SR is now running but its relying on IGP for the shortest path through the SP core. RSVP-TE is used to choose the best route and not necessarily the shortest path. We'll pretend that the connections between XR1 and XR2, XR3 and XR4 are 10 Gbps connections, the rest of the network is 40 Gbps. The goal is to build a TE tunnel that will take the path XR1 > XR5 > XR6 > XR2 > XR3 > XR7 > XR8 > XR4, which will effectively bypass the slower links. There will also be a backup path option that will be able to take the direct XR1 > XR2 > XR3 > XR4 path.
The first thing that needs to be done is enabling MPLS Traffic Engineering, RSVP and enabling OSPF to support MPLS TE for area 0.
XR1 - XR8
router ospf 1
area 0
mpls traffic-eng
!
mpls traffic-eng router-id Loopback0
XR1
rsvp
interface GigabitEthernet0/0/0/0.112
bandwidth 750000
!
interface GigabitEthernet0/0/0/0.115
bandwidth 750000
!
!
mpls traffic-eng
interface GigabitEthernet0/0/0/0.112
!
interface GigabitEthernet0/0/0/0.115
XR2
rsvp
interface GigabitEthernet0/0/0/0.112
bandwidth 750000
!
interface GigabitEthernet0/0/0/0.123
bandwidth 750000
!
interface GigabitEthernet0/0/0/0.126
bandwidth 750000
!
!
mpls traffic-eng
interface GigabitEthernet0/0/0/0.112
!
interface GigabitEthernet0/0/0/0.123
!
interface GigabitEthernet0/0/0/0.126
XR3
rsvp
interface GigabitEthernet0/0/0/0.123
bandwidth 750000
!
interface GigabitEthernet0/0/0/0.134
bandwidth 750000
!
interface GigabitEthernet0/0/0/0.137
bandwidth 750000
!
!
mpls traffic-eng
interface GigabitEthernet0/0/0/0.123
!
interface GigabitEthernet0/0/0/0.134
!
interface GigabitEthernet0/0/0/0.137
XR4
rsvp
interface GigabitEthernet0/0/0/0.134
bandwidth 750000
!
interface GigabitEthernet0/0/0/0.148
bandwidth 750000
!
!
mpls traffic-eng
interface GigabitEthernet0/0/0/0.134
!
interface GigabitEthernet0/0/0/0.148
XR5
rsvp
interface GigabitEthernet0/0/0/0.115
bandwidth 750000
!
interface GigabitEthernet0/0/0/0.156
bandwidth 750000
!
!
mpls traffic-eng
interface GigabitEthernet0/0/0/0.115
!
interface GigabitEthernet0/0/0/0.156
XR6
rsvp
interface GigabitEthernet0/0/0/0.126
bandwidth 750000
!
interface GigabitEthernet0/0/0/0.156
bandwidth 750000
!
interface GigabitEthernet0/0/0/0.167
bandwidth 750000
!
!
mpls traffic-eng
!
interface GigabitEthernet0/0/0/0.126
!
interface GigabitEthernet0/0/0/0.156
!
interface GigabitEthernet0/0/0/0.167
XR7
rsvp
interface GigabitEthernet0/0/0/0.137
bandwidth 750000
!
interface GigabitEthernet0/0/0/0.167
bandwidth 750000
!
interface GigabitEthernet0/0/0/0.178
bandwidth 750000
!
!
mpls traffic-eng
interface GigabitEthernet0/0/0/0.137
!
interface GigabitEthernet0/0/0/0.167
!
interface GigabitEthernet0/0/0/0.178
XR8
rsvp
interface GigabitEthernet0/0/0/0.148
bandwidth 750000
!
interface GigabitEthernet0/0/0/0.178
bandwidth 750000
!
!
mpls traffic-eng
interface GigabitEthernet0/0/0/0.148
!
interface GigabitEthernet0/0/0/0.178
Now that we have built the TE topology, we can build the unidirectional tunnel from XR1 to XR4 via the path we laid out from above, there should also be another path option that follows the IGP path. The TE tunnel should advertise the TE tunnel as an IGP route.
XR1
explicit-path name SR_TE
index 1 next-address strict ipv4 unicast 192.0.2.25
index 2 next-address strict ipv4 unicast 192.0.2.26
index 3 next-address strict ipv4 unicast 192.0.2.22
index 4 next-address strict ipv4 unicast 192.0.2.23
index 5 next-address strict ipv4 unicast 192.0.2.27
index 6 next-address strict ipv4 unicast 192.0.2.28
index 7 next-address strict ipv4 unicast 192.0.2.24
!
interface tunnel-te1
ipv4 unnumbered Loopback0
autoroute announce
!
destination 192.0.2.24
path-option 5 explicit name SR_TE segment-routing
path-option 10 segment-routing
RP/0/0/CPU0:XR1#sh ip int br
tunnel-te1 192.0.2.21 Up Up default
We can see that the tunnel was signaled successfully, if it wasn't the tunnel wouldn't not become up/up.
RP/0/0/CPU0:XR1#show mpls traffic-eng tunnels 1
Thu May 10 22:34:29.600 UTC
Name: tunnel-te1 Destination: 192.0.2.24 Ifhandle:0x680
Signalled-Name: XR1_t1
Status:
Admin: up Oper: up Path: valid Signalling: connected
path option 5, (Segment-Routing) type explicit SR_TE (Basis for Setup)
Protected-by PO index: none
path option 10, type segment-routing
G-PID: 0x0800 (derived from egress interface properties)
Bandwidth Requested: 0 kbps CT0
Creation Time: Thu May 10 21:31:07 2018 (01:03:23 ago)
Config Parameters:
Bandwidth: 0 kbps (CT0) Priority: 7 7 Affinity: 0x0/0xffff
Metric Type: TE (default)
Path Selection:
Tiebreaker: Min-fill (default)
Protection: any (default)
Hop-limit: disabled
Cost-limit: disabled
Path-invalidation timeout: 10000 msec (default), Action: Tear (default)
AutoRoute: enabled LockDown: disabled Policy class: not set
Forward class: 0 (default)
Forwarding-Adjacency: disabled
Loadshare: 0 equal loadshares
Auto-bw: disabled
Path Protection: Not Enabled
BFD Fast Detection: Disabled
Reoptimization after affinity failure: Enabled
SRLG discovery: Disabled
History:
Tunnel has been up for: 01:03:22 (since Thu May 10 21:31:08 UTC 2018)
Current LSP:
Uptime: 00:52:10 (since Thu May 10 21:42:20 UTC 2018)
Prior LSP:
ID: 2 Path Option: 10
Removal Trigger: reoptimization completed
Segment-Routing Path Info (OSPF 1 area 0)
Segment0[Node]: 192.0.2.25, Label: 16025
Segment1[Node]: 192.0.2.26, Label: 16026
Segment2[Node]: 192.0.2.22, Label: 16022
Segment3[Node]: 192.0.2.23, Label: 16023
Segment4[Node]: 192.0.2.27, Label: 16027
Segment5[Node]: 192.0.2.28, Label: 16028
Segment6[Node]: 192.0.2.24, Label: 16024
Displayed 1 (of 1) heads, 0 (of 0) midpoints, 0 (of 0) tails
Displayed 1 up, 0 down, 0 recovering, 0 recovered heads
The MPLS TE tunnel output shows that SR is being used to build the tunnel, meaning that SR labels will be used and not RSVP-TE which would be labels starting at 24000 and above. The current path being leveraged is option 5, the explicit path, which is defined above.
RP/0/0/CPU0:XR1#sh route 192.0.2.24
Thu May 10 22:35:40.545 UTC
Routing entry for 192.0.2.24/32
Known via "ospf 1", distance 110, metric 4, labeled SR, type intra area
Installed May 10 21:31:09.200 for 01:04:31
Routing Descriptor Blocks
192.0.2.24, from 192.0.2.24, via tunnel-te1
Route metric is 4
No advertising protos.
Expanding the route to XR4's loopback, we see that the path now follows the TE1 path and is using a labeled SR path.
RP/0/0/CPU0:XR1#sh cef 192.0.2.24
Thu May 10 22:35:56.954 UTC
192.0.2.24/32, version 46, internal 0x1000001 0x1 (ptr 0xa12b3a74) [1], 0x0 (0xa127f584), 0xa20 (0xa150d320)
Updated May 10 21:31:09.460
Prefix Len 32, traffic index 0, precedence n/a, priority 3
via 192.0.2.24/32, tunnel-te1, 7 dependencies, weight 0, class 0 [flags 0x0]
path-idx 0 NHID 0x0 [0xa0f164f0 0xa0f16154]
next hop 192.0.2.24/32
local adjacency
local label 24007 labels imposed {ImplNull}
Looking at the CEF table we can see label 24007 was allocated as adjacency SID since the TE1 tunnel is a new tunnel and therefore a label needs to be allocated.
RP/0/0/CPU0:XR1#sh mpls forwarding labels 24007
Thu May 10 22:50:33.174 UTC
Local Outgoing Prefix Outgoing Next Hop Bytes
Label Label or ID Interface Switched
------ ----------- ------------------ ------------ --------------- ------------
24007 Pop 192.0.2.24/32 tt1 192.0.2.24 0
We can prove that by looking at what label 24007 was applied to, in this case it is the TE tunnel.
Once the tunnel is up, re-optimization maybe needed to take the explicit path.
RP/0/0/CPU0:XR1#mpls traffic-eng reoptimize 1
Now that we have a TE tunnel up and running, the routing table shows that traffic towards XR4 will take the TE tunnel. Let's do a trace from XR1 to XR4 and see what happens.
RP/0/0/CPU0:XR1#traceroute 192.0.2.24 source 192.0.2.21 num
Thu May 10 22:36:40.701 UTC
Type escape sequence to abort.
Tracing the route to 192.0.2.24
1 100.64.115.15 [MPLS: Labels 16026/16022/16023/16027/16028/16024 Exp 0] 139 msec 119 msec 109 msec
2 100.64.156.16 [MPLS: Labels 16022/16023/16027/16028/16024 Exp 0] 119 msec 109 msec 149 msec
3 100.64.126.12 [MPLS: Labels 16023/16027/16028/16024 Exp 0] 119 msec 119 msec 119 msec
4 100.64.123.13 [MPLS: Labels 16027/16028/16024 Exp 0] 129 msec 109 msec 119 msec
5 100.64.137.17 [MPLS: Labels 16028/16024 Exp 0] 109 msec 119 msec 119 msec
6 100.64.178.18 [MPLS: Label 16024 Exp 0] 119 msec 129 msec 109 msec
7 100.64.148.14 109 msec * 109 msec
We can see that the TE tunnel is being taken with the 7 SR label stack. This stack is encoded as it hits the ingress PE.
R1#ping 192.0.2.2 source lo0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.0.2.2, timeout is 2 seconds:
Packet sent with a source address of 192.0.2.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 80/86/90 ms
R1#traceroute 192.0.2.2 source lo0 num
Type escape sequence to abort.
Tracing the route to 192.0.2.2
VRF info: (vrf in name/id, vrf out name/id)
1 100.64.101.11 19 msec 7 msec 10 msec
2 100.64.115.15 [MPLS: Labels 16026/16022/16023/16027/16028/16024/24004 Exp 0] 131 msec 133 msec 126 msec
3 100.64.156.16 [MPLS: Labels 16022/16023/16027/16028/16024/24004 Exp 0] 143 msec 134 msec 123 msec
4 100.64.126.12 [MPLS: Labels 16023/16027/16028/16024/24004 Exp 0] 143 msec 129 msec 124 msec
5 100.64.123.13 [MPLS: Labels 16027/16028/16024/24004 Exp 0] 140 msec 133 msec 126 msec
6 100.64.137.17 [MPLS: Labels 16028/16024/24004 Exp 0] 141 msec 138 msec 124 msec
7 100.64.178.18 [MPLS: Labels 16024/24004 Exp 0] 135 msec 132 msec 128 msec
8 100.64.148.14 [MPLS: Label 24004 Exp 0] 130 msec 133 msec 127 msec
9 100.64.103.2 133 msec * 136 msec
We see that in the above ping worked, but that doesn't showcase the SR TE output. The traceroute showcases the SR TE stack. The screenshot shows that the entire stack is encoded as traffic enters the SP core.
Thanks for stopping by!
Rob Riker, CCIE #50693
No comments:
Post a Comment