Now that we’ve enabled SR for OSPF, let’s see how SR works with ISIS.
As a reminder, here is our lab topology:
On R1, remove OSPF and configure ISIS, then enable SR for ISIS. The manual prefix-sid index value for the loopback will remain under the segment-routing configuration stanza. We must enable wide-metrics, as the prefix-SID and adjacency SIDs are advertised under the extended IP reachability TLVs.
#R1
no router ospf 1
!
router isis
net 49.0001.0000.0000.0001.00
is-type level-2-only
segment-routing mpls
metric-style wide
!
int Gi1
no ip ospf network point-to-point
ip router isis
isis network point-to-point
!
int Lo0
ip router isis
Even before we enable ISIS on R2, we can see SR information under the R1.00-00 LSP:
We can see the prefix-SID index for Lo0, but we see no label for the adjacency SID for Gi1. While Gi1 is enabled for ISIS, no neighbor has been discovered yet.
The I:1 and V:0 under the router capabililties indicate MPLS IPv4 and MPLS IPv6 support. I is used for the MPLS IPv4 flag, and when it is set (as it is above), it indicates the router supports SR MPLS encapsulated IPv4 packets. V indicates support for SR MPLS encapsulated IPv6 packets.
The flags under the prefix 1.1.1.1/32 indicate the following:
R - Re-advertisement. Set only if the prefix has been propagated from another level
N - Node-SID. Set if the prefix represents the node, which it does in this case.
P - PHP-Off. Set only if the router is requesting its neighbors turn PHP off. This is not set, so the neighbors will preform the normal PHP functionality and pop the label.
E - Explicit-Null. Set if the router is requesting to see the explicit-null label which is usually used to preseve the MPLS EXP bits for QoS. If this is set, then the P flag must also be set, as PHP needs to be turned off too.
V - Value. Set if the Prefix SID has a label value instead of an index. You should never see this set.
L - Local. Set if the prefix SID only has local significance. You should never see this set, as the prefix SID is always global.
Let’s do the same change on R2 and then capture the LSPs advertised between R1 and R2. For brevity I won’t include the R2 commands.
Here is the R1.00-00 LSP:
The following TLVs enable SR: Router Capability, Extended IS Reachability, and Extended IP Reachability. Like OSPF, even though we have not enabled MPLS-TE, we still see TE information on under Extended IS Reachability.
Let’s now enable SR for ISIS on XR3. As a reminder, all SR config is under the IGP configuration on IOS-XR. For ISIS on XR, SR is enabled under the address-family.
#XR3
no router ospf 1
!
router isis 1
net 49.0001.0000.0000.0003.00
is-type level-2-only
address-family ipv4 unicast
segment-routing mpls
metric-style wide
exit
int Gi0/0/0/0
point-to-point
address-family ipv4 unicast
int Gi0/0/0/1
point-to-point
address-family ipv4 unicast
int Gi0/0/0/2
point-to-point
address-family ipv4 unicast
int Lo0
address-family ipv4 unicast
prefix-sid index 3
Enable SR for ISIS on all other routers.
Examine the LFIB on XR3 again. It should be almost identical to the LFIB as with OSPF in the previous article. The only difference is the local label allocations for the adjacencies.
XR3#show mpls forwarding
Sat Aug 20 22:42:32.730 UTC
Local Outgoing Prefix Outgoing Next Hop Bytes
Label Label or ID Interface Switched
------ ----------- ------------------ ------------ --------------- ------------
16001 16001 SR Pfx (idx 1) Gi0/0/0/1 10.2.3.2 0
16002 Pop SR Pfx (idx 2) Gi0/0/0/1 10.2.3.2 0
16004 Pop SR Pfx (idx 4) Gi0/0/0/0 10.3.4.4 0
16005 16005 SR Pfx (idx 5) Gi0/0/0/2 10.3.6.6 0
16006 Pop SR Pfx (idx 6) Gi0/0/0/2 10.3.6.6 0
24003 Pop SR Adj (idx 1) Gi0/0/0/1 10.2.3.2 0
24004 Pop SR Adj (idx 3) Gi0/0/0/1 10.2.3.2 0
24005 Pop SR Adj (idx 1) Gi0/0/0/0 10.3.4.4 0
24006 Pop SR Adj (idx 3) Gi0/0/0/0 10.3.4.4 0
24007 Pop SR Adj (idx 1) Gi0/0/0/2 10.3.6.6 0
24008 Pop SR Adj (idx 3) Gi0/0/0/2 10.3.6.6 0
On IOS-XR, two adjacency SIDs are allocated per adjacency by default. One is a fast-reroute protected adjacency SID, and one is unprotected. If another router uses the label for the protected one, and the link on the local router goes down, it will automatically fast-reroute around the failure. It is “protected” against failure using FRR. We have not enabled FRR but the IOS-XR router still reserves the label for it. It does not advertise the protected adjacency-SID label into the IGP until you enable FRR.
You can see which is the protected (FRR) adjacency SID and which is the non-FRR adjacency SID using the following show command:
XR3#show isis adjacency detail Gi0/0/0/1
Mon Aug 22 14:06:08.095 UTC
IS-IS 1 Level-2 adjacencies:
System Id Interface SNPA State Hold Changed NSF IPv4 IPv6
BFD BFD
R2 Gi0/0/0/1 *PtoP* Up 26 1d15h Yes None None
Area Address: 49.0001
Neighbor IPv4 Address: 10.2.3.2*
Adjacency SID: 24003
Non-FRR Adjacency SID: 24004
Topology: IPv4 Unicast
Total adjacency count: 1
You may have noticed in the previous output of the LFIB that the prefix SIDs conveniently show you the index number in paraenthesis. For example, 16004 shows SR Pfx (idx 4). For adjacency SIDs, the index value has nothing to do with the index in the SRGB, as the adjacency SIDs are local segments anyways. Index 1 and index 3 refers to something internal within the IGP so you can ignore this. If you are curious how this works:
Index 0 = Protected adjacency SID for level-1
Index 1 = Protected adjacency SID for level-2
Index 2 = Non-protected adjacency SID for level-1
Index 3 = Non-protected adjacency SID for level-2
You can also see that when you enable SR for the MPLS dataplane under the IGP with the command segment-routing mpls, MPLS is enabled for each IGP-enabled interface.
R2#show mpls interfaces
Interface IP Tunnel BGP Static Operational
GigabitEthernet1 No No No No Yes
GigabitEthernet2 No No No No Yes
GigabitEthernet3 No No No No Yes
My guess is that this command came out before SR, so there is no SR column. MPLS is operational but it is not enabled via IP (LDP), Tunnel (RSVP), BGP (BGP-LU) or Static. So by process of elimination, it must be enabled via SR according to this output.
Let’s generate some mpls traffic and verify the LSPs.
First on R1, do an mpls traceroute to R4:
R1#traceroute mpls ipv4 4.4.4.4/32 source 1.1.1.1
Tracing MPLS Label Switched Path to 4.4.4.4/32, timeout is 2 seconds
Codes: '!' - success, 'Q' - request not sent, '.' - timeout,
'L' - labeled output interface, 'B' - unlabeled output interface,
'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
'M' - malformed request, 'm' - unsupported tlvs, 'N' - no label entry,
'P' - no rx intf label prot, 'p' - premature termination of LSP,
'R' - transit router, 'I' - unknown upstream index,
'l' - Label switched with FEC change, 'd' - see DDMAP for return code,
'X' - unknown return code, 'x' - return code 0
Type escape sequence to abort.
0 10.1.2.1 MRU 1500 [Labels: 16004 Exp: 0]
L 1 10.1.2.2 MRU 1500 [Labels: implicit-null Exp: 0] 139 ms
! 2 10.2.4.4 5 ms
R1 pushes label 16004, which represents R4’s prefix SID. 16000 is the SRGB base for R2, and the label index, 4, is added to that.
R2 pops the label, as SR preforms PHP by default. R4 receives and unlabeled packet.
Let’s try R1 to XR5 now:
R1#traceroute mpls ipv4 5.5.5.5/32 source 1.1.1.1
Tracing MPLS Label Switched Path to 5.5.5.5/32, timeout is 2 seconds
Codes: '!' - success, 'Q' - request not sent, '.' - timeout,
'L' - labeled output interface, 'B' - unlabeled output interface,
'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
'M' - malformed request, 'm' - unsupported tlvs, 'N' - no label entry,
'P' - no rx intf label prot, 'p' - premature termination of LSP,
'R' - transit router, 'I' - unknown upstream index,
'l' - Label switched with FEC change, 'd' - see DDMAP for return code,
'X' - unknown return code, 'x' - return code 0
Type escape sequence to abort.
0 10.1.2.1 MRU 1500 [Labels: 16005 Exp: 0]
L 1 10.1.2.2 MRU 1500 [Labels: 16005 Exp: 0] 7 ms
L 2 10.2.3.3 MRU 1500 [Labels: 16005 Exp: 0] 4 ms
L 3 10.3.6.6 MRU 1500 [Labels: implicit-null Exp: 0] 6 ms
! 4 10.5.6.5 11 ms
Isn’t it nice how the label stays consistent through the entire LSP? Each router along the way is literally preforming a swap operation, but swapping 16005 for 16005. If XR3 had an SRGB of 18000-18999, what label would we see? We would see R2 swap 16005 for 18005, and then XR3 would swap 18005 for 16005.
I’ve demonstrated this here:
#XR3
router isis 1
segment-routing global-block 18000 18999
R1#traceroute mpls ipv4 5.5.5.5/32 source 1.1.1.1
Tracing MPLS Label Switched Path to 5.5.5.5/32, timeout is 2 seconds
Codes: '!' - success, 'Q' - request not sent, '.' - timeout,
'L' - labeled output interface, 'B' - unlabeled output interface,
'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
'M' - malformed request, 'm' - unsupported tlvs, 'N' - no label entry,
'P' - no rx intf label prot, 'p' - premature termination of LSP,
'R' - transit router, 'I' - unknown upstream index,
'l' - Label switched with FEC change, 'd' - see DDMAP for return code,
'X' - unknown return code, 'x' - return code 0
Type escape sequence to abort.
0 10.1.2.1 MRU 1500 [Labels: 16005 Exp: 0]
L 1 10.1.2.2 MRU 1500 [Labels: 18005 Exp: 0] 4 ms
L 2 10.2.3.3 MRU 1500 [Labels: 16005 Exp: 0] 5 ms
L 3 10.3.6.6 MRU 1500 [Labels: implicit-null Exp: 0] 9 ms
! 4 10.5.6.5 7 ms
If you run a regular traceroute from R1, you may see the other path, R1-R2-R4-R6-XR5. You see two paths because prefix-SIDs are ECMP-aware or “ECMP-capable.” R2 has two equal-cost routes for 5.5.5.5/32. The traceroute and mpls traceroute generate different flows that R2 should load-balance.
R1#traceroute 5.5.5.5 source lo0 probe 1
1 10.1.2.2 [MPLS: Label 16005 Exp 0] 9 msec
2 10.2.3.3 [MPLS: Label 18005 Exp 0] 7 msec
3 10.3.6.6 [MPLS: Label 16005 Exp 0] 4 msec
4 10.5.6.5 7 msec
R1#traceroute mpls ipv4 5.5.5.5/32 source 1.1.1.1
0 10.1.2.1 MRU 1500 [Labels: 16005 Exp: 0]
L 1 10.1.2.2 MRU 1500 [Labels: 16005 Exp: 0] 4 ms
L 2 10.2.4.4 MRU 1500 [Labels: 16005 Exp: 0] 6 ms
L 3 10.4.6.6 MRU 1500 [Labels: implicit-null Exp: 0] 8 ms
! 4 10.5.6.5 7 ms
R2#show ip route 5.5.5.5
Routing entry for 5.5.5.5/32
Known via "isis", distance 115, metric 40, type level-2
Redistributing via isis
Last update from 10.2.4.4 on GigabitEthernet2, 00:00:13 ago
SR Incoming Label: 16005
Routing Descriptor Blocks:
10.2.4.4, from 5.5.5.5, 00:00:13 ago, via GigabitEthernet2, prefer-non-rib-labels, merge-labels
Route metric is 40, traffic share count is 1
MPLS label: 16005
MPLS Flags: NSF
* 10.2.3.3, from 5.5.5.5, 00:00:13 ago, via GigabitEthernet3, prefer-non-rib-labels, merge-labels
Route metric is 40, traffic share count is 1
MPLS label: 18005
MPLS Flags: NSF
Breaking SR
What happens if we turn off SR on R6? What will we see in the LFIBs of its neighbors? Let’s test it out.
#R6
router isis
no segment-routing mpls
R6#show isis data R6.00-00 verbose
IS-IS Level-2 LSP R6.00-00
LSPID LSP Seq Num LSP Checksum LSP Holdtime/Rcvd ATT/P/OL
R6.00-00 * 0x0000004F 0x2BB9 1194/* 0/0/0
Area Address: 49.0001
NLPID: 0xCC
Hostname: R6
Metric: 10 IS-Extended XR3.00
Metric: 10 IS-Extended R4.00
Metric: 10 IS-Extended XR5.00
IP Address: 6.6.6.6
Metric: 10 IP 6.6.6.6/32
Prefix-attr: X:0 R:0 N:1
Metric: 10 IP 10.3.6.0/24
Prefix-attr: X:0 R:0 N:0
Metric: 10 IP 10.4.6.0/24
Prefix-attr: X:0 R:0 N:0
Metric: 10 IP 10.5.6.0/24
Prefix-attr: X:0 R:0 N:0
All of the segment routing information is gone from the R6.00-00 LSP.
RP/0/0/CPU0:XR3#show mpls forwarding
Sun Aug 21 14:08:20.975 UTC
Local Outgoing Prefix Outgoing Next Hop Bytes
Label Label or ID Interface Switched
------ ----------- ------------------ ------------ --------------- ------------
18001 16001 SR Pfx (idx 1) Gi0/0/0/1 10.2.3.2 18528
18002 Pop SR Pfx (idx 2) Gi0/0/0/1 10.2.3.2 44800
18004 Pop SR Pfx (idx 4) Gi0/0/0/0 10.3.4.4 0
18005 Unlabelled SR Pfx (idx 5) Gi0/0/0/2 10.3.6.6 0
24003 Pop SR Adj (idx 1) Gi0/0/0/1 10.2.3.2 0
24004 Pop SR Adj (idx 3) Gi0/0/0/1 10.2.3.2 0
24005 Pop SR Adj (idx 1) Gi0/0/0/0 10.3.4.4 0
24006 Pop SR Adj (idx 3) Gi0/0/0/0 10.3.4.4 0
24007 Pop SR Adj (idx 1) Gi0/0/0/2 10.3.6.6 0
24008 Pop SR Adj (idx 3) Gi0/0/0/2 10.3.6.6 0
R4#show mpls forwarding-table
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
16 Pop Label 10.4.6.6-A 0 Gi3 10.4.6.6
17 Pop Label 10.2.4.2-A 0 Gi1 10.2.4.2
18 Pop Label 10.3.4.3-A 0 Gi2 10.3.4.3
16001 16001 1.1.1.1/32 1860 Gi1 10.2.4.2
16002 Pop Label 2.2.2.2/32 848 Gi1 10.2.4.2
16003 Pop Label 3.3.3.3/32 0 Gi2 10.3.4.3
16005 No Label 5.5.5.5/32 0 Gi3 10.4.6.6
A - Adjacency SID
On both XR3 and R4, the prefix SID with index 6 is gone. The prefix SID for XR5 is known still, but the path to XR5 from both R4 and XR3 is via R6, which is no longer running SR. So the outgoing action is Unlabelled or No Label. You also see this behaviour when a neighbor is not running LDP in a traditional LDP environment. This does not mean to pop the label, instead it means that the nexthop is not running MPLS on that interface, so the traffic is IP routed.
Below, a traceroute from R1 to XR5 works, but the label information is gone at R6. An mpls traceroute cannot get past R4:
R1#traceroute 5.5.5.5 source lo0 probe 1
Type escape sequence to abort.
Tracing the route to 5.5.5.5
VRF info: (vrf in name/id, vrf out name/id)
1 10.1.2.2 [MPLS: Label 16005 Exp 0] 7 msec
2 10.2.3.3 [MPLS: Label 18005 Exp 0] 5 msec
3 10.3.6.6 31 msec
4 10.5.6.5 7 msec
R1#traceroute mpls ipv4 5.5.5.5/32 source 1.1.1.1
Tracing MPLS Label Switched Path to 5.5.5.5/32, timeout is 2 seconds
Codes: '!' - success, 'Q' - request not sent, '.' - timeout,
'L' - labeled output interface, 'B' - unlabeled output interface,
'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
'M' - malformed request, 'm' - unsupported tlvs, 'N' - no label entry,
'P' - no rx intf label prot, 'p' - premature termination of LSP,
'R' - transit router, 'I' - unknown upstream index,
'l' - Label switched with FEC change, 'd' - see DDMAP for return code,
'X' - unknown return code, 'x' - return code 0
Type escape sequence to abort.
0 10.1.2.1 MRU 1500 [Labels: 16005 Exp: 0]
L 1 10.1.2.2 MRU 1500 [Labels: 16005 Exp: 0] 5 ms
B 2 10.2.4.4 MRU 1500 [No Label] 5 ms
B 3 10.2.4.4 MRU 1500 [No Label] 6 ms
B 4 10.2.4.4 MRU 1500 [No Label] 4 ms
B 5 10.2.4.4 MRU 1500 [No Label] 5 ms
<snip>
The following rules apply when the outgoing label is Unlabelled:
If there is no label, the IP packet is forwarded as normal
If there is one label, the label is removed and the packet is forwarded as an IP packet
If there are two or more labels, the packet is dropped
Conclusion
We’ve seen the basics of SR theory, including global vs. local segments, the SRGB, and prefix vs. adjacency segments. We also examined some of the benefits that SR has over LDP and RSVP. Namely the removal of an entire protocol just for label distribution, which also has complications due to potential sync issues, and replacement of RSVP-TE that offers full TE functionality without the associated state in the network. SR also enables FRR which we will cover in the next section.
We also explored how to configure basic SR for OSPF and ISIS. These configurations are fully sufficient to have a basic SR-enabled core that completely replaces LDP. We saw the OSPF type 10 Opaque LSA, and how it is used to advertise the SRGB, prefix-SIDs and adjacency SIDs. Likewise, ISIS uses the existing TLVs (Router Capability, Extended IS Reachability, and Extended IP Reachability) to advertise the SRGB, prefix-SIDs and adjacency SIDs. We must use wide metrics in order to use SR with ISIS.
I hope this has been useful, and that SR seems a little easier to understand now. SR was created with simplicity in mind. Once you are familiar with some of the basic terms it should be even easier to work with than LDP.
