IOS XE 15.5
IOS XR 5.3
The topology for this demo:
In this post we will take a look at configuring bandwidth on IOS XR, it's very similar operationally to IOS so I won't go dig into the details as deep as it's really all the same, slightly different outputs. One thing I did notice between the previous post and this, which could negatively effect operations in the network. Remember that MPLS TE tunnels are unidirectional, and are always signalled in a head end to tail end manner. In this scenario, I configured a TE tunnel from XR3 to R3, used the same TE attributes as the last post, config output below. The tunnel forms without any issue, but which path it uses to form the TE tunnel raises an interesting situation I wasn't prepared for.
XR3
interface tunnel-te1
bandwidth 200000
ipv4 unnumbered Loopback0
priority 7 7
destination 192.168.1.3
affinity 0x10 mask 0x10
path-option 1 dynamic
So with the above configuration, the TE tunnel does form relatively quickly. One mechanism used by MPLS TE tunnels is the concept of "make before break" where a tunnel has to be first signaled end to end, ensuring that the attributes can be met and then then tunnel will form. If there is a case, covered in the next post, where another tunnel has a higher priority or if the LSP has FRR setup on it, that the primary LSP will not be broken before the higher priority tunnel is built and ready or the FRR tunnel is also built and ready. This prevents the blackholing in the MPLS core.
RP/0/0/CPU0:XR3#sh mpls traffic-eng tunnels 1
Sat Jan 28 01:51:41.499 UTC
Name: tunnel-te1 Destination: 192.168.1.3 Ifhandle:0x680
Signalled-Name: XR3_t1
Status:
Admin: up Oper: up Path: valid Signalling: connected
Path info (OSPF 1 area 0):
Node hop count: 5
Hop0: 10.12.13.12
Hop1: 10.12.16.12
Hop2: 10.12.16.16
Hop3: 10.15.16.16
Hop4: 10.15.16.15
Hop5: 10.15.4.15
Hop6: 10.15.4.4
Hop7: 10.3.4.4
Hop8: 10.3.4.3
Hop9: 192.168.1.3
Resv Info: None
Record Route: Disabled
Fspec: avg rate=200000 kbits, burst=1000 bytes, peak rate=200000 kbits
Displayed 1 (of 1) heads, 0 (of 0) midpoints, 1 (of 2) tails
Displayed 1 up, 0 down, 0 recovering, 0 recovered heads
R3 uses the XR2 to XR3 link to terminate it's TE LSPs on XR3. Which let's us achieve the 2 connections we need with the bandwidth reservation and the affinity values specified. After I had finished the last post, I created a third tunnel with then intention of TE simply directing the third tunnel out the G1.34 link to R4. But when I watched the debugs roll by, I would see the entire path getting signalled until XR3 was reached and then an Admission control error was thrown. I was a bit baffled at first, so I slowly lowered the reservation amount down from 400 Mbps to 100 Mbps, no joy.
I went to XR3 to see if I had missed something, that is when I spotted the issue, both the TE LSPs R3 had connected to XR3 where coming in on XR3s link to XR2, and the sum total of the bandwidth was 750 Mbps. Well, I found the issue, which then lead me to create a TE tunnel on XR3 back to R3, figuring it had to bypass the max'd out link to XR2 and use the path through R2 instead, not the case, to my surprise the tunnel came up with no issue. Remember, TE LSP are unidirectional. So even though the TE LSP was signalled and formed, there would be a contention spot in the network because of this.
I have 3 solutions to solve this, 1, modify the affinity values to not match on "BROWN" links but to exclude "BLACK" links, thus eliminating the XR2 to XR3 path or, 2, use priority to force the R3 to XR3 tunnel with 100 Mbps to be decommissioned in favor of the higher priority link or, 3, tell TE not to take affinity into consideration. I chose this option as it is the easiest.
interface tunnel 3
tunnel mpls traffic-eng affinity 0x0 mask 0x0
However the path still fails, this is because path wise, I could use admin weight or an explicit path to override this operation. If RSVP tries to use the G0/0/0/0.1213 link, the bandwidth reservation will not be met. Which means that XR3s tunnel R3 will form as the path from XR3 to R3 only has a 200 Mbps reservation and it isn't seeing the incoming TE reservation due to the TE tunnel being unidirectional. Instead, we'll finish verifying XR3s TE tunnel and I'll fix the R3 issue in the next post.
RP/0/0/CPU0:XR3#sh rsvp reservation session-type lsp-p2p detail destination 19$
Sat Jan 28 02:26:56.304 UTC
Input adjusted interface: Gi0/0/0/0.1213. Input physical interface: Gi0/0/0/0.1213.
Labels: Outgoing downstream: 24014.
RP/0/0/CPU0:XR3#sh mpls traffic-eng forwarding tunnel-id 1
Sat Jan 28 02:28:02.429 UTC
P2P tunnels:
Tunnel ID Ingress IF Egress IF In lbl Out lbl Backup
-------------------------- -------------- -------------- ------- ------- -------
192.168.1.13 1_2 - Gi0/0/0/0.1213 24023 24014 unknown
Displayed 1 tunnel heads, 0 label P2P rewrites
Displayed 0 tunnel heads, 0 label P2MP rewrites
We can see that the outgoing label value is 24014, and that shows up in the below traffic-eng traceroute.
RP/0/0/CPU0:XR3#traceroute mpls traffic-eng tunnel-te 1 lsp active
Type escape sequence to abort.
0 10.12.13.13 MRU 1500 [Labels: 24014 Exp: 0]
L 1 10.12.13.12 MRU 1500 [Labels: 24013 Exp: 0] 10 ms
L 2 10.12.16.16 MRU 1500 [Labels: 24004 Exp: 0] 10 ms
L 3 10.15.16.15 MRU 1500 [Labels: 18 Exp: 0] 10 ms
L 4 10.15.4.4 MRU 1500 [Labels: implicit-null Exp: 0] 10 ms
! 5 10.3.4.3 10 ms
So you can see that the TE tunnel is up and working. We have signaled a tunnel, but haven't actually gone and mapped traffic to it. But its working.
Thanks for stopping by!
Rob Riker, CCIE #50693
