Per-VRF TE Tunnels
Load flash:mpls.te.per.vrf.init.cfg
#IOS-XE
config replace flash:mpls.te.per.vrf.init.cfg
#IOS-XR
configure
load bootflash:mpls.te.per.vrf.init.cfg
commit replace
yThere are two customer VRFs now: “VOICE” and “DATA.”
XRv13 and XRv14 each have one interface and one loopback in each VRF. They are running VRF Lite:
VOICE
XRv13
Lo0= 100.13.13.13/32
XRv14
Lo0 = 100.14.14.14/32
DATA
XRv13
Lo1= 200.13.13.13/32
XRv14
Lo1 = 200.14.14.14/32
Configure two bidirectional TE tunnels between CSR8 and XRv11.
The Voice TE tunnel should use most direct path between the two PEs.
It should reserve 5M of CT1 bandwidth using the MAM model so that this bandwidth is protected.
The Data TE tunnel should use the path: CSR8-CSR6-CSR9-CSR10-XR12-XR11.
Answer
Configure DS-TE IETF mode with MAM on at least one path between CSR8 and XR11.
Configure TE tunnels and a secondary loopback for DATA VRF.
Explanation
DS-TE is covered in a separate lab, so we won’t go into its details here.
For TE tunnels that you want to use on a per-VRF basis, you must use a separate loopback. We configure Lo1 for this purpose on CSR8 and XR11:
Next, we need to configure these loopbacks as the VPNv4 nexthop for the routes exported from the DATA VRF. This is simple to do on IOS-XE, using a built-in command just for this purpose, but it requires an RPL on IOS-XR.
You may need to clear BGP VPNv4 routes. You should now see that VOICE routes are learned via Lo0 as usual, and the DATA routes have a BGP nexthop of Lo1.
Finally, we must configure the TE tunnels. This is no different than before, however you need to watch out for the TE tunnel destination. The destination is not an IP address, it is a TE RID. So if you try to build the DATA TE tunnel with a destination of Lo1, the tunnel cannot be resolved. Instead, we build both TE tunnels destined to the Lo0 address, and then use a static route to steer traffic destined for the Lo1 address out the appropriate TE tunnel.
Note that if you accidentally build the TE tunnel to the Lo1 address, you can verify the issue multiple ways. One way is to use “show mpls traffic-eng topology path destination <Lo1 address>.” This will run PCALC on the router and give you the following error:
Additionally, we can debug path errors while the router tries to calculate the tunnel as well:
Verification
Traffic between XR13 and XR14 in the VOICE VRF should take the most direct path:
Traffic between XR13 and XR14 in the DATA VRF should take the “long” path:
In summary, per-VRF TE tunnels are not a new configuration. You configure multiple TE tunnels as usual. The difference is that you set the BGP nexthop different per VRF. You then must steer the traffic to the different loopback to the appropriate TE tunnel based on a static route.
Last updated