In this post I will be showing you how its possible to use different paths between your PE routers on a per VRF basis.
This is very useful if you have customers you want to “steer” away from your normal traffic flow between PE routers.
For example, this could be due to certain SLA’s.
I will be using the following topology to demonstrate how this can be done:
A short walkthrough of the topology is in order.
In the service provider core we have 4 routers. R3, XRv-1, XRv-2 and R4. R3 and R4 are IOS-XE based routers and XRv-1 and XRv-2 are as the name implies, IOS-XR routers. There is no significance attached to the fact that im running two XR routers. Its simply how I could build the required topology.
The service provider is running OSPF as the IGP, with R3 and R4 being the PE routers for an MPLS L3 VPN service. On top of that, LDP is being used to build the required LSP’s. The IGP has been modified to prefer the northbound path (R3 -> XRv-1 -> R4) by increasing the cost of the R3, XRv-2 and R4 to 100.
So by default, traffic between R3 and R4 will flow northbound.
We can easily verify this:
And the reverse path is the same:
Besides that traffic flow the desired way, we can see we are using label switching between the loopbacks. Exactly what we want in this type of setup.
On the customer side, we have 2 customers, Customer A and Customer B. Each of them has 2 sites, one behind R3 and one behind R4. Pretty simple. They are all running EIGRP between the CE’s and the PE’s.
Beyond this we have MPLS Traffic Engineering running in the service core as well. Specifically we are running a tunnel going from R3’s loopback200 (33.33.33.33/32) towards R4’s loopback200 (44.44.44.44/32). This has been accomplished by configuring an explicit path on both R3 and R4.
Lets verify the tunnel configuration on both:
On R3:
And on R4:
On top of that we have configured a static route on both R3 and R4, to steer traffic for each others loopback200’s down the tunnel:
Resulting in the following RIB’s:
And to test out that we are actually using the southbound path (R3 -> XRv-2 -> R4), lets traceroute between the loopbacks (loopback200):
on R3:
and on R4:
This verifies that we have our two unidirectional tunnels and that communication between the loopback200 interfaces flows through the southbound path using our TE tunnels.
So lets take a look at the very simple BGP PE configuration on both R3 and R4:
R3:
and R4:
From this output, we can see that we are using the loopback100 interfaces for the BGP peering. As routing updates comes in from one PE, the next-hop will be set to the remote PE’s loopback100 interface. This will then cause the transport-label to be one going to this loopback100 interface.
A traceroute from R1’s loopback0 interface to R5’s loopback0 interface, will show us the path that traffic between each site in VRF A (Customer A) will take:
R1:
and lets compare that to what R3 will use as the transport label to reach R4’s loopback100 interface:
We can see that this matches up being 16005 (going to XRv-1) through the northbound path.
This begs the question, how do we steer our traffic through the southbound path using the loopback200 instead, when the peering is between loopback100’s?
Well, thankfully IOS has it covered. Under the VRF configuration for Customer B (VRF B), we have the option of setting the loopback interface of updates sent to the remote PE:
On R3:
and the same on R4:
This causes the BGP updates to contain the “correct” next-hop:
R3:
44.44.44.44/32 being the loopback200 of R4, and on R4:
Lets check out whether this actually works or not:
Excellent! – We can see that we are indeed using the southbound path. To make sure we are using the tunnel, note the transport label of 16007, and compare that to:
R3:
I have deleted alot of non-relevant output, but pay attention to the Outlabel, which is indeed 16007.
So that was a quick walkthrough of how easy it is to accomplish the stated goal once you know about that nifty IOS command.
I hope its been useful to you.
Take Care!