Partial SR-MPLS Migration with LDP-Only PEs
An ISP is migrating a six-router core to SR-MPLS. R1 through R4 support SR with a common SRGB of 16000-23999 and prefix-SID indices 10-60. R5 and R6 are LDP-only PE routers that cannot be upgraded this year. The customer L3VPN runs from PE R1 to PE R6, and R4 is the only router that has both SR and LDP enabled. R1 must forward VPN traffic to R6 using an SR transport label to R4 and an LDP label from R4 to R6. A mapping server is being considered on R4 to advertise a prefix-SID for R6's loopback 10.6.6.6/32. R1 currently has no label for 10.6.6.6/32 and drops traffic when the VPN label is popped at R1. The ISP also plans to upgrade R5 to SR next quarter and wants to avoid SID conflicts or a flag day. The core uses OSPF and LDP with default timers, and no MPLS TE is deployed.
1. How should R1 forward VPN traffic to R6 during the partial SR migration, and what role does the mapping server play?
Read the worked answer
R1 cannot use an SR prefix SID for 10.6.6.6/32 because R6 is LDP-only and does not advertise one. R4 is the SR/LDP border and should act as the SR mapping server for the LDP-only prefixes. R4 advertises a mapping entry for 10.6.6.6/32 using an unused index from the domain SRGB, for example index 60 giving SID 16060. R1 installs an SR forwarding entry for 16060 toward R4. When R1 sends VPN traffic, the label stack is the SR transport label 16060 plus the VPN label. R4 receives 16060, recognizes it as the mapping for R6's loopback, swaps it to the LDP label it learned for 10.6.6.6/32, and forwards toward R5/R6. The VPN label is preserved until R6. Verify R4 has an LDP label for R6, that R1 resolves 16060 via R4, and that the SRGB is consistent on R1-R4. This avoids a flag day and does not require R1 to run LDP.
2. What SID and SRGB checks are required before R5 is upgraded to SR, and what would happen if R4 and R5 use different SRGBs?
Read the worked answer
The mapping server makes R6 reachable, but it does not make SID allocation safe. Before R5 is upgraded, inventory every prefix-SID index in the SR domain and ensure the index chosen for R6's loopback does not collide with an index that R5 will advertise. The mapping entry should be removed or overridden when R6 becomes SR-capable and starts advertising its own prefix SID. Also confirm all SR routers use the same SRGB, or that the mapping server advertises mappings valid for each node's SRGB. If R4 and R5 use different SRGBs, a label such as 16060 may mean different things on different routers; R1 may push 16060, R4 may forward it, and R5 may interpret it as a different SID or not have a forwarding entry, causing a blackhole. For SR-MPLS prefix SIDs, keep a single domain-wide SRGB and unique indices, and test the label stack with show mpls forwarding and MPLS traceroute before cutover.