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:
CE1#traceroute 10.2.2.2 sou lo0 probe 1 dscp 46
Type escape sequence to abort.
Tracing the route to 10.2.2.2
VRF info: (vrf in name/id, vrf out name/id)
1 100.64.0.1 1 msec
2 10.1.2.2 [MPLS: Labels 16/24000 Exp 5] 3 msec
3 10.2.5.5 6 msec
CE1#
CE1#traceroute 10.2.2.2 sou lo0 probe 1 dscp 51
Type escape sequence to abort.
Tracing the route to 10.2.2.2
VRF info: (vrf in name/id, vrf out name/id)
1 100.64.0.1 2 msec
2 10.1.2.2 [MPLS: Labels 16/24000 Exp 6] 3 msec
3 10.2.5.5 8 msec
CE1#
CE1#traceroute 10.2.2.2 sou lo0 probe 1 dscp 0
Type escape sequence to abort.
Tracing the route to 10.2.2.2
VRF info: (vrf in name/id, vrf out name/id)
1 100.64.0.1 2 msec
2 10.1.3.3 [MPLS: Labels 24000/24000 Exp 0] 9 msec
3 10.3.4.4 [MPLS: Labels 24000/24000 Exp 0] 8 msec
4 10.4.5.5 14 msec
CE1#
CE1#traceroute 10.2.2.2 sou lo0 probe 1 dscp 18
Type escape sequence to abort.
Tracing the route to 10.2.2.2
VRF info: (vrf in name/id, vrf out name/id)
1 100.64.0.1 2 msec
2 10.1.3.3 [MPLS: Labels 24000/24000 Exp 2] 7 msec
3 10.3.4.4 [MPLS: Labels 24000/24000 Exp 2] 7 msec
4 10.4.5.5 9 msec
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:
R1#show mpls traffic-eng exp 5.5.5.5
Destination: 5.5.5.5
Master: Tunnel100 Status: up
Members Status Conf Exp Actual Exp
Tunnel0 up (Active) 5 6 5 6
Tunnel1 up (Active) Default 0 1 2 3 4 7
(D) : Destination is different
(NE): Exp values not configured on tunnel
R1#
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:
interface Tunnel0
tunnel mpls traffic-eng exp 5 6
!
interface Tunnel1
tunnel mpls traffic-eng exp 6 default
R1#show mpls traffic-eng exp 5.5.5.5
Destination: 5.5.5.5
Master: Tunnel100 Status: up
Members Status Conf Exp Actual Exp
Tunnel0 up (Active) 5 6 5 6
Tunnel1 up (Active) 6 Default 0 1 2 3 4 7
(D) : Destination is different
(NE): Exp values not configured on tunnel
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.
interface Tunnel0
tunnel mpls traffic-eng exp 5 6
!
interface Tunnel1
tunnel mpls traffic-eng exp 6
!
interface Tunnel1
tunnel mpls traffic-eng exp default
R1#show mpls traffic-eng exp 5.5.5.5
Destination: 5.5.5.5
Master: Tunnel100 Status: up
Members Status Conf Exp Actual Exp
Tunnel0 down 5 6
Tunnel1 up (Active) 6 6
Tunnel2 up (Active) Default 0 1 2 3 4 5 7
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.
IOS-XR does not let you create multiple tunnels to the same destination that have an overlapping policy-class definition.
interface tunnel-te0
policy-class 5 6
!
interface tunnel-te1
policy-class default
RP/0/RP0/CPU0:XR(config)#show
Sun Nov 20 23:55:10.150 UTC
Building configuration...
!! IOS XR Configuration 7.2.2
interface tunnel-te2
ipv4 unnumbered Loopback0
autoroute announce
!
destination 1.1.1.1
policy-class 5
!
end
RP/0/RP0/CPU0:XR(config)#commit
Sun Nov 20 23:55:13.514 UTC
% Failed to commit one or more configuration items during a pseudo-atomic operation. All changes made have been reverted. Please issue 'show configuration failed [inheritance]' from this session to view the errors
RP/0/RP0/CPU0:XR(config)#show config failed
Sun Nov 20 23:55:16.115 UTC
!! SEMANTIC ERRORS: This configuration was rejected by
!! the system due to semantic errors. The individual
!! errors with each failed configuration command can be
!! found below.
interface tunnel-te2
policy-class 5
!!% Invalid or corrupt data was supplied to TE: overlapping policy-class config conflict
!
end
RP/0/RP0/CPU0:XR(config)#
Tunnel-te2 uses a policy-class of 5, which overlaps with tunnel-te0 (which has the same destination)
