An In-Depth Look at RD and RT, Pt. 4
In this final part, we will use RTs to provide shared services to multiple customer VPNs.
By importing and exporting multiple RTs into a VRF, we can share routes between VRFs to easily provide the same routes to multiple customer VPNS. This exercise will help you understand exactly how import and export RTs work.
In this lab, we will provide internet access to the CUSTOMER_A and CUSTOMER_B VRFs by importing a 0/0 route from our INTERNET VRF into the customer VPNs. The customers will need to source NAT their own traffic from a public /32 IP that we give them, and we’ll need to import their public /32s into the internet VRF.
Lab
We’ll re-use the existing topology from part 3, but now PE4 connects to an internet transit peer. 20.20.20.0/30 is used for BGP peering, and there is a loopback, 8.8.8.8 on the peer which we will use to verify internet connectivity. PE4 advertises 100.1.1.0/24 to the peer, which is the service provider’s own address space which it will hand out to customers.
The CUSTOMER_A and CUSTOMER_B VRFs use the same RD and RTs values of 123:100 and 123:200, respectively, as in the previous lab.
Here’s the PE4 and Internet peer configuration:
As you can see, we’re running the internet routing table as a VRF. This allows us to easily import/export routes to and from this INTERNET VRF into customer VRFs.
We’ll allocate public IP address for the CEs as follows:
CE1
100.1.1.1/32
CE2
100.1.1.2/32
CE3
100.1.1.3/32
CE4
100.1.1.4/32
IOS-XR
The public IPs will be added as a loopback (Lo100) on the CEs. On PE2 we’ll add static routes with a next-hop-vrf of the Customer VRF, with the next-hop-address as the MPLS transit IP for that CE.
Because PE2 redistributes those statics into the BGP table for the INTERNET VRF, PE4 has learned the routes to 100.1.1.3 and 100.1.1.4. But CE3 and CE4 do not have a default route to the internet yet.
In order to inject the 0/0 route from the INTERNET VRF, we’ll simply import the route-target that the INTERNET VRF exports, which is 123:1000. We cannot just advertise a default route to the customers under BGP in the Customer VRFs (such as default-originate). This is because we need the default route to actually be from the INTERNET VRF, and to point to PE4 in the INTERNET VRF.
We’re getting the full INTERNET VRF routing table on the CEs now, which is not what we want. We want just a default route to be injected from the INTERNET VRF into the Customer VRFs.
We’ll add a route-policy to the import of all routes into the VRF in order to control which routes we are actually importing into the Customer VRFs. This will let us block everything except for the 0/0 coming from the INTERNET VRF.
Oops, we have just our 0/0 from the INTERNET VRF now, but we lost all of our customer routes on the CEs as well!
We’ll need to change our route-policy to pass along any RFC1918 prefixes. Feel free to try alternative methods, such as matching the RT value and filtering traffic based on that.
Perfect, we now have our customer routes plus the 0/0 from the INTERNET VRF.
The CEs see the 0/0 route as just another prefix advertised by the PE. The CEs have no idea that this actually came from another VRF.
On PE2, the 0/0 route in the Customer VRFs points to PE4. PE2 will put the VPN label on traffic matching this route before forwarding it to PE4, just as if the 0/0 route was another route in the customer VRF itself. Once you import the prefix into the customer VRF, there is really no difference between routes imported from the same VRF on another PE, or a different VRF. Meaning, on PE2, it doesn’t have the nexthop in the INTERNET VRF, and then that nexthop in the default VRF. Looking at the RIB, you have no idea which routes came from RT 123:100 and which from RT 123:1000. The PE simply matches prefixes with RT vales that match the import statement and puts those into the VRF.
Success! CE3 and CE4 can ping 8.8.8.8 from Lo100.
Remember that PE2 is redistributing the static routes into BGP in the INTERNET VRF. This is how PE4 has a route back to Lo100 of CE3 and CE4.
IOS-XE
On IOS-XE there is not a one-line command to set a static route in a VRF to use a next-hop in another VRF. Instead, the CE1 and CE2 will advertise their Lo100 to the PE, and PE4 will import these routes into the INTERNET VRF.
We’ll use an import map which is the IOS-XE version of the import route-policy we used on PE2. This will filter routes from the INTERNET VRF so that we only get a 0/0 from the INTERNET VRF plus the RFC1918 prefixes from the customer VRFs.
PE4 does not have the two Customer VRFs defined, so it is automatically filtering out the vpnv4 routes from the CUSTOMER_A and CUSTOMER_B VRF.
However, when we import the RTs that these Customer VRFs are exporting into the INTERNET VRF, PE4 will stop filtering those prefixes automatically.
We now have the public IPs of CE1 and CE2 in the RIB
Success! Both CE1 and CE2 can ping 8.8.8.8
The CEs can also ping each other.
Conclusion
The purpose of this article was to give you a real-world example of importing and exporting multiple RT values in order to offer shared services to customer VPNs. In order to accomplish this we had to rely on quite a few extra features, such as the import map and static routes using a different next-hop VRF. Along the way we defined prefix-sets and route-policies which, while taking away some attention from the overall goal of this article, is still great practice in terms of learning the exam topics.
I hope that you feel extremely confident with RDs and RTs now.
To sum it up, RDs distinguish routes to make them unique in the global vpnv4 (or vpnv6) table. You can use the same RD for the same VRF among multiple PEs, or you can use a unique RD per PE for the same VRF. As we saw in part 3, this technique can be used to facilitate multipathing.
RTs are used to import prefixes into a VRF. A VRF can have multiple import RTs and/or multiple export RTs. Normally you will see a single import RT and export RT on a VRF, and this will often be the same value as the RD. But now you’ve seen how you can import/export multiple RT values in order to provide shared services to multiple customer VPNs, as we did in this article (part 4).
Last updated