Migrating LDP to SR

SR will often be deployed onto an existing network that runs LDP. Cisco’s implementation of SR has taken this into account and provided a very smooth migration procedure.

When you run SR along-side LDP, you will see two labels for prefixes which have prefix-SIDs in the LFIB - the LDP label and the SR label. By default, LDP labels will be imposed on incoming unlabeled traffic. This means that you can enable SR without actually using SR in your network. If you leave the defaults as they are, no traffic will actually use the SR labels. You can then manually configure SR preference when you are ready. Only then will incoming unlabeled packets be imposed with an SR label.

The IOS-XR command to configure SR preference is as follows:

router ospf 1
 segment-routing mpls
 segment-routing sr-prefer
!
router isis 1
 address-family ipv4 unicast
  segment-routing mpls sr-prefer
  ! For ISIS, sr-prefer is a keyword to the 'segment-routing mpls' command.
  ! It is not a separate command as in OSPF.

The IOS-XE command to configure SR preference is as follows:

segment-routing
 set-attributes
  address-family ipv4
   sr-label-preferred

The sr-prefer configuration only affects which label is pushed onto incoming IP traffic. It does not affect incoming traffic that has an existing MPLS label. Incoming traffic which has an LDP label will be swapped with the corresponding LDP label in the LFIB. Incoming labeled traffic which has an SR label will be swapped with the SR label from the LFIB. This is regardless of whether sr-prefer is configured.

Lab

We’ll reuse our topology from the SR Introduction series:

Currently all nodes are running LDP, and SR is not enabled. Here are the startup configs:

#R1
hostname R1
!
interface Loopback0
 ip address 1.1.1.1 255.255.255.255
!
interface GigabitEthernet1
 ip address 10.1.2.1 255.255.255.0
 ip ospf network point-to-point
 mpls ip
!
router ospf 1
 network 0.0.0.0 255.255.255.255 area 0

#R2
hostname R2
!
interface Loopback0
 ip address 2.2.2.2 255.255.255.255
!
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
 mpls ip
!
interface GigabitEthernet3
 ip address 10.2.3.2 255.255.255.0
 ip ospf network point-to-point
 mpls ip
!
router ospf 1
 network 0.0.0.0 255.255.255.255 area 0

#XR3
hostname XR3
!
interface Loopback0
 ipv4 address 3.3.3.3 255.255.255.255
!
interface GigabitEthernet0/0/0/0
 ipv4 address 10.3.4.3 255.255.255.0
!
interface GigabitEthernet0/0/0/1
 ipv4 address 10.2.3.3 255.255.255.0
!
interface GigabitEthernet0/0/0/2
 ipv4 address 10.3.6.3 255.255.255.0
!
router ospf 1
 area 0
  interface Loopback0
  !
  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 oam
!
mpls ldp
 interface GigabitEthernet0/0/0/0
 !
 interface GigabitEthernet0/0/0/1
 !
 interface GigabitEthernet0/0/0/2
 !
!
end

#R4
hostname R4
!
interface Loopback0
 ip address 4.4.4.4 255.255.255.255
!
interface GigabitEthernet1
 ip address 10.2.4.4 255.255.255.0
 ip ospf network point-to-point
 mpls ip
!
interface GigabitEthernet2
 ip address 10.3.4.4 255.255.255.0
 ip ospf network point-to-point
 mpls ip
!
interface GigabitEthernet3
 ip address 10.4.6.4 255.255.255.0
 ip ospf network point-to-point
 mpls ip
!
router ospf 1
 network 0.0.0.0 255.255.255.255 area 0

#R6
hostname R6
!
interface Loopback0
 ip address 6.6.6.6 255.255.255.255
!
interface GigabitEthernet1
 ip address 10.3.6.6 255.255.255.0
 ip ospf network point-to-point
 mpls ip
!
interface GigabitEthernet2
 ip address 10.5.6.6 255.255.255.0
 ip ospf network point-to-point
 mpls ip
!
interface GigabitEthernet3
 ip address 10.4.6.6 255.255.255.0
 ip ospf network point-to-point
 mpls ip
!
router ospf 1
 network 0.0.0.0 255.255.255.255 area 0

#XR5
hostname XR5
!
interface Loopback0
 ipv4 address 5.5.5.5 255.255.255.255
!
interface GigabitEthernet0/0/0/0
 ipv4 address 10.5.6.5 255.255.255.0
!
router ospf 1
 area 0
  interface Loopback0
  !
  interface GigabitEthernet0/0/0/0
   network point-to-point
  !
 !
!
mpls oam
!
mpls ldp
 interface GigabitEthernet0/0/0/0
 !
!
end

You should have an end-to-end LSP between R1 and XR5 using LDP labels:

R1#traceroute 5.5.5.5 source lo0 probe 1
Type escape sequence to abort.
Tracing the route to 5.5.5.5
VRF info: (vrf in name/id, vrf out name/id)
  1 10.1.2.2 [MPLS: Label 24 Exp 0] 8 msec
  2 10.2.4.4 [MPLS: Label 24 Exp 0] 9 msec
  3 10.4.6.6 [MPLS: Label 24 Exp 0] 4 msec
  4 10.5.6.5 7 msec

We’ll now enable SR on all nodes. Try to do this on your own for practice. The configuration is below if you need it:

#R1
segment-routing mpls
 connected-prefix-sid-map
  address-family ipv4
   1.1.1.1/32 index 1
!
router ospf 1
 segment-routing mpls

#R2
segment-routing mpls
 connected-prefix-sid-map
  address-family ipv4
   2.2.2.2/32 index 2
!
router ospf 1
 segment-routing mpls

#XR3
router ospf 1
 segment-routing mpls
 area 0
  int lo0
   prefix-sid index 3

#R4
segment-routing mpls
 connected-prefix-sid-map
  address-family ipv4
  4.4.4.4/32 index 4
!
router ospf 1
 segment-routing mpls

#R6
segment-routing mpls
 connected-prefix-sid-map
  address-family ipv4
  6.6.6.6/32 index 6
!
router ospf 1
 segment-routing mpls

#XR5
router ospf 1
 segment-routing mpls
 area 0
  int lo0
   prefix-sid index 5

Notice that R1 has both the LDP labels and the SR prefix SIDs in its LFIB. Take the prefix 5.5.5.5/32. The LDP outgoing label is 24, and the SR outgoing label is 16005.

R1#show mpls forwarding-table 
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop    
Label      Label      or Tunnel Id     Switched      interface              
16         Pop Label  2.2.2.2/32       0             Gi1        10.1.2.2    
17         Pop Label  10.2.4.0/24      0             Gi1        10.1.2.2    
18         Pop Label  10.2.3.0/24      0             Gi1        10.1.2.2    
19         16         3.3.3.3/32       0             Gi1        10.1.2.2    
20         18         10.3.6.0/24      0             Gi1        10.1.2.2    
21         19         10.3.4.0/24      0             Gi1        10.1.2.2    
22         20         4.4.4.4/32       0             Gi1        10.1.2.2    
23         21         10.4.6.0/24      0             Gi1        10.1.2.2    
24         22         6.6.6.6/32       0             Gi1        10.1.2.2    
25         23         10.5.6.0/24      0             Gi1        10.1.2.2    
26         24         5.5.5.5/32       0             Gi1        10.1.2.2    
27         Pop Label  10.1.2.2-A       0             Gi1        10.1.2.2    
16002      Pop Label  2.2.2.2/32       0             Gi1        10.1.2.2    
16003      16003      3.3.3.3/32       0             Gi1        10.1.2.2    
16004      16004      4.4.4.4/32       0             Gi1        10.1.2.2    
16005      16005      5.5.5.5/32       0             Gi1        10.1.2.2    
16006      16006      6.6.6.6/32       0             Gi1        10.1.2.2

Let’s check the cef entry for 5.5.5.5/32 on R1:

R1#show ip cef 5.5.5.5/32
5.5.5.5/32
  nexthop 10.1.2.2 GigabitEthernet1 label 24-(local:26)

This shows that label 24 will be imposed on traffic towards the IP destination 5.5.5.5/32, and the local LDP label binding is 26. This is the default behaviour on both IOS-XE and IOS-XR when LDP and SR are both configured. The LDP label is imposed on IP traffic.

The traceroute uses the same labels as we saw previously, before SR was configured:

R1#traceroute 5.5.5.5 source lo0 probe 1
Type escape sequence to abort.
Tracing the route to 5.5.5.5
VRF info: (vrf in name/id, vrf out name/id)
  1 10.1.2.2 [MPLS: Label 24 Exp 0] 8 msec
  2 10.2.4.4 [MPLS: Label 24 Exp 0] 9 msec
  3 10.4.6.6 [MPLS: Label 24 Exp 0] 4 msec
  4 10.5.6.5 7 msec

An interesting question is: What happens if we configure sr-prefer only on R1, and run the traceroute again? R1 will impose the SR label which is 16005. Does R2 swap this for the LDP label because it does not have sr-prefer configured? Or does it swap it for the SR label?

#R1
segment-routing
 set-attributes
  address-family ipv4
   sr-label-preferred
!
end

R1#show ip cef 5.5.5.5/32
5.5.5.5/32
  nexthop 10.1.2.2 GigabitEthernet1 label 16005-(local:16005)

R1#traceroute 5.5.5.5 source lo0 probe 1
Type escape sequence to abort.
Tracing the route to 5.5.5.5
VRF info: (vrf in name/id, vrf out name/id)
  1 10.1.2.2 [MPLS: Label 16005 Exp 0] 30 msec
  2 10.2.3.3 [MPLS: Label 16005 Exp 0] 10 msec
  3 10.3.6.6 [MPLS: Label 16005 Exp 0] 5 msec
  4 10.5.6.5 12 msec

The answer is that all nodes will swap the incoming SR label for the outgoing SR label, which in this case is always 16005 because all nodes have the same (default) SRGB. As we saw in R1’s LFIB, an incoming label of 16005 is swapped for 16005.

If we run the traceroute on R2, the traffic will use LDP labels, because R2 is not configured to prefer SR for labels imposed onto IP traffic. Now R2 is the one originating the traffic and doing label imposition, so the default LDP imposition behaviour is observed.

R2#traceroute 5.5.5.5 source lo0 probe 1
Type escape sequence to abort.
Tracing the route to 5.5.5.5
VRF info: (vrf in name/id, vrf out name/id)
  1 10.2.3.3 [MPLS: Label 24008 Exp 0] 6 msec
  2 10.4.6.6 [MPLS: Label 24 Exp 0] 6 msec
  3 10.5.6.5 8 msec

Conclusion

SR and LDP can co-exist with no issues. For that matter, SR, LDP, RSVP and BGP-LU can all co-exist. The label manager process on the router ensures that each protocol allocates labels that do not overlap with one another. The SRGB label range is reserved only for SR global SIDs.

When an IP packet arrives, by default the LDP label is imposed on the packet. To change this behaviour, you configure sr-prefer. IP packets will then have the SR label imposed instead.

Regardless of whether the LDP or SR label is imposed on IP packets, LDP labels will be swapped for the outgoing LDP label, and SR labels will be swapped for the outoing SR label. Both LDP and SR labels are present in the LFIB.

In the next part, we will look at LDP/SR interworking when some nodes cannot run SR at all. This may happen when a router runs an OS that does not support SR. We will configure an SR mapping server which will advertise the SR index of the LDP-only node into the IGP to allow SR and LDP to interwork together.

Last updated