If you have routers in your MPLS core that are not capable of running SR, then the good news is that this does not prevent you from deploying SR in your network. SR-only and LDP-only routers can co-exist is the same network through the use of a SRMS (Segment Routing Mapping Server). This is a function on a router which advertises prefix-SIDs on behalf of LDP-only routers into the IGP.
The mapping server is a control-plane function. Similar to a BGP RR, the SRMS can be anywhere in the network and does not need to be in the data path. The SRMS simply needs to be able to have an IGP adjacency to the network.
In order to receive and install the prefix-to-prefix-SID mappings advertised by the SRMS, a router must be a Mapping Client. By default, when you enable SR under the IGP, the router preforms the Mapping Client function and accepts mappings from Mapping Servers, so this is normally not something you need to be concerned with.
Lab
We’ll re-use the topology from the preivous article. R4 will be our mapping server and will advertise mappings into the IGP for R1 and R2. R1-R2-XR3 makes up the LDP-only section of the network, and XR3-R6-XR5 makes up the SR-only section of the network. For LDR and SR to interwork, there must be one node which does LDP-SR translation and acts as the “border router.” This is XR3 in our topologuy.
For brevity I will omit the full configs of each router, and include only the relevant LDP and OSPF sections:
#R1
interface Gi1
ip address 10.1.2.1 255.255.255.0
ip ospf network point-to-point
mpls ip
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
router ospf 1
network 0.0.0.0 255.255.255.255 area 0
#R2
interface GigabitEthernet1
ip address 10.1.2.2 255.255.255.0
ip ospf network point-to-point
mpls ip
!
interface GigabitEthernet2
ip address 10.2.4.2 255.255.255.0
ip ospf network point-to-point
!
interface GigabitEthernet3
ip address 10.2.3.2 255.255.255.0
ip ospf network point-to-point
mpls ip
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
router ospf 1
network 0.0.0.0 255.255.255.255 area 0
#XR3
router ospf 1
segment-routing mpls
area 0
interface Loopback0
prefix-sid index 3
!
interface GigabitEthernet0/0/0/0
network point-to-point
!
interface GigabitEthernet0/0/0/1
network point-to-point
!
interface GigabitEthernet0/0/0/2
network point-to-point
!
!
!
mpls ldp
interface GigabitEthernet0/0/0/1
#R4
<no LDP config>
segment-routing mpls
!
connected-prefix-sid-map
address-family ipv4
4.4.4.4/32 index 4 range 1
exit-address-family
!
router ospf 1
segment-routing mpls
network 0.0.0.0 255.255.255.255 area 0
!
int range Gi1-3
! We don't want R4 to be in the data path
ip ospf cost 20
#R6
<no LDP config>
segment-routing mpls
!
connected-prefix-sid-map
address-family ipv4
6.6.6.6/32 index 6 range 1
exit-address-family
!
router ospf 1
segment-routing mpls
network 0.0.0.0 255.255.255.255 area 0
#XR5
<no LDP config>
router ospf 1
segment-routing mpls
area 0
interface Loopback0
prefix-sid index 5
!
interface GigabitEthernet0/0/0/0
network point-to-point
Before we add the mapping server functionality to R4, what labeled reachability do we have right now? The answer is that the LDP nodes have a unidirectional LSP to the SR nodes, because XR3 advertises LDP mappings for the SR nodes’s prefixes into the LDP domain, as normal LDP behavior. However the SR nodes do not have a unidirectional LSP to the LDP nodes, because the LDP nodes do not have SR prefix-SIDs.
Let’s examine this more deeply. R1 can preform an mpls traceroute to 5.5.5.5/32:
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: 24 Exp: 0] ! LDP label from R2
L 1 10.1.2.2 MRU 1500 [Labels: 24008 Exp: 0] 7 ms ! LDP label from XR3
L 2 10.2.3.3 MRU 1500 [Labels: 16005 Exp: 0] 5 ms ! XR3 swaps 24008 for 16005 (Prefix-SID)
L 3 10.3.6.6 MRU 1500 [Labels: implicit-null Exp: 0] 28 ms ! R6 pops 16005
! 4 10.5.6.5 7 ms
The reason this works is because XR3 substitues its unlabeled LDP entry for 5.5.5.5/32 with the SR prefix-SID entry. Normally, if SR was not running, the LFIB on XR3 would look like this:
In fact we can actually see this if we filter the LIB to LDP bindings:
RP/0/0/CPU0:XR3#show mpls ldp forwarding 5.5.5.5/32
Thu Aug 25 18:46:15.262 UTC
Codes:
- = GR label recovering, (!) = LFA FRR pure backup path
{} = Label stack with multi-line output for a routing path
G = GR, S = Stale, R = Remote LFA FRR backup
Prefix Label Label(s) Outgoing Next Hop Flags
In Out Interface G S R
--------------- ------- -------------- ------------ ------------------- -----
5.5.5.5/32 24008 Unlabelled Gi0/0/0/2 10.3.6.6
This is because its next-hop router for 5.5.5.5/32 is R6, which has not advertised an LDP binding for this prefix. However, XR3 replaces the Unlabelled outbound entry with the SR entry automatically in the LFIB:
RP/0/0/CPU0:XR3#show mpls forwarding labels 24008
Thu Aug 25 14:48:52.448 UTC
Local Outgoing Prefix Outgoing Next Hop Bytes
Label Label or ID Interface Switched
------ ----------- ------------------ ------------ --------------- ------------
24008 16005 5.5.5.5/32 Gi0/0/0/2 10.3.6.6 264
This automatic substitution is a function of Cisco’s SR implementation and means that LDP and SR can seamlessly interoperate. XR3 is essentially doing LDP to SR translation.
Let’s take a look at the reverse path, from the SR-only side to the LDP-only side.
XR5 cannot even send the request, as it has no label for 1.1.1.1/32. It has the IP route from the IGP but no label binding.
So we can say that the SRMS function is needed so that SR-only nodes can reach LDP-only nodes. LDP-only nodes can by default reach SR-only nodes as long as there is some node that runs both LDP and SR in order to translate between them (which is XR3 in our topology).
Let’s implement the mappings on R4:
#R4
segment-routing mpls
mapping-server
prefix-sid-map
address-family ipv4
1.1.1.1/32 index 1
2.2.2.2/32 index 2
!
router ospf 1
segment-routing prefix-sid-map advertise-local
As you can see, mapping prefixes to prefix-SID indexes is very similar to mapping a router’s own connected prefix to a prefix-SID index. One feature that is available under the mapping-server configuration is that you can map multiple consecutive prefixes in a single line with the command 1.1.1.1/32 index 1 range 10. This would map 1.1.1.1/32 to index 1, 1.1.1.2/32 to index 2, all the way up to 1.1.1.10/32 to index 10. This doesn’t apply in our topology but could be a useful shortcut depending on your loopback addressing scheme.
The segment-routing prefix-sid-map advertise-local command is necessary under the IGP in order to actually use the locally defined mappings. Without this command, the router does not inject the mappings into the IGP. By default, all routers act as a mapping client. To disable this you can use the command segment-routing prefix-sid-map receive disable but it usually doesn’t make sense to do this. Because the client functionality is on by default, when you use advertise-local, it means the router will advertise the local mappings and also continue to accept remote mappings. For redundancy you likely want to deploy multiple mapping servers in a network.
! R4's 7.0.0.0 Opaque LSA for its own loopback
LS age: 421
Options: (No TOS-capability, DC)
LS Type: Opaque Area Link
Link State ID: 7.0.0.0
Opaque Type: 7 (Extended Prefix)
Opaque ID: 0
Advertising Router: 4.4.4.4
LS Seq Number: 80000021
Checksum: 0x3A22
Length: 44
TLV Type: Extended Prefix
Length: 20
Prefix : 4.4.4.4/32
AF : 0
Route-type: Intra
Flags : N-bit
Sub-TLV Type: Prefix SID
Length: 8
Flags : None
MTID : 0
Algo : SPF
SID : 4
! R4's mapping for 1.1.1.1/32
LS age: 217
Options: (No TOS-capability, DC)
LS Type: Opaque Area Link
Link State ID: 7.0.0.1
Opaque Type: 7 (Extended Prefix)
Opaque ID: 1
Advertising Router: 4.4.4.4
LS Seq Number: 80000001
Checksum: 0xF46C
Length: 48
TLV Type: Extended Prefix Range
Length: 24
AF : 0
Prefix : 1.1.1.1/32
Range size: 1
Flags : None
Sub-TLV Type: Prefix SID
Length: 8
Flags : M-bit, NP-bit
MTID : 0
Algo : SPF
SID : 1
! R4's mapping for 2.2.2.2/32
LS age: 217
Options: (No TOS-capability, DC)
LS Type: Opaque Area Link
Link State ID: 7.0.0.2
Opaque Type: 7 (Extended Prefix)
Opaque ID: 2
Advertising Router: 4.4.4.4
LS Seq Number: 80000001
Checksum: 0x4B10
Length: 48
TLV Type: Extended Prefix Range
Length: 24
AF : 0
Prefix : 2.2.2.2/32
Range size: 1
Flags : None
Sub-TLV Type: Prefix SID
Length: 8
Flags : M-bit, NP-bit
MTID : 0
Algo : SPF
SID : 2
Do you see the difference between the Opaque LSAs that R4 generated for its own prefix compared to the prefixes of R1 and R2? One difference is that the R1 and R2 mappings have the M-bit and NP-bit set. The M-bit indicates that it is a mapping, and the NP-bit means “no PHP.” Additionally these mappings do not have the N-bit set which indicates they are Node-SIDs. You can also see that there is a range size parameter. If you use that shortcut that was mentioned earlier, you can advertise multiple consecutive prefix-SIDs in a single LSA.
XR5 has accepted the mappings and installed them into the LFIB:
RP/0/0/CPU0:XR5#show mpls forwarding
Thu Aug 25 15:03:19.738 UTC
Local Outgoing Prefix Outgoing Next Hop Bytes
Label Label or ID Interface Switched
------ ----------- ------------------ ------------ --------------- ------------
16001 16001 SR Pfx (idx 1) Gi0/0/0/0 10.5.6.6 0
16002 16002 SR Pfx (idx 2) Gi0/0/0/0 10.5.6.6 0
16003 16003 SR Pfx (idx 3) Gi0/0/0/0 10.5.6.6 0
16004 16004 SR Pfx (idx 4) Gi0/0/0/0 10.5.6.6 0
16006 Pop SR Pfx (idx 6) Gi0/0/0/0 10.5.6.6 0
24011 Pop SR Adj (idx 0) Gi0/0/0/0 10.5.6.6 0
! This command shows active mappings that came from a mapping server
RP/0/0/CPU0:XR5#show ospf segment-routing prefix-sid-map active-policy
Thu Aug 25 15:04:28.184 UTC
SRMS active policy for Process ID 1
Prefix SID Index Range Flags
1.1.1.1/32 1 1
2.2.2.2/32 2 1
Number of mapping entries: 2
XR5 now has a unidirectional LSP to R1:
XR5#traceroute 1.1.1.1 source lo0 probe 1
Thu Aug 25 15:06:55.174 UTC
Type escape sequence to abort.
Tracing the route to 1.1.1.1
1 10.5.6.6 [MPLS: Label 16001 Exp 0] 9 msec
2 10.3.6.3 [MPLS: Label 16001 Exp 0] 9 msec
3 10.2.3.2 [MPLS: Label 17 Exp 0] 0 msec
4 10.1.2.1 0 msec
XR3 does the same label entry replacement for the incoming SR label to the outoing LDP label, since R2 is not SR-enabled. This is automatic, and is basically SR to LDP translation.
RP/0/0/CPU0:XR3#show mpls forwarding labels 16001
Thu Aug 25 15:08:11.458 UTC
Local Outgoing Prefix Outgoing Next Hop Bytes
Label Label or ID Interface Switched
------ ----------- ------------------ ------------ --------------- ------------
16001 17 SR Pfx (idx 1) Gi0/0/0/1 10.2.3.2 436
Since we only enabled the mapping server functionality on IOS-XE, here is the configuration for IOS-XR for reference:
Q: In the topology [ SR - LDP - SR ] with no mapping server, is there a bidirectional LSP between SR nodes on either end?
A: Yes, because the SR only nodes know their prefix-SIDs via the IGP. The two routers at the SR/LDP boundaries will do automatic label translation, so a mapping server is not needed. We can say that a mapping server is only needed when an LDP-only node will terminate an LSP, and specifically when it is the egress node in the LSP. (LDP to SR works without a mapping server, but SR to LDP does not).
Multi-level/area mapping
IS-IS does not propagate mapping server advertisements between levels. OSPF does propagate the Type 10 LSAs for the mapping advertisements between areas, as the prefixes themselves become inter-area routes. This is actually the same behaviour as when a mapping server is not used at all.
Conclusion
LDP-only and SR-only routers can co-exist in a network without any issue, as long as there is a router that runs both LDP and SR that can do label translation. This label translation function happens by default.
An LDP-only node can form a unidirectional LSP to an SR-only node, but the reverse is not true. In order for a SR-only node to form a unidirectional LSP to an LDP-only node, a mapping server is needed. This mapping server advertises prefix-SIDs on behalf of LDP-only nodes into the IGP.
