New SRGB Turns a Prefix-SID into a Black Hole
A network is migrating from LDP to SR-MPLS. P1 and P2 use SRGB 16000-23999. PE2 runs both SR and LDP, while PE1 still runs LDP only. A mapping server is planned for LDP-to-SR interworking. A new router P3 is added with SRGB 17000-24999. P3 advertises prefix-SID index 2 for its loopback 10.255.255.3/32. P1 installs label 16002 for that loopback and forwards traffic from PE2 toward P3. P3 receives label 16002 and drops the packets; traffic to P3's loopback and to a customer prefix behind P3 fails. Traffic to P1 and P2 loopbacks still works. The team says SR is hop-by-hop and expects mismatched SRGBs to be harmless. You must judge the failure and the fix.
1. Why does traffic to P3 blackhole after P3 is added, while traffic to P1 and P2 still works?
Read the worked answer
SR-MPLS forwarding depends on the receiving router recognizing the incoming label as a SID within its local SRGB. P3 advertises prefix-SID index 2, but its SRGB starts at 17000. P1, using the older SRGB convention, installs and sends label 16002 for that prefix. From P1's perspective the label is within its own SRGB, but P3 receives 16002 outside its configured SRGB 17000-24999 and cannot resolve it to a valid SID, so it drops the packet. P1 and P2 share the same SRGB, so their prefix-SIDs are recognized. This is not a routing failure in OSPF and not an LDP failure; it is an SRGB consistency problem. The hop-by-hop nature of SR does not make label ranges arbitrary, because each hop must interpret the incoming SID.
2. What would you check to confirm the SRGB and prefix-SID mismatch?
Read the worked answer
Check the configured SRGB on P1, P2, and P3 with the platform's SR configuration commands and with show mpls label range or the SR equivalent. Check the advertised prefix-SID for 10.255.255.3/32 in the IGP database and on P1's forwarding entry. On P1, show mpls forwarding-table 10.255.255.3/32 detail should show the outgoing label 16002. On P3, verify the local label for its own loopback and whether 16002 falls inside its SRGB. If available, use an MPLS traceroute or a packet capture to show that the packet reaches P3 with label 16002 and is dropped. Also confirm that no mapping server is currently remapping the prefix-SID, and check whether P3's SRGB was intended to be part of the same SR domain.
3. What are the fix options, and which would you recommend for this migration?
Read the worked answer
The clean fix is to align the SRGB across all SR routers, for example set P3 to 16000-23999 to match P1 and P2. That gives one global SID space and avoids per-hop interpretation problems. Changing an SRGB can be disruptive because labels may change; schedule it in a maintenance window and verify prefix-SIDs after the change. A mapping server can translate LDP prefixes into SR SIDs for LDP-only PE1, but it does not fix a mismatched SRGB among SR routers unless it is explicitly used to map the affected SIDs. Another option is to keep P3 out of the SR domain or use LDP between P3 and the SR core, but that adds protocol complexity. For a migration, I would standardize the SRGB first, then use the mapping server only for the LDP edge.