# LDP/SR Interworking

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.

### &#x20;<a href="#a22f1716-b245-4488-b685-a36afcffc110" id="a22f1716-b245-4488-b685-a36afcffc110"></a>

### Lab <a href="#a22f1716-b245-4488-b685-a36afcffc110" id="a22f1716-b245-4488-b685-a36afcffc110"></a>

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.

<figure><img src="https://1203572585-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FgAMH3CMtmYTBkob03NUj%2Fuploads%2Fz8tbKm1ttzQNuyXfuVvl%2FUntitled.png?alt=media&#x26;token=3ddbb0cd-aff1-4046-a6de-a41880c758b2" alt=""><figcaption></figcaption></figure>

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:

```
24008  Unlabelled   5.5.5.5/32         Gi0/0/0/2    10.3.6.6        6600
```



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.

```
RP/0/0/CPU0:XR5#traceroute mpls ipv4 1.1.1.1/32 source 5.5.5.5
Thu Aug 25 14:50:03.713 UTC

Tracing MPLS Label Switched Path to 1.1.1.1/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 rx label, 
  'P' - no rx intf label prot, 'p' - premature termination of LSP, 
  'R' - transit router, 'I' - unknown upstream index,
  'X' - unknown return code, 'x' - return code 0

Type escape sequence to abort.

Q 1 *
```



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:

```
segment-routing
 mapping-server
  prefix-sid-map
   address-family ipv4
    2.2.2.2/32 2 range 1
!
router isis 1
 address-family ipv4 unicast
  segment-routing prefix-sid-map advertise-local
!
router ospf 1
 segment-routing prefix-sid-map advertise-local
```



### Test Your Understanding

**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.

### &#x20;<a href="#ad12c2d2-c973-4152-90f9-6d731946b6a4" id="ad12c2d2-c973-4152-90f9-6d731946b6a4"></a>

### Conclusion <a href="#ad12c2d2-c973-4152-90f9-6d731946b6a4" id="ad12c2d2-c973-4152-90f9-6d731946b6a4"></a>

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.
