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!