IOS XE 15.5
IOS XR 5.3
The topology for this demo:
In this post we will look at using Interface level TE attributes to influence the path that the TE labels will take through the MPLS core. Administrative weight is the closest mechanism to IGP that we can use, so we start with that as most engineers are comfortable with IGP "cost" as the mechanism to forward traffic in the network.
Administrative weight is a method that is configured at the interface level of the P or PE router that is checked when RSVP PATH messages go hop by hop to determine constraints to attributes. With AW, we can use this attribute on interfaces we do not want our TE path to take. This is configurable on both IOS and XR. By default it is 0 and any value above that will make that link look less desirable to the other paths.
IOS
interface GigabitEthernet1.143
mpls traffic-eng administrative-weight 200
XR
mpls traffic-eng
interface GigabitEthernet0/0/0/0.115
admin-weight 200
In this case, we only had to modify a couple routers and 1 interface per router to influence the appropriate path.
Looking at the headend router, we can see the old RSVP path.
R3#sh mpls traffic-eng tunnels tunnel 1 | b RSVP
Explicit Route: 10.14.3.14 10.11.14.14 10.11.14.11 10.1.11.11
10.1.11.1 192.168.1.1
This path says that XR, then XR1 then R1 will be the path from R3 to R1. That works, but this is also the LDP path and the IGP path.
Now, since we have modified the TE interface attributes, we have to re-signal the TE path to make use of the new configuration. We need to bounce TE Tunnel 1. This will trigger an RSVP PATH message to travel from R3 to R1 and each router we configured with the "AW" feature will be seen and that path will not be used.
R3#sh mpls traffic-eng tunnels tunnel 1 | b RSVP
RSVP Signalling Info:
Src 192.168.1.3, Dst 192.168.1.1, Tun_Id 1, Tun_Instance 81
RSVP Path Info:
My Address: 10.3.4.3
Explicit Route: 10.3.4.4 10.15.4.4 10.15.4.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 192.168.1.1
So now the path has grown to include R4, XR5 which were not in the path prior to the AW modification. Before we go and do a rudimentary traceroute to prove the path has changed, let's very some of the basic control plane parts first.
R3#sh ip rsvp reservation detail filter session-type 7 tunnel-id 1 | b Label
Label: 17 (outgoing)
We can see that label 17 is used as the outgoing label for this path.
R3#sh ip route 192.168.1.1
Routing entry for 192.168.1.1/32
Known via "ospf 1", distance 110, metric 4, type intra area
Last update from 10.3.4.4 on GigabitEthernet1.34, 00:01:07 ago
Routing Descriptor Blocks:
* 10.14.3.14, from 192.168.1.1, 00:01:07 ago, via GigabitEthernet1.143
Route metric is 4, traffic share count is 1
10.3.4.4, from 192.168.1.1, 00:01:07 ago, via GigabitEthernet1.34
Route metric is 4, traffic share count is 1
R3#sh ip cef 192.168.1.1 detail
192.168.1.1/32, epoch 2, per-destination sharing
local label info: global/32
3 RR sources [non-eos indirection, heavily shared]
nexthop 10.3.4.4 GigabitEthernet1.34 label 25
nexthop 10.14.3.14 GigabitEthernet1.143 label 24007
R3#sh mpls forwarding-table 192.168.1.1 detail | in Label
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
MAC/Encaps=18/22, MRU=1500, Label Stack{25}
MAC/Encaps=18/22, MRU=1500, Label Stack{24007}
The ironic part is that if you compare the TE label to the LDP label, they are not the same, which means that R3 will use the LDP Label over the TE label, simply because we aren't pointing traffic to the TE tunnel.
R3#traceroute 192.168.1.1 source lo0 num
Type escape sequence to abort.
Tracing the route to 192.168.1.1
VRF info: (vrf in name/id, vrf out name/id)
1 10.14.3.14 [MPLS: Label 24007 Exp 0] 8 msec
10.3.4.4 [MPLS: Label 25 Exp 0] 7 msec
10.14.3.14 [MPLS: Label 24007 Exp 0] 5 msec
2 10.15.4.15 [MPLS: Label 24031 Exp 0] 6 msec
10.11.14.11 [MPLS: Label 24000 Exp 0] 8 msec
10.15.4.15 [MPLS: Label 24031 Exp 0] 5 msec
3 10.1.11.1 9 msec
10.1.15.1 6 msec *
R8#traceroute vrf BGP 13.13.13.13 source 8.8.8.8 num
Type escape sequence to abort.
Tracing the route to 13.13.13.13
VRF info: (vrf in name/id, vrf out name/id)
1 83.0.0.3 3 msec 1 msec 1 msec
2 10.3.4.4 [MPLS: Labels 25/28 Exp 0] 8 msec 7 msec 6 msec
3 10.15.4.15 [MPLS: Labels 24031/28 Exp 0] 28 msec 30 msec 31 msec
4 131.0.0.1 [MPLS: Label 28 Exp 0] 18 msec 14 msec 17 msec
5 131.0.0.13 25 msec * 8 msec
So basically what all the above outputs prove is that until we point MPLS traffic to go over the TE tunnel, it won't be used. I will configure a static route to point to 192.168.1.1/32 over tunnel 1. This will force the usage of the TE tunnel, then we'll compare the above outputs.
R3(config)#ip route 192.168.1.1 255.255.255.255 tunnel1
R3#sh ip route 192.168.1.1
Routing entry for 192.168.1.1/32
Known via "static", distance 1, metric 0 (connected)
Routing Descriptor Blocks:
* directly connected, via Tunnel1
Route metric is 0, traffic share count is 1
R3#sh ip cef 192.168.1.1 detail
192.168.1.1/32, epoch 2, flags [attached]
local label info: global/32
3 RR sources [non-eos indirection, heavily shared]
attached to Tunnel1
R3#sh mpls forwarding-table labels 32 detail
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
32 Pop Label 192.168.1.1/32 0 Tu1 point2point
MAC/Encaps=18/22, MRU=1500, Label Stack{17}, via Gi1.34
000C2924DCA2000C29062644810000228847 00011000
No output feature configured
The local label is 32, but the label stack points to use label 17. Which is the label value allocated by RSVP TE.
R3#sh ip rsvp reservation detail filter session-type 7 tunnel-id 1 | b Label
Label: 17 (outgoing)
So let's go ahead and retrace that same path again and see the difference.
R3#traceroute 192.168.1.1 source lo0 num
Type escape sequence to abort.
Tracing the route to 192.168.1.1
VRF info: (vrf in name/id, vrf out name/id)
1 10.3.4.4 [MPLS: Label 17 Exp 0] 12 msec 7 msec 6 msec
2 10.15.4.15 [MPLS: Label 24000 Exp 0] 13 msec 9 msec 8 msec
3 10.14.15.14 [MPLS: Label 24001 Exp 0] 7 msec 10 msec 20 msec
4 10.11.14.11 [MPLS: Label 24001 Exp 0] 21 msec 8 msec 9 msec
5 10.1.11.1 8 msec
You can see that label 17 points to R4, label 24000 points to XR5, label 24001 points to XR4, label 24001 points to XR1 and then we land on R1.
Let's trace from R8 to R13 and see the output, it should match.
R8#traceroute vrf BGP 13.13.13.13 source 8.8.8.8 num
Type escape sequence to abort.
Tracing the route to 13.13.13.13
VRF info: (vrf in name/id, vrf out name/id)
1 83.0.0.3 2 msec 2 msec 0 msec
2 10.3.4.4 [MPLS: Labels 17/28 Exp 0] 11 msec 10 msec 9 msec
3 10.15.4.15 [MPLS: Labels 24000/28 Exp 0] 23 msec 31 msec 31 msec
4 10.14.15.14 [MPLS: Labels 24001/28 Exp 0] 32 msec 30 msec 32 msec
5 10.11.14.11 [MPLS: Labels 24001/28 Exp 0] 30 msec 30 msec 32 msec
6 131.0.0.1 [MPLS: Label 28 Exp 0] 16 msec 15 msec 16 msec
7 131.0.0.13 19 msec * 12 msec
It matches as expected. Not much more to verify beyond that for this feature. Now the return path from R1 to R3 will use IGP/LDP since there are no TE tunnels configured on R1, yet that is, we'll focus on that as we go.
Thanks for stopping by!
Rob Riker, CCIE #50693
No comments:
Post a Comment