I previously made a post about VRF lite, but there's some more information worth adding to the subject. Mainly how the VRF protocol elements behave, which is relevant to both types of VRF. This post also covers introduction to MPLS, but will not include how the protocol works in detail.

VRF name & Route Distinguisher

The previous post is about how these are configured, but didn't cover how they interact between routers. The thing about these 2 configurations, is that they are locally significant, the name more so than RD. This has design implications that are worth considering when deploying, especially for VRF lite, but also for Edge devices (something that'll be a subject in MPLS later).

VRF Name: The name is locally significant and is not propagated between routers. This means two different VRF names on different routers can by default route into each other, or a VRF into Global Routing Table (GRT).

Route Distinguisher: RD is also locally significant, but it's still propagated through an MPLS. An RD can be the same across a VRF on different routers, but a different RD can also be used for different routers (same VRF). This has several purposes such as using the RD to load balance and being able to see which router a prefix was advertised from (if using unique RD). RD is only propagated with MP-BGP, but configuring VRF doesn't require BGP, which leads to the implication that the VRF and RD don't matter at all for VRF lite. Needs some PoC.

Above topology is a VRF aware router peering with a regular router, both with OSPF. initial configuration used:

hostname R1 ! ip vrf 1 rd 1:1 ip vrf 2 rd 1:2 ! int e2/0 ip vrf forwarding 1 ip address ! int e2/1 ip vrf forwarding 2 ip address ! int lo100 ip vrf forwarding 1 ip address ! int lo101 ip vrf forwarding 2 ip address ! router ospf 1 vrf 1 network area 1 network area 0 ! router ospf 2 vrf 2 network area 2 network area 0 ________________________________________ hostname R2 ! int e2/0 ip address ! int e2/1 ip address ! router ospf 1 network area 0 network area 0

Refer to the image below. What this leads to are seperate routing tables on R1, both peering with R2. R2 then advertises each routing table into the other VRF. Basically its a redistribution. It shows that VRF instances do not care about the other end of an interface and it just opens up for a bit of creativity in regards to route design. It's also an essential knowledge when getting into MPLS VPN.

Next element is Route-Target and MP-BGP. RT is how a router knows which VRFs are allowed into each other. It has 2 functions: Export and Import, as seen on the image below. The format is the same as RD, but they have no direct relation or effect on each other. The ID one VRF exports to, has to be the same ID another VRF imports, if redistribution is desired. The same ID can be used to both import and export, which is what the both command does, saves a bit of configuration.

RT needs MP-BGP to do anything. What RT actually does is importing or exporting the BGP table. RT is a BGP extended community, which will be further described in MPLS VPN. The following image presents the logic behind a VRF leak. First off, it requires information present in the RIB. That information has to get into the BGP table. Either redistribute the IGP or use network statements in BGP.

Configuration used:

hostname R1 ! ip vrf 1 rd 1:1 ip vrf 2 rd 1:2 ! int e2/0 ip vrf forwarding 1 ip address ! int e2/1 ip vrf forwarding 2 ip address ! int lo1 ip vrf forwarding 1 ip address ! int lo2 ip vrf forwarding 2 ip address ! router eigrp dc address-family ipv4 unicast vrf 1 autonomous-system 1 network network ! address-family ipv4 unicast vrf 2 autonomous-system 2 network network ________________________________________ hostname R2 ! ip vrf 1 rd 1:1 route-target import 1:1 ! ip vrf 2 rd 1:2 route-target export 1:1 ! int e2/0 ip address ! int e2/1 ip address ! router eigrp dc address-family ipv4 unicast vrf 1 autonomous-system 1 network ! address-family ipv4 unicast vrf 2 autonomous-system 2 network ! router bgp 1 address-family ipv4 vrf 1 redistribute eigrp 1 ! address-family ipv4 vrf 2 redistribute eigrp 2

Before applying the RT configuration, the BGP table for one VRF looks like this:

I redistributed the IGP into BGP. Probably ought to use a route-map to remove transit routes. In the vrf configuration I use the route-target import 1:1 / route-target export 1:1 to send VRF 2 into VRF 1. The BGP table now gets some more entries:

And the routing table for VRF 1 now has routes learned through BGP. The routes learned from another VRF are marked with () or specifically (2) in this scenario:

The fact that the routes are learned through BGP, means the IGP won't advertise them by default. One of the options is to redistribute BGP into IGP. It's not possible to use the network statement in the IGP to advertise the leaked BGP routes.

RT has a purpose in VRF lite when doing VRF leak with MP-BGP, but this setup can just as well be performed with a firewall using virtual instances, even if it's not VRF aware. In regards to MPLS VPN, it is important to keep in mind, that the VRF is locally significant. RT has to be configured for the same VRF on different routers in MPLS L3 VPN, otherwise they wont exchange routes.


MPLS itself is rather simple, but what it enables us to do with the network is the complicated part. The benefits of MPLS are not the same as they were when it was invented. MPLS isn't used to get faster routing anymore. Routing in hardware or IP switching provides the same routing capacity as label switching. Instead MPLS provides advanced traffic engineering and MPLS L3 VPN, which enables a core without the need for BGP.

Unified Network Infrastructure is one of the buzzwords surrounding the technology. MPLS has the capability to carry different types of traffic. IPv4, IPv6, L2 and the old technologies such as HLDC and PPP. The MPLS core doesn't care about the kind of traffic crossing, only the edge is concerned with this.

AToM: Any Transport over MPLS is used to connect layer 2 across MPLS and is enabled with a single command.

BGP-Free Core: MPLS VPN scalability stems from this concept. It's a combination of what label switching provides along with BGP. The Core only has to provide Next-Hop knowledge for the BGP peers, which means an IGP (OSPF, IS-IS). Now, this is how iBGP can be configured regularly, but MPLS is needed to encapsulate and carry the IP traffic, so the core doesn't need to actually have the IP routes in a routing table.

Peer-to-Peer VPN, CE & PE: Three of the main terms in context of MPLS VPN. P2P is how MPLS is delivered to a customer. This model entails peering from the Customer Edge (CE) to the Provider Edge (PE). The model is effective because the provider only has to provision the PE to CE, while the MPLS backbone is unchanged.

The alternative model is Overlay VPN, which makes the provider network completely transparent to the customer's edge, which is also the concept of DMVPN.

Label: The MPLS label is 32 bit and contains 4 fields. The header is as shown below. In the label, the first 16 (0-15) values are reserved, so the first label a router can use is 16. The next field is experimental, which is used for QoS. BoS means Bottom of Stack, which is used for the router to check how many labels are "beneath". MPLS VPN will put a label on top of a label and in this case, the BoS will be set to 0, if there is a label beneath. A value of 1 means it's the bottom label. The routers use this when popping the labels at edges.

MPLS Terminology

There are a lot of unique terms to MPLS, which describe different mechanics or roles.

  • LSR = Label Switch Router. This decsribes an MPLS capable router and there are 3 types of LSR. Ingress LSR is the first router that receives regular traffic and labels the packet. It can also be refered to as an imposing LSR. Egress LSR is the end of the MPLS network and removes the label from packets. Intermediate LSR is a router inbetween the edges. In MPLS VPN, a PE router for a customer will be both Egress and Ingress. A Provider (P) router, which is what the MPLS core consists of, would be the Intermediate LSR.
  • Pop, label popping, removing label. Terms that describe removing one or more labels from the Label Stack (Third field in the MPLS label). This is done by the LSR.
  • Opposit of popping is pushing, which is the term for adding a label to the packet, also done by the LSR.
  • Swapping is when an LSR receives a labeled packet, changes the label to one of its own and forwards the packet.
  • LSP = Label Switch Path. As the name implies, it's a path through the network that is MPLS enabled.
  • Nested LSP is the process of an LSP within LSP, which is a concept of Hierarchical MPLS TE and will be a larger subject in the next post.
  • FEC = Forwarding Equivalence Class. It describes a flow where packets are forwarded the same way. This means all traffic in an FEC, receives the same label. The FEC pretty easily defines what the same path is: Using the same exit interface and the same next-hop. FEC contains a lot more than this when going into advanced subjects like QoS. The same label can belong to different FEC, if the packets are treated differently, such as using QoS.

LDP, label stacking and RSVP will be covered in the next post.