Introduction to Interprovider MPLS L3 VPN's

This post is about the technology that has somewhat limited use in real life - at least most interesting (complex) parts of it.

There are many reasons why these technologies are not widely used it and I will touch on some of them in appropriate sections, but major reasons are (in)security and relative complexity. Since these technologies are in their nature oriented towards network service providers and they tend not to like complexity and especially trusting other networks, it's easily understood why there are not many applications in real life.

The foundation for this text is laid out in RFC 4364, section 10.

The RFC details three different ways in which two (or more) carriers can interconnect their networks in order to provide end-to-end VPN service for their customer(s). These are widely known as "Option A", "Option B" and "Option C". Of course, some of these can be implemented in several ways and I will point that out in due time. However, I would like to immediately split "Option C" into "Option C-1" and "Option C-2".

In this post, I will provide very brief overview over these options and in subsequent posts, explain them in more detail.

"Option A", sometimes also known as back-to-back VRF is by far the simplest solution. Essentially, Carrier 1 will connect to Customer site 1 from a PE router and create VRF. Similarly, Carrier 2 will connect to Customer site 2 from their PE router and create VRF. PE-CE routing is not really relevant and can be anything. Interconnection between carriers will be implemented using dedicated interface (or a subinterface if more such VPN's are delivered) in their respective VRF's. Like I mentioned, this is the simplest and possibly the most common form. There are virtually no security or complex implications, as two carriers can treat each other as just another customer connection. Refer to the diagram below for illustration.



"Option B" is slightly more complex and requires "MPLS interconnection" between service providers. I.e. border routers (dubbed, as one may expect, Autonomous System Border Routers - ASBR) need to exchange labels for given prefixes. These prefixes are Loopback interfaces of PE nodes that VPN is connected to. Labels are usually exchanged using BGP (bgp send-label), which automatically enables MPLS forwarding on the interface. I will visit this in more detail later. What happens within single AS is interesting. Sometimes, these routes are redistributed in IGP and sometimes, iBGP is used for label distribution. Diagram below illustrates this variant.



"Option C" is, probably, the most complex of the three. Labels are not exchanged between ASBR's using direct BGP session, but there is MPLS forwarding on the link. Usually using LDP, but other options (RSVP) can be used. PE's, of course, need to know about each other's labels, so it's important that they exchange their labels. This can be done directly between two PE's in what I call "Option C-1", or alternatively, eBGP session between route reflectors can be used. The important thing to note here is that in order for this solution to work, one aspect of BGP needs to be "adapted". In a case of eBGP session, next-hop attribute on received prefixes is replaced with the IP address of the BGP neighbor. This is perfectly fine for IP forwarding, but it will break MPLS. In this case, eBGP session needs to leave next-hop as-is, or as Cisco says, "bgp next-hop-unchanged". I will address this in the implementation post. For now, consult the diagrams below for "Option C-1" and "Option C-2", respectively.





This was a horrible week for me. I've been working on upgrading backbone network and was hit hard with several 7600 bugs. I spent 5 hours sleeping and the rest either talking to or waiting for TAC. She may even have left me, but if She hasn't, that must mean that She truly loves me. I haven't seen her for a while... I hope She's still there when I finally go home.