Software versions:
IOS XE 15.5
IOS XR 5.3
The topology for this demo:
In this post we will take a look at the "path option" feature, which essentially determines how the TE tunnel will calculate its path. We can be either really "lazy" or really involved in this process, lazy with using the dynamic option and letting RSVP go out and find the shortest path and pretty much use IGPs path and call it a day. We could also use the explicit path option which allows us to have more control over where the traffic goes. We haven't covered PE to P LSPs yet for things like H-VPLS TE support, what we'll focus on here is R3 to XR3 and XR3 to R3 LSP signalling. The dynamic path option is the easiest and has been used so far in all of our testing so no reason to really break that out here. Let's focus on the explicit path and start there.
There are several ways to "code" the path, the "ip explicit-path" is the primary way. This method allows us to be really specific or be rather general. General in the sense I can give the path certain IPs that must be in the path and the others I may not care about. Other times I could give per interface path IPs and be really specific. Using the "loose" keyword allow us to specify the node we want to go through, but not necessarily how we go through. The strict keyword pretty much says you have to go through it.
Our demo will start with leveraging the loose option and just build a TE tunnel path from R3 to XR3. The path we will take is XR4 to XR1 to R1 to XR5 to XR6 to R2 to XR3, not exactly direct but we want to exercise our capabilities.
R3
ip explicit-path name LOOSE_TO_XR3 enable
next-address loose 192.168.1.14
next-address loose 192.168.1.11
next-address loose 192.168.1.1
next-address loose 192.168.1.15
next-address loose 192.168.1.16
next-address loose 192.168.1.2
next-address loose 192.168.1.13
interface Tunnel4
ip unnumbered Loopback0
tunnel mode mpls traffic-eng
tunnel destination 192.168.1.13
tunnel mpls traffic-eng affinity 0x0 mask 0x0
tunnel mpls traffic-eng path-option 1 explicit name LOOSE_TO_XR3
R3#show mpls traffic-eng tunnels tunnel 4
Name: R3_t4 (Tunnel4) Destination: 192.168.1.13
Status:
Admin: up Oper: up Path: valid Signalling: connected
path option 1, type explicit LOOSE_TO_XR3 (Basis for Setup, path weight 1)
RSVP Path Info:
My Address: 10.14.3.3
Explicit Route: 10.14.3.14 192.168.1.14 192.168.1.11* 192.168.1.1*
192.168.1.15* 192.168.1.16* 192.168.1.2* 192.168.1.13*
Explicit Route: 10.14.3.3 10.14.3.14 10.14.15.14 10.14.15.15
10.15.16.15 10.15.16.16 10.16.2.16 10.16.2.2
10.13.2.2 10.13.2.13 192.168.1.13
As you can see above, we have configured our explicit path to use the TE ID of the nodes in the path to XR3. The * you see next to each of the router IDs is the indication of a loose path. The explicit path noted below the RSVP path is the actual path that will be taken from R3 to XR3.
Now let's take a look at an strict explicit path.
R3
ip explicit-path name STRICT_TO_XR3 enable
next-address 192.168.1.4
next-address 192.168.1.15
next-address 192.168.1.1
next-address 192.168.1.12
next-address 192.168.1.13
interface Tunnel5
ip unnumbered Loopback0
tunnel mode mpls traffic-eng
tunnel destination 192.168.1.13
tunnel mpls traffic-eng priority 4 4
tunnel mpls traffic-eng affinity 0x0 mask 0x0
tunnel mpls traffic-eng path-option 1 explicit name STRICT_TO_XR3
R3#show mpls traffic-eng tunnels tunnel 5
Name: R3_t5 (Tunnel5) Destination: 192.168.1.13
Status:
Admin: up Oper: up Path: valid Signalling: connected
path option 1, type explicit STRICT_TO_XR3 (Basis for Setup, path weight 5)
RSVP Path Info:
My Address: 10.3.4.3
Explicit Route: 10.3.4.4 10.15.4.4 10.15.4.15 10.1.15.15
10.1.15.1 10.1.12.1 10.1.12.12 10.12.13.12
10.12.13.13 192.168.1.13
Explicit Route: 10.14.3.3 10.14.3.14 10.14.15.14 10.14.15.15
10.15.16.15 10.15.16.16 10.16.2.16 10.16.2.2
10.13.2.2 10.13.2.13 192.168.1.13
As you can see, the RSVP path is configured to use R4 to XR5 to R1 to XR2 to XR3. I don't have a static route or other traffic to tunnel mapping mechanism in place for this TE tunnel, so this path is simply a different output to show you the difference. The Other explicit route is the route that falls under the "Shortest Unconstrained Path" in the network, basically, this is the LDP path in the network. The RSVP path is the one that will be followed.
The next option is the "identifier" where state which devices we want the TE tunnel to go through.
ip explicit-path identifier 1 enable
next-address 192.168.1.4
next-address 192.168.1.5
next-address 192.168.1.6
next-address 192.168.1.2
next-address 192.168.1.16
next-address 192.168.1.15
next-address 192.168.1.14
next-address 192.168.1.11
next-address 192.168.1.1
next-address 192.168.1.12
next-address 192.168.1.13
interface Tunnel6
ip unnumbered Loopback0
tunnel mode mpls traffic-eng
tunnel destination 192.168.1.13
tunnel mpls traffic-eng affinity 0x0 mask 0x0
tunnel mpls traffic-eng path-option 1 explicit identifier 1
ip route 192.168.1.13 255.255.255.255 Tunnel6
R3#show mpls traffic-eng tunnels tunnel 6
Name: R3_t6 (Tunnel6) Destination: 192.168.1.13
Status:
Admin: up Oper: up Path: valid Signalling: connected
path option 1, type explicit 1 (Basis for Setup, path weight 11)
RSVP Path Info:
My Address: 10.3.4.3
Explicit Route: 10.3.4.4 10.4.5.4 10.4.5.5 10.5.6.5
10.5.6.6 10.2.6.6 10.2.6.2 10.16.2.2
10.16.2.16 10.15.16.16 10.15.16.15 10.14.15.15
10.14.15.14 10.11.14.14 10.11.14.11 10.1.11.11
10.1.11.1 10.1.12.1 10.1.12.12 10.12.13.12
10.12.13.13 192.168.1.13
This path hits every router in the MPLS core, intentionally configured to show you it could be done that way. I also configured a static route pointing towards XR3 to use Tunnel 6.
R3# traceroute mpls traffic-eng tunnel 6
Type escape sequence to abort.
0 10.3.4.3 MRU 1500 [Labels: 28 Exp: 0]
L 1 10.3.4.4 MRU 1500 [Labels: 42 Exp: 0] 10 ms
L 2 10.4.5.5 MRU 1500 [Labels: 36 Exp: 0] 3 ms
L 3 10.5.6.6 MRU 1500 [Labels: 26 Exp: 0] 5 ms
L 4 10.2.6.2 MRU 1500 [Labels: 24013 Exp: 0] 4 ms
L 5 10.16.2.16 MRU 1500 [Labels: 24014 Exp: 0] 10 ms
L 6 10.15.16.15 MRU 1500 [Labels: 24010 Exp: 0] 17 ms
L 7 10.14.15.14 MRU 1500 [Labels: 24026 Exp: 0] 15 ms
L 8 10.11.14.11 MRU 1500 [Labels: 40 Exp: 0] 18 ms
L 9 10.1.11.1 MRU 1500 [Labels: 24014 Exp: 0] 11 ms
L 10 10.1.12.12 MRU 1500 [Labels: implicit-null Exp: 0] 17 ms
! 11 10.12.13.13 17 ms
Let's do a little recursion to make sure we still know how to figure out where the TE label gets allocated and why.
R3#show ip route 192.168.1.13
Routing entry for 192.168.1.13/32
Known via "static", distance 1, metric 0 (connected)
Routing Descriptor Blocks:
* directly connected, via Tunnel6
Route metric is 0, traffic share count is 1
R3#sh ip cef 192.168.1.13 detail
192.168.1.13/32, epoch 2, flags [attached]
local label info: global/30
3 RR sources [non-eos indirection, heavily shared]
attached to Tunnel6
R3#sh mpls forwarding-table labels 30 detail
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
30 Pop Label 192.168.1.13/32 0 Tu6 point2point
MAC/Encaps=18/22, MRU=1500, Label Stack{28}, via Gi1.34
000C2924DCA2000C29062644810000228847 0001C000
No output feature configured
We will first look at the RIB, we see that traffic to XR3s loopback will be sent out Tunnel 6, if we do a CEF lookup we can see that a local global label of 30 has been allocated to that prefix. We can use that now in the MPLS lookup and see that 30 is the local label, label 28 is the outgoing label and it points out Tunnel 6.
Let's checkout XR3 now, we can also configure path options on XR3. They are almost identical in XR so I'll only show you the TE tunnel to R3 I created to show some basic verification against.
XR3
explicit-path identifier 1
index 1 next-address strict ipv4 unicast 192.168.1.2
index 2 next-address strict ipv4 unicast 192.168.1.6
index 3 next-address strict ipv4 unicast 192.168.1.5
index 4 next-address strict ipv4 unicast 192.168.1.4
index 5 next-address strict ipv4 unicast 192.168.1.3
interface tunnel-te2
ipv4 unnumbered Loopback0
destination 192.168.1.3
affinity ignore
path-option 1 explicit identifier 1
RP/0/0/CPU0:XR3#show mpls traffic-eng tunnels 2
Sun Feb 5 03:18:33.883 UTC
Name: tunnel-te2 Destination: 192.168.1.3 Ifhandle:0x780
Signalled-Name: XR3_t2
Status:
Admin: up Oper: up Path: valid Signalling: connected
Node hop count: 5
Hop0: 10.13.2.2
Hop1: 10.2.6.2
Hop2: 10.2.6.6
Hop3: 10.5.6.6
Hop4: 10.5.6.5
Hop5: 10.4.5.5
Hop6: 10.4.5.4
Hop7: 10.3.4.4
Hop8: 10.3.4.3
Hop9: 192.168.1.3
We can see that the tunnel was successfully signalled and the path was built. Slightly different output from IOS but it still makes sense. I created a static route to point to R3 for verification purposes.
router static
address-family ipv4 unicast
192.168.1.3/32 tunnel-te2
RP/0/0/CPU0:XR3#sh cef 192.168.1.3 detail | in label
Sun Feb 5 03:20:18.416 UTC
local label 24013 labels imposed {ImplNull}
RP/0/0/CPU0:XR3#show mpls traffic-eng forwarding p2p tunnel-id 2 detail
Sun Feb 5 03:21:07.423 UTC
P2P tunnels:
Tunnel ID: 2 LSP ID: 2 Destination: 192.168.1.3 Ctype: 7
Source: 192.168.1.13 Ext Tun ID: 192.168.1.13
Output: Gi0/0/0/0.132 Next Hop: 10.13.2.2 Output Label: 29
Input: - Prev Hop: None Local Label: 24028
RP/0/0/CPU0:XR3#traceroute mpls traffic-eng tunnel-te 2 lsp active
Type escape sequence to abort.
0 10.13.2.13 MRU 1500 [Labels: 29 Exp: 0]
L 1 10.13.2.2 MRU 1500 [Labels: 37 Exp: 0] 0 ms
L 2 10.2.6.6 MRU 1500 [Labels: 43 Exp: 0] 10 ms
L 3 10.5.6.5 MRU 1500 [Labels: 29 Exp: 0] 10 ms
L 4 10.4.5.4 MRU 1500 [Labels: implicit-null Exp: 0] 0 ms
! 5 10.3.4.3 10 ms
The routing table has R3s loopback pointed out Tunnel 2, the CEF output states that local label 24013 will be used. IOS XR has a separate but equally important traffic-eng forwarding table for us to leverage, we see that label 29 will be used for outbound forwarding. A MPLS trace proves that label 29 will be used as the transport label to R3.
As you can see, the path option is very handy in situations like this, being able to manipulate the forwarding is key in modern networks.
Thanks for stopping by!
Rob Riker, CCIE #50693
