So I hope the last three posts got you excited about this technology. Not only have we used a shared infrastructure for multiple customers without them knowing, but we’ve kept all of the customer routes out of the providers network! That’s pretty cool! So let’s take a look at how this works.
VRFs/VPNV4/RDs/RTs
So we already talked about VRFs and VPNV4 route advertisements. However, I didn’t really dig into the details mostly because it’s a little confusing. So let’s talk about how RDs and RTs really work in greater detail.
RDs (Route Designators) are 64 bit identifiers that get prepended to your 32 bit route to make a 96 bit VPNv4. This makes good sense and it’s a perfect way to keep customer A’s 10.0.0.0/8 route distinct from customer B’s 10.0.0.0/8 route when advertising them across the MP-BGP session between PE routers.
RTS (Route Targets) are BGP extended community values. These get tagged on import and export from a VRF and are what the router actually uses to import and export routes out of certain VRFs.
This is where it’s sort of confusing. RDs are used to make routes unique but RTs are what are used to import and export routes out of VRFs. Literally the only thing that an RD is used for is to make the VPNv4 route. They accomplish the task of making multiple customer’s routes unique when they are being advertised via MP-BGP. However, that’s where their functionality ends. RTs make the VRF import/export decision. Routes are tagged on import and export with an RT. These get attached to the route updates as extended community strings and are then used by the receiving router to make VRF import decisions.
In the last post, we configured the PEs to do so with this configuration…
ip vrf customer1
rd 65100:100
route-target export 65100:100
route-target import 65100:100
So the RD for customer1’s VRF is 65100:100. I decided (it was just easier) to use the same value for the RT for this VRF. So these route’s will get exported with an extended community value of 65100:100. Let’s look at both of these items on the routers. In the output of the command shown below you can see that the RD for each VRF is shown.
PE3#show ip bgp vpnv4 all
BGP table version is 9, local router ID is 7.7.7.7
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,
r RIB-failure, S Stale
Origin codes: i – IGP, e – EGP, ? – incomplete
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 65100:100 (default for vrf customer1)
*> 10.10.20.0/24 192.168.30.2 0 0 65100 i
Route Distinguisher: 65200:200 (default for vrf customer2)
*> 172.16.2.0/24 192.168.40.2 0 0 65200 i
To see the RT you can look at the actual BGP route to see the extended community string as shown below.
PE3#show ip bgp vpnv4 vrf customer1
BGP table version is 9, local router ID is 7.7.7.7
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,
r RIB-failure, S Stale
Origin codes: i – IGP, e – EGP, ? – incomplete
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 65100:100 (default for vrf customer1)
*> 10.10.20.0/24 192.168.30.2 0 0 65100 i
PE3#show ip bgp vpnv4 vrf customer1 10.10.20.0 255.255.255.0
BGP routing table entry for 65100:100:10.10.20.0/24, version 4
Paths: (1 available, best #1, table customer1)
Not advertised to any peer
65100
192.168.30.2 from 192.168.30.2 (10.10.20.1)
Origin IGP, metric 0, localpref 100, valid, external, best
Extended Community: RT:65100:100
mpls labels in/out 31/nolabel
I’m hoping at this point it’s a little clearer how the entire ‘shared provider infrastructure’ works. In the next section we’ll talk about why there aren’t any customer routers on the P routers.
MPLS Label Stacks
In the last post we showed you a ‘show ip route’ from a P router and we saw that the P routers didn’t know about any of the customer routes. So how is that possible? This is where MPLS really begins to shine.
We talked about how MPLS works at a very basic level. Tags get assigned to prefixes and the traffic is label switched through the network. Each LSR performs an operation based on the label that it sees when it receives the traffic. In most cases, the LSR will examine the label on the packet, and swap labels based on what the LFIB entry for that incoming label said to do. That’s pretty easy to understand but it still doesn’t explain how the P routers don’t need to know any customer routes. This is where label stacks come into play.
While we knew that MPLS used label switching, you likely dint know that you could have multiple labels on the same MLPS packet. In the a VPN scenario, there are generally two labels. The top label is sometimes called the local label and the bottom label is called the VPN label. When a PE router sends a MPLS packet to another PE router it pushes both labels onto the MPLS label stack for that packet. First it looks up the packets true destination and pushes the packet for that. This would be the VPN label. Next it pushes the local label which is likely the label for the PE router that the destination MPLS VPN packet is towards. An example should clear up any questions…
PE1#show ip cef vrf customer1 10.10.20.0 255.255.255.0
10.10.20.0/24, version 15, epoch 0, cached adjacency 172.172.172.2
0 packets, 0 bytes
tag information set
local tag: VPN-route-head
fast tag rewrite with Fa0/0.1, 172.172.172.2, tags imposed: {21 31}
via 7.7.7.7, 0 dependencies, recursive
next hop 172.172.172.2, FastEthernet0/0.1 via 7.7.7.7/32
valid cached adjacency
tag rewrite with Fa0/0.1, 172.172.172.2, tags imposed: {21 31}
If we look for the 10.10.20.0/24 customer1 route in the CEF table we can see the labels that are imposed on the MPLS packet. In this case, the label 21 is the label that PE1 received from it’s neighbor P1 for the prefix 7.7.7.7/32. This would be the top or local label. At each LSR in the LSP the top (local) label is swapped just like in normal MPLS. The bottom label (31) is the label PE1 received from its MP-BGP neighbor PE3 for the destination prefix 10.10.20.0/24. So the local label is used to transport the MPLS packet across the provider infrastructure. The last P router in the path pops the label (the local label with PHP) and PE3 receives a MLPS packet with the VPN label on it. This way, it knows MPLS VPN the packet belongs to.
In this blog we looked a little deeper at some of the aspect of MPLS VPNs. While we just touched the surface, I hope it helps give some perspective as to what you can accomplish with MPLS.