Making the case for Layer 2 and Layer 3 VPNs

The common wisdom a few years ago was that Frame Relay and ATM were dead and that anyone trying to offer a serious Virtual Private Network (VPN) service should be offering Layer 3 VPNs (usually in form of an MPLS

    Requires Free Membership to View


Unfortunately, the world is not flat, and Layer 2 services cannot cover the needs of an entire network.

Ivan Pepelnjak, Chief Technology Advisor, NIL Data Communications

Equipment manufacturers have started promoting Layer 2 VPNs recently, increasing the confusion within some service providers that now have to decide what service to offer to their customers. As always, the right answer is: Listen to your customers, find a solution that matches their expectations, help them get the most out of the solution, and deliver it reliably.

Before the explosion of IP-based VPNs based on Multiprotocol Label Switching (MPLS) or IP Security (IPSec), almost all service providers (excluding the pure Internet Service Providers) were offering Layer 2 virtual circuit services implemented with Frame Relay or ATM technologies. Some providers decided early to climb up the value chain and offer managed router services, effectively providing end-to-end IP connectivity to their customers (most often LAN-to-LAN, but some even provided dial-in access).

For these service providers, the migration to IP-based VPNs was simple, as they already had the necessary IP routing skills and understood the customer environment. The providers that didn't make that early migration needed to make the following realizations:

  • Previously they had provided point-to-point transport (bit pipes); now they were providing the very core of the customer's network.
  • End-to-end convergence and backup plans were previously the customer's problem; now they were the service provider's responsibility.
  • If they wanted to offer IP-based services, they needed to have in-depth IP knowledge in their design, deployment and operations teams.

 Some of the more traditional service providers have ignored these facts and failed miserably. I've seen service providers offering point-to-point IP services (emulating virtual circuits with IP) or supporting only static routes and connected subnets (which also meant they also couldn't answer the simple question of how they planned to provide a backup for the primary access link). For these service providers, the newly introduced Layer 2 VPNs seemed like a panacea; they could continue ignoring the IP world and offer what they know best -- Layer 2 services.

Unfortunately, the world is not flat, and Layer 2 services cannot cover the needs of an entire network. This fact has been proven time and again in networks that used wide area network (WAN) bridges 15 years ago (and crashed) or in environments where switches without Layer 3 capabilities were used) to replace routers. To provide a stable, reliable, scalable network, you need both Layer 2 services to provide transport and Layer 3 services to segment the network into manageable isolated chunks.

Implementing true service convergence on a single core

On the other hand, there are situations where Layer 2 transport is the only solution. Customers often use legacy equipment that has Frame Relay or ATM uplinks (in some cases, the really old boxes have only an X.25 port) and these needs have to be addressed. as well. Some customers still run non-IP protocols in an Ethernet environment. And there's always the transport of non-packetized voice traffic that uses T1/E1 lines between exchanges.

If you want to implement true convergence of all your services onto a single core infrastructure, your core network should support the transport of public IP, private IP (VPN) as well as a number of legacy Layer 2 WAN and LAN technologies (for example, with Any Transport over MPLS – AtoM). Unless you decide that your core network will be built with Wavelength Division Multiplexing (WDM), you have to offer IP-based Layer 2 and Layer 3 VPN services (using ATM in the core is simply too expensive when compared to IP-based solutions). Most often, the core technology of choice would be MPLS, but you can get similar results (although with more overhead and reduced traffic engineering capabilities) with IPSec-based Layer -3 VPNs and Layer 2 Tunneling Protocol Version 3 (L2TPv3)-based Layer 2 VPNs.

Whatever you decide to offer your customers, be honest with them. If you're providing an end-to-end LAN-to-LAN solution, use a Layer 3 service (an MPLS- or IPSec-based VPN). If you decide not to offer a Layer 3 service, but provide a site-to-site Layer 2 transport infrastructure (virtual circuits or bridged LAN-to-LAN traffic), that's fine -- as long as you're not trying to persuade customers that they can plug your LAN cable straight into their Layer 2 switches on every site and have a reliably running network.

About the author: Ivan Pepelnjak, CCIE No. 1354, is a 25-year veteran of the networking industry. He has more than 10 years of experience in designing, installing, troubleshooting and operating large service provider and enterprise WAN and LAN networks and is currently chief technology advisor at NIL Data Communications, focusing on advanced IP-based networks and web technologies. His books include MPLS and VPN Architectures and EIGRP Network Design. You can read his blog here: http://ioshints.blogspot.com/index.html.

This was first published in November 2007

There are Comments. Add yours.

TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.