Using L2TPv3 for Layer 3 VPNs

Deploying L3VPNs using MPLS is common in service provider and—more recently—in enterprise environments.  While not as widespread, using L2TPv3 as the foundation for RFC2547bis-like VPNs is a viable alternative that has its advantages. In this post, I’ll describe reasons for selecting L2TPv3 for L3VPN and highlight arguments against the protocol. I’ll refer to the technology as MPLS/L2TPv3.

Here’s a quick technology refresher. In the context of L3VPNs, L2TPv3 tunneling is used to build VPNs over a native IP network. Familiar MPLS/VPN concepts such as P|PE|CE routers, VRFs, route targets, and route distinguishers carry over mostly intact. Rather than using an outer label, the IP header in the L2TPv3-encapsulated packet directs packets to the egress PE, where the session ID and cookie are used to de-multiplex connections. The inner label encapsulates the customer IP packet the same way as in traditional MPLS/VPN deployments.

MPLS/L2TPv3 is simple to configure and maintain. Since the core is native IP, label distribution protocols aren’t needed. All MPLS configuration is performed on the PE routers. PE to PE connectivity problems can be diagnosed with ping. If the ping fails, your NOC will investigate an IP routing issue rather than examining label state in the core.

The decoupling of the end-to-end LSP and L3VPN construction permits greater flexibility. I can build an overlay L3VPN to any location that has vanilla IP connectivity. In selecting service providers for my global locations, I am not tied to SPs that offer Carrier-Serving-Carrier (CsC) or Inter-AS Option 3. Give me an IP pipe, and I can create PE devices anywhere without resorting to questionably scalable GRE overlays.

Let’s look at two applications. Mobile network operators are moving toward IP/Ethernet for cell site to aggregation point connectivity (known as backhaul in the industry). Carrier Ethernet—though popular—is a poor match for offering commodity Internet access to mobile subscribers (for more on this, see my article in Cisco’s IP Journal). A better approach is using a native IP backhaul network. Since operators often require address separation, MPLS/L2TPv3 is a natural fit. Providers can roll their own L3VPN without interaction with the backhaul providers.

The second application I’ll mention is cloud/data center. I’m not the first person who has pointed out scalability problems with segmenting the network using VLANs. Layer 3-centric architectures have superior scaling properties and discourage wide-area live migration and other practices that scare us network engineers. The MPLS/VPN architecture allows for segmentation at Layer 3. Of course, this could be accomplished with an MPLS core or native IP one with L2TPv3. I’d argue that engineers should consider L2TPv3 for the ability to construct L3VPNs without end-to-end LSPs. Think about the ease in which you could connect data centers and various cloud types over public and private networks.

I was involved in the deployment of MPLS/L2TPv3 at a major Tier 1 ISP. In this position, I probably heard most arguments against L2TPv3. Let’s examine several of these.

  • L2TPv3 creates a vendor lock-in situation - MPLS/L2TPv3 definitely limits your router vendor options. Cisco implements MPLS/L2TPv3. I believe Huawei may as well. I’m convinced Juniper would implement MPLS/L2TPv3 if your spending warranted.
  • “I already implemented MPLS for other reasons.” – Using MPLS/L2TPv3 probably doesn’t make sense if you already have MPLS in the core and are satisfied with limitations that accompany the need for the end-to-end LSP. You could always use GRE for the one-offs for which an LSP can’t be established.
  • L2TPv3 doesn’t provide traffic engineering – Correct. If you want TE, use an MPLS core. In carrier environments, I advocate provisioning sufficient bandwidth to render complex TE mechanisms unnecessary. Traffic on the Internet increases too quickly to ride high on the utilization curve. In environments where bandwidth is cheap and plentiful, why not deliver all packets?
  • Cisco implements MPLS/L2TPv3 features six months after features are supported in MPLS/VPN – True. This was a problem in the early days of L3VPNs. Over ten years into deployment, are you still on the bleeding edge for L3VPN features? Perhaps you are, in which case MPLS/L2TPv3 may not be for you. The huge install base for MPLS/VPN will always trump L2TPv3 when it comes to feature delivery.

My goal in writing this article was to offer a balanced assessment of using L2TPv3 for L3VPNs. In my experience, engineers have very strong feelings on this subject. I look forward to hearing the thoughts of the Packet Pushers community and discussing the subject with posters.

Jeff Loughridge
Jeff Loughridge has been promoting simplicity in IP networks since 1997. In his role as principal consultant at Brooks Consulting, Jeff helps his clients design and operate large-scale wireline and wireless networks. Prior to starting his company in 2009, Jeff spent ten years at Sprint in engineer and manager positions.
Jeff Loughridge

Latest posts by Jeff Loughridge (see all)

  • pmchan

    There are already alternative solution like encapsulate MPLS into GRE to solve the problem and Juniper support this for long time. Why re-inviting the wheel to create a separate protocol to encapsulate MPLS? Besides, for carrier network which they can control, building MPLS ready core network is not as hard as it sounds and offer sounds like a must to me.

    So for me,  the only value for L2TPv3 for MPLS is to carrier the MPLS over Internet and yes, it is a pretty vendor lock-in solution.