Class Based Tunnel Selection
In this post i would like to demonstrate the Class-Based Tunnel Selection feature.
In class-based tunnel selection, we will select an MPLS TE tunnel based on the incomming Precedence bit in the data.
For example, IP Prec 5 goes to TE Tunnel 1, whereas IP Prec 3 goes to TE Tunnel 2.
This sort of thing would be very useful for the SP if SLA’s are offered based on the incomming data. Think of voice for example. IP Prec 5 marked traffic would be voice and as it enters the SP network it automatically gets sent down the appropriate tunnel.
For the example, i will be using the topology shown in Figure 1.
The entire L2 VPN has been setup already so we will just focus on the TE Tunnels.
Topology for CB Tunnel Selection
Figure 1 outlines a typical SP network, with a customer using its L3 VPN service.
The end result is that we want to differentiate the tunnel selection based on what traffic enters PE-1 from CE-1 going to CE-2.
I will be using 3 IP Prec values:
0 = Best Effort
3 = High priority Data
5 = Voice
We will need their decimal values when we issue ICMP Pings from CE-1 to CE-2, so here they are:
0 = 0 = 0
3 = 011 000 00 = 96
5 = 101 000 00 = 160
I will be using 3 Tunnels originating from PE-1 terminating at PE-2.
These tunnels will be used to carry traffic with the 3 different IP Precedence values.
Tunnel 1 will go from PE-1 to P1 to PE-2.
Tunnel 2 will go from PE-1 to P2 to P3 to PE-2.
Tunnel 3 will go from PE-1 to P4 to PE-2.
Note that Tunnel 1 will carry IP Prec 0, but also all the other unassigned values (1, 2, 4, 6 and 7).
This tunnel layout can be seen in Figure 2
Topology with tunnels
On top of that i will be using Tunnel100 to be the “master” of the other three.
This tunnel will control which Tunnel member will be used for the forwarding.
Remember that TE tunnels are unidirectional. That means that the traffic engineering we are doing
here is only from PE-1 to PE-2, not from PE-2 to PE-1.
In the real world you would ofcourse do it both ways.
Lets take a look at the tunnel definitions on PE-1:
interface Tunnel1 ip unnumbered Loopback0 tunnel destination 7.7.7.7 tunnel mode mpls traffic-eng tunnel mpls traffic-eng path-option 10 explicit name TUNNEL1-PATH tunnel mpls traffic-eng exp 0 end interface Tunnel2 ip unnumbered Loopback0 tunnel destination 7.7.7.7 tunnel mode mpls traffic-eng tunnel mpls traffic-eng path-option 10 explicit name TUNNEL2-PATH tunnel mpls traffic-eng exp 3 end interface Tunnel3 ip unnumbered Loopback0 tunnel destination 7.7.7.7 tunnel mode mpls traffic-eng tunnel mpls traffic-eng path-option 10 explicit name TUNNEL3-PATH tunnel mpls traffic-eng exp 5 end
And then the “main” tunnel:
interface Tunnel100 ip unnumbered Loopback0 tunnel destination 7.7.7.7 tunnel mode mpls traffic-eng tunnel mpls traffic-eng autoroute announce tunnel mpls traffic-eng exp-bundle master tunnel mpls traffic-eng exp-bundle member Tunnel1 tunnel mpls traffic-eng exp-bundle member Tunnel2 tunnel mpls traffic-eng exp-bundle member Tunnel3
We can issue the command: “show mpls traffic-eng exp” to verify our tunnel setup on PE-1:
PE-1#sh mpls traffic-eng exp Destination: 7.7.7.7 Master: Tunnel100 Status: up Members Status Conf Exp Actual Exp Tunnel1 up (Active) 0 0 1 2 4 6 7 Tunnel2 up (Active) 3 3 Tunnel3 up (Active) 5 5
Everything looks as we expected. Tunnel 1 handles every but Prec 3 and 5.
Tunnel 2 handles Prec 3 and Tunnel 3 handles Prec 5.
We can verify on CE-1 and CE-2 that we are seeing the routes we expect through the L3 VPN.
on CE-1:
CE-1#sh ip route | beg Gate Gateway of last resort is not set C 192.168.12.0/24 is directly connected, FastEthernet0/0 1.0.0.0/32 is subnetted, 1 subnets C 1.1.1.1 is directly connected, Loopback0 R 192.168.78.0/24 [120/10] via 192.168.12.2, 00:00:13, FastEthernet0/0 8.0.0.0/32 is subnetted, 1 subnets R 8.8.8.8 [120/10] via 192.168.12.2, 00:00:13, FastEthernet0/0
and on CE-2:
CE-2#sh ip route | beg Gate Gateway of last resort is not set R 192.168.12.0/24 [120/10] via 192.168.78.7, 00:00:07, FastEthernet0/0 1.0.0.0/32 is subnetted, 1 subnets R 1.1.1.1 [120/10] via 192.168.78.7, 00:00:07, FastEthernet0/0 C 192.168.78.0/24 is directly connected, FastEthernet0/0 8.0.0.0/32 is subnetted, 1 subnets C 8.8.8.8 is directly connected, Loopback0
We can verify that our data forwarding works, by enabling “debug mpls pack” on P1, P2 and P4.
When we ping from CE-1 to CE-2 (using loopbacks), with the value 0, we expect to see traffic going through P1:
On CE-1:
CE-1#ping 8.8.8.8 so loo0 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds: Packet sent with a source address of 1.1.1.1 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 56/65/76 ms
At the same time on P1:
*Sep 30 09:20:34.355: MPLS turbo: Fa1/0: rx: Len 122 Stack {310 0 254} {709 0 254} - ipv4 data
*Sep 30 09:20:34.355: MPLS turbo: Fa1/1: tx: Len 118 Stack {709 0 253} - ipv4 data
*Sep 30 09:20:34.427: MPLS turbo: Fa1/0: rx: Len 122 Stack {310 0 254} {709 0 254} - ipv4 data
*Sep 30 09:20:34.427: MPLS turbo: Fa1/1: tx: Len 118 Stack {709 0 253} - ipv4 data
*Sep 30 09:20:34.511: MPLS turbo: Fa1/0: rx: Len 122 Stack {310 0 254} {709 0 254} - ipv4 data
*Sep 30 09:20:34.511: MPLS turbo: Fa1/1: tx: Len 118 Stack {709 0 253} - ipv4 data
*Sep 30 09:20:34.575: MPLS turbo: Fa1/0: rx: Len 122 Stack {310 0 254} {709 0 254} - ipv4 data
If we then perform the same ping from CE-1, but with the IP Prec value of 3 (96 decimal), we expect the traffic to be on P2 instead:
on CE-1:
CE-1#ping Protocol [ip]: Target IP address: 8.8.8.8 Repeat count [5]: Datagram size [100]: Timeout in seconds [2]: Extended commands [n]: y Source address or interface: loopback0 Type of service [0]: 96 Set DF bit in IP header? [no]: Validate reply data? [no]: Data pattern [0xABCD]: Loose, Strict, Record, Timestamp, Verbose[none]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds: Packet sent with a source address of 1.1.1.1 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 52/64/84 ms
And sure enough, on P2:
*Sep 30 09:23:22.879: MPLS turbo: Fa1/0: rx: Len 122 Stack {410 3 254} {709 3 254} - ipv4 data
*Sep 30 09:23:22.879: MPLS turbo: Fa1/1: tx: Len 122 Stack {510 3 253} {709 3 254} - ipv4 data
*Sep 30 09:23:22.959: MPLS turbo: Fa1/0: rx: Len 122 Stack {410 3 254} {709 3 254} - ipv4 data
*Sep 30 09:23:22.959: MPLS turbo: Fa1/1: tx: Len 122 Stack {510 3 253} {709 3 254} - ipv4 data
*Sep 30 09:23:23.023: MPLS turbo: Fa1/0: rx: Len 122 Stack {410 3 254} {709 3 254} - ipv4 data
*Sep 30 09:23:23.023: MPLS turbo: Fa1/1: tx: Len 122 Stack {510 3 253} {709 3 254} - ipv4 data
*Sep 30 09:23:23.087: MPLS turbo: Fa1/0: rx: Len 122 Stack {410 3 254} {709 3 254} - ipv4 data
Finally, lets verify with IP Prec 5 (160 decimal), we want to see the traffic hit P4:
on P4:
P4#Sep 30 09:25:10.959: MPLS turbo: Fa1/0: tx: Len 118 Stack {209 5 253} - ipv4 data
*Sep 30 09:25:10.991: MPLS turbo: Fa1/0: rx: Len 122 Stack {610 5 254} {709 5 254} - ipv4 data
*Sep 30 09:25:10.991: MPLS turbo: Fa1/1: tx: Len 118 Stack {709 5 253} - ipv4 data
*Sep 30 09:25:11.023: MPLS turbo: Fa1/1: rx: Len 122 Stack {604 5 254} {209 5 254} - ipv4 data
*Sep 30 09:25:11.023: MPLS turbo: Fa1/0: tx: Len 118 Stack {209 5 253} - ipv4 data
*Sep 30 09:25:11.055: MPLS turbo: Fa1/0: rx: Len 122 Stack {610 5 254} {709 5 254} - ipv4 data
*Sep 30 09:25:11.055: MPLS turbo: Fa1/1: tx: Len 118 Stack {709 5 253} - ipv4 data
*Sep 30 09:25:11.083: MPLS turbo: Fa1/1: rx: Len 122 Stack {604 5 254} {209 5 254} - ipv4 data
*Sep 30 09:25:11.083: MPLS turbo: Fa1/0: tx: Len 118 Stack {209 5 253} - ipv4 data
Excellent! – So depending on how the traffic is marked comming from our customer, we will use different TE tunnels to forward the data through our SP core.
Thats all i had for now. Take care!