MPLS TE CBTS/PBTS
While MPLS DS-TE addresses control admission for bandwidth on a per-class basis, it does not address the problem of forwarding traffic based on class into separate TE tunnels.
Imagine that you want all voice traffic to go via the top path, and all data traffic to go via bottom path. MPLS TE CBTS (Class Based Tunnel Selection) gives you a very easy way to accomplish this. All you need to do is specify the EXP values you want to match on under the tunnel interface. Because the IPP is automatically mapped to the EXP upon label imposition, you do not need to apply policy-maps anywhere to accomplish class-based TE tunnel selection.
You can preform CBTS for both TE tunnels and DS-TE tunnels, it does not make any difference. Once the tunnel is setup, CBTS simply decides which tunnel to used, based on EXP value, to the given destination.
Lab
I will use the simple topology below to demonstrate CBTS. The provider will provide an L3VPN service to the customer. TTL propagation is enabled which will allow us to trace the path from a CE to verify that tunnel selection is working correctly.
R1 has two TE tunnels with R5 as a destination. Tun0 should forward EXP5 and EXP6 traffic, and Tun1 should be used to forward all other traffic.
The configuration for this is quite simple. You use the tunnel mpls traffic-eng exp command to specify the EXP markings on traffic you want to forward down the tunnel. Multiple EXP markings are separated by a space. The default keyword will match any EXP values not configured on any other tunnels to the same destination.
To use CBTS, you configure a “master” tunnel interface which points to the member tunnel interfaces which are actually signaled. The master tunnel has no path-options and is just a control point for tunnel selection decisions. The master tunnel has autoroute announce and the member tunnels do not. In the configuration above, the master tunnel is tun100.
We can verify that traffic is being steered correctly by running traceroutes from CE1:
The first two traces have an EXP value of 5 and 6, and are steering along the top path. The second two traces have a default DSCP value (zero) and value of AF21 which is mapped to EXP2. These follow the default path (which is the bottom path).
We can verify the tunnel selection configuration using the following show commands:
Quirks of CBTS
IOS does not validate that you have a unique EXP mapping for each member tunnel. This means you can overlap values, and IOS will arbitrarily select a random tunnel for that EXP value.
For example, you can have two member tunnels that are configured for EXP5, or two that are configured for default. One tunnel will randomly be selected for actually forwarding EXP5 traffic, or the unmapped EXP values (default).
Below is an example:
EXP6 is configured for both tun0 and tun1, but is only mapped to tun0.
If tun0 goes down, then tun1 would be used for EXP6 traffic. If there are several member tunnels, then overlapping EXP values might be a strategic engineering choice.
Both tun0 and tun1 are configured for EXP6. The idea is that, as long as one tunnel is up, EXP6 should use either of these tunnels and not tun2.
PBTS (Policy Based Tunnel Selection)
IOS-XR uses PBTS instead of CBTS which is used on IOS-XE. The idea is the same, but it is a little easier to configure on IOS-XR, because no master tunnel is needed.
On IOS-XR you simply list the EXP values you want to forward traffic for using the policy-class command.
You can use the following command to verify the EXP-to-tunnel mappings:
IOS-XR does not let you create multiple tunnels to the same destination that have an overlapping policy-class definition.
Tunnel-te2 uses a policy-class of 5, which overlaps with tunnel-te0 (which has the same destination)
Further Reading
https://www.networkurge.com/2017/06/class-based-tunnel-selection-cbts.html
Last updated