Introduction, Lab (ISIS) Pt. 3
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.
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.
Take a look at the same information in the CLI:
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.
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.
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:
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.
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 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:
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:
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.
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.
All of the segment routing information is gone from the R6.00-00 LSP.
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:
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.
Last updated