SR/LDP Interworking
Last updated
Last updated
Load sr.ldp.interworking.init.cfg
Above, routers R1, R2 and R4 are SR-only routers. Routers R5-R8 are LDP-only routers. R3 runs both SR and LDP.
Configure R3 and R4 as segment routing mapping servers to allow the SR-only and LDP-only nodes to form bidirectional LSPs.
Before adding the solution, we’ll explore the current issue. There are two “islands” in this topology:
SR-only, consisting of R1-R4
LDP-only, consisting of R5-R8
R3 belongs to both islands and can translate between SR and LDP
By default, LDP to SR unidirectional LSPs will work. This is because LDP creates a label binding for every IGP prefix. So the LDP-only side already has labels for the SR-only nodes. (All nodes belong to the same IGP area/level).
Notice that R3 automatically swaps the LDP label to the SR label:
R3 has two separate entries for each prefix SID known in the SR domain. One SR label entry, and one LDP entry. The LDP entry swaps to the SR label.
In addition to the LDP label above for 2.2.2.1/32, R3 also has the SR label entry for the prefix SID with index 2.
Essentially what happens is that the LDP entry has an Unlabelled outgoing label. The router finds a valid SR outgoing label for the same nexthop, which replaces the Unlablled entry.
We can see the low level details of this by inspecting the CEF flags for this prefix. We see the flags “LDP/SR merge requested” and “LDP/SR merge active.” This means that the SR label was “merged” (think “replaced”) with the unlabelled output entry. However, these flags are only for the IP-to-MPLS action. Since LDP preference is enabled by default, but the router cannot impose an LDP label, the SR label is imposed instead.
As a slight tangent, if we change to sr-prefer, R3 will now remove the “LDR/SR merge active” flag because the merge is no longer needed on the IP-to-MPLS action, as the SR label is pushed by default. Instead we see a flag for “RIB pref over LSD”.
While the LDP —> SR unidirectional LSP exists and works, there is currently no unidirectional LSP from SR —> LDP. This is because SR-only routers only have label entries for prefix SIDs, and the LDP-only routers are not advertising prefix SIDs for their loopbacks. Unlike LDP, in SR local label binding allocation is not driven simply by IGP prefixes, it is driven by SID advertisements.
To fix this, we must somehow advertise prefix SIDs on behalf of the LDP-only routers into the IGP. We can do this using a segment-routing mapping server (SRMS). This feature allows us to use multiple mapping servers per domain for redundancy. All routers will simply prefer the mapping server with the largest SysID in case of conflicting mappings.
We configure the SRMS as follows:
We can confirm the mappings locally on the mapping server using the following command:
Note that we can optionally configure a range of mappings in a single command. There probably aren’t many times you would use this, but the functionality is there in case you want it. The prefix length is the prefix length you want for each individual mapping. This would normally be a /32 (or /128 if using IPv6).
The router would create prefix SID mappings for:
10.10.10.1/32 = 100
10.10.10.2/32 = 101
…
10.10.10.10/32 = 109
Our topology does not have prefixes that increment sequentially like this, so we will not be able to use this.
Note that while we’ve created the local mappings, we haven’t advertised them into the IGP yet. All we need to do is add the following command to ISIS:
We can verify that all SR-only nodes see the new prefix SID mappings using the following command:
This works because all routers are automatically accepting/receiving remote mappings. If for some reason you wanted to disable this on a router, you can use the following command. This command can optionally be used on the SRMS itself to only use local mappings, but there is not a good reason to do this.
These nodes should now be able to form an end-to-end LSP with LDP-only nodes:
Notice that R3 now swaps the LDP-only prefix SIDs with their LDP label learned from R5:
The reverse action happens that we saw before: the unlabelled SR output label is swapped with the LDP output label. If we leave the sr-prefer configuration, R3 will be unable to impose an SR label for the prefix 8.8.8.1/32. We will see a “LDP/SR merge requested” and “LD/SR merge active” flag in the CEF flags output. The router must impose an LDP label instead of an SR label. (Note that R3 is not originating LSPs so this isn’t very relevant, but it is shown to explain how SR/LDP by default interwork with no extra configuration needed).
R3 advertises prefix SID mappings by using a new TLV within its LSP:
Notice that the PHP-off flag is not set. The flags for the SID Binding high-level TLV are used to control whether the TLV is attached to the originator with the A flag. By default this is unset. The Prefix SID sub TLV is then used for the mapping entry. All flags besides in the N (node) flag in this sub TLV are to be ignored, hence why the PHP-off flag is not set as you might expect.
(Also note that the S and D flags on the SID Binding TLV are always unset. These are the same as what we saw with the Router Capabilities TLV in the very first lab. There is also an M (mirror) flag which is not used by IOS-XR).
The attached flag is said to be used “when the node for the prefix SID is not SR nor LDP enabled” although I don’t quite understand what this does. You can set it in the local mapping policy as follows. It does not appear that nexthop neighbors will preform PHP, so I don’t quite understand this.
Moving on, we can see on the SR-only nodes that a route to an LDP-only loopback is now via “labeled SR(SRMS)” instead of “labeled SR”:
When multiple mapping servers are used, the clients will prefer the mapping server with the highest SysID. If these tie because the mapping is advertised in multiple areas, the lowest OSPF area ID or lowest level number is preferred. (The mapping might be advertised to multiple areas/levels from the same RID/SysID for a brief moment when a mapping range is moved from one area/level to another and the old LSP/LSA has not been purged).
We can confirm this by creating a conflict for a mapping between R3 and R4:
If we look at the active policy on R2, we should see that the index is 55 because R4 has a higher ISIS SysID:
The backup-policy shows us that 5 will be used instead, if R4 no longer functions as a mapping server:
Note that this is only for conflicting/overlapping mappings. If R3 adds a mapping that R4 doesn’t advertise, then R3’s mapping will be placed in the active policy on all clients.
Note that ranges are treated as single entries. If one range overlaps another range in some subsection of the range, only the range from the primary server is used.
Also, if there is a discrepancy between a natively adverised prefix SID and a mapping entry, the natively advertised prefix SID is preferred.
The above example also demonstrates another point: the SRMS can advertise any arbitrary prefix. It does not need to exist in the RIB. Also, the SRMS can be placed anywhere in the network, as long as it belongs to the IGP area/level.
Another point to be aware of is that the mapping server itself is also a client. It treats its own local mappings with the same priority as a remote mapping server. That is to say, R3 does not give its own local mappings special preference over R4’s mappings. R4’s overlapping mappings are used because it has a higher SysID. This makes sense when you consider that all routers in the IGP should make the same decision about which mapping is preferred, and this includes the mapping server itself.
