CBTS/PBTS
Load mpls.te.cbts.init.cfg
Two tunnels are configured between CSR8 and XRv11, but there is no traffic forwarding setup for them yet. (No autoroute announce). Configure tun0 (”LONG_WAY”) to forward customer traffic matching the default EXP values, and tun1 (dynamic) to forward traffic matching EXP=5. Test this from the CEs to verify that traffic is taking the correct path.
Answer
On IOS-XE we must setup a master tunnel which has the autoroute announce statement and sepcifies the member tunnels. Additionally we must set the EXP mappings on the two member tunnels directly.
On IOS-XR we simply define the EXP mappings and use autoroute announce directly on the individual tunnels. IOS-XR calls this feature PBTS (Policy-Based Traffic Selection).
Verification
We can use the command show mpls traffic-eng exp to verify the EXP mappings are configured correctly on CSR8:
CSR8 will show the route for 11.11.11.11/32 via tun100 (the master tunnel):
Note that IOS-XE doesn’t validate that EXP values are uniquely mapped to tunnels. You can overlap mappings. If that happens, IOS-XE just randomly picks which tunnel to use. This does give you redunancy though - if one tunnel goes down, you know the other tunnel will forward that EXP traffic.
To verify in the data plane, we would ideally traceroute with dscp values, but IOS-XR doesn’t let us do this. Instead I set the IPP mapping on ingress on CSR8.
First, traffic with no marking should go via tun0 which is the “long way”:
Next I mark these packets as IPP 5 on CSR8:
Traffic is now taking the more direct path which was calculated dynamically on tun1:
An easier way to do this is by using ping with the type option, and watching the output count on the individual tunnel interfaces. From XR14 we ping XR13 with no DSCP value.
We see the counters only increase on tun0, which is used for exp default.
Now we’ll ping with ToS byte = 160 in decimal, which is CS5.
We see the counters only increase for Tun1. This proves that the CBTS is working.
Also note that the EXP value used for CBTS is after inbound modification, but before outbound modification. (This is logical when you think about it - CBTS happens after the packet is received and before it is transmitted outbound).
IOS-XR Verification
We cannot verify in the data plane on XRv11 using ingress marking. (Ingress marking does not appear to be supported on XRv, as it is a data plane function). However, we can try to verify using ToS on the pings.
First we can use show commands to verify the correct mapping:
Note that unlike IOS-XE, IOS-XR does not let you overlap policy classes. If you try to assign the same EXP value to two tunnels, you will get a commit error.
Also, when no tunnel interface has the default policy-class, whichever tunnel interface has the lowest policy-class number will also implicitly use “policy-class default.”
We can also verify PBTS in the FIB:
From XR13 we ping XR14 with no DSCP value.
We see that only TE tunnel 0 has hits, which uses exp default.
Let’s now set the ToS value to 160 (DSCP CS5):
Unfortunately, the TE1 tunnel counters are not incrementing. It appears this was supported in an older version of XRv which Nick Russo was using, but not this current version. Perhaps this works on XRv9K?
Last updated
