Segment Routing on IOS-XR

Cisco has released some support for segment-routing on IOS-XR 5.2.0 so what better time to lab it up. I’ve got four IOS-XRv boxes running 5.2.0:

RP/0/0/CPU0:XR1#sh ver | include XR
Cisco IOS XR Software, Version 5.2.0[Default]

Currently IS-IS is the only protocol with support in XR. There are drafts to get this working in both OSPFv2 and OSPFv3

Segment Routing?

Segment routing is a huge topic. In the long run it’ll make it very easy for an SDN controller to force packets through the network in any way it wants. The draft says that it can use the existing MPLS data plane (aka labels) or the IPv6 data plane (header extensions). Right now support is for the MPLS data plane only. The nice thing here is that all devices that can currently switch based on labels should really only need a software upgrade to run segment routing in it’s current form.

Currently, in order to populate the MPLS data plane with labels you need a MPLS control plane protocol to distribute those labels. With segment routing, those labels are distributed with the IGP. Your core is now simplified as it’s only running the IGP with no LDP or RSVP. Your core no longer needs to keep LDP or RSVP state at all.

Traffic Engineering

Take the following simple diagram into consideration:
SR-1
I’d like to use both paths to get from PE1 to PE2 for different taffic flows. This is possible with RSVP by creating multiple RSVP-TE tunnels:
SR-2
The above works perfectly fine, but those P routers need to keep state for each and every RSVP tunnel going through them. In segment routing, there is a concept of a node segment and adjaceny segment. There are also other segment types but I won’t go into that yet. With the MPLS dataplane, each segment has a label. I can therefore force traffic to go over a certain segment by adding the segment label to the stack.
SR-3
In the above diagram, if I want PE1 to send to PE2 via the shortest path, it simply imposes the node segment of PE2 onto the packet and sends it on. Every router in the core knows what PE2’s node segment is and as such the packet is pushed through using only that single label. Note that standard MPLS PHP behaviour is still used:
SR-4

If I wanted to force traffic to PE2 to go over the P1-P2 link and then the P2-P3 link, I would stack the labels to ensure it went that way. It’s the ingress PE that decides this:
SR-5
PE1 has stacked the labels in such a way that it forces the packet to go to particular segments. The core does not need to contain any of the LSP state. It simply installs the labels from the IGPs previously sent.

Configuration

Segment Routing in 5.2.0 has been enabled, but at a preliminary level only. IS-IS is the only IGP supported. MPLS dataplane is only supported. I can’t seem to find a way to advertise adjaceny segments yet, only node segments. All of the above is fine for an MPLS L3VPN lab. I’ll be using the following topology:
SR-6
The CEs are running OSPFv2 and advertising their loopbacks into OSPF:

interface Loopback0
 ip address 100.100.100.100 255.255.255.255
 ip ospf 1 area 0
!
interface GigabitEthernet0/0.11
 encapsulation dot1Q 11
 ip address 10.0.11.1 255.255.255.0
 ip ospf 1 area 0

The PE config is pretty standard:

vrf CUS1
 address-family ipv4 unicast
  import route-target
   100:1
  !
  export route-target
   100:1
  !
 !
!
router ospf CUS1
 vrf CUS1
  redistribute bgp 100
  area 0
   interface GigabitEthernet0/0/0/0.11
   !
  !
 !
!
router bgp 100
 address-family vpnv4 unicast
 !
 neighbor 4.4.4.4
  remote-as 100
  update-source Loopback0
  address-family vpnv4 unicast
  !
 !
 vrf CUS1
  rd 100:4
  address-family ipv4 unicast
   redistribute ospf CUS1
  !
 !
!

XR1 has a VPNv4 session with XR4 and advertising the prefixes over. Segment routing is now enabled under the core IGP, IS-IS:

router isis 1
 is-type level-2-only
 net 49.0001.0000.0000.0001.00
 address-family ipv4 unicast
  metric-style wide
  segment-routing mpls
 !
 interface Loopback0
  address-family ipv4 unicast
   prefix-sid index 1000
  !
 !
 interface GigabitEthernet0/0/0/1
  address-family ipv4 unicast
  !
 !
 interface GigabitEthernet0/0/0/2
  address-family ipv4 unicast
  !
 !
!

For now you can only configure the node ID under the loopback interface. Once this is all done, I should have a labbeled router to R4’s loopback, without LDP or RSVP:

RP/0/0/CPU0:XR1#show cef  4.4.4.4 | include labels
Sun Aug 10 19:48:51.587 UTC
     local label 904000      labels imposed {904000}
     local label 904000      labels imposed {904000}

RP/0/0/CPU0:XR1#show mpls int gigabitEthernet 0/0/0/1 detail
Sun Aug 10 19:49:25.145 UTC
Interface GigabitEthernet0/0/0/1:
        LDP labelling not enabled
        LSP labelling not enabled
        MPLS ISIS enabled
        MPLS enabled

There are two labels are XR1 has two equal cost paths to XR4. A quick traceroute will show the same label:

RP/0/0/CPU0:XR1#traceroute 4.4.4.4
Sun Aug 10 19:50:16.191 UTC

Type escape sequence to abort.
Tracing the route to 4.4.4.4

 1  10.0.12.2 [MPLS: Label 904000 Exp 0] 9 msec  0 msec  0 msec
 2  10.0.24.4 0 msec  *  0 msec

Note that L3VPN still uses an inner label, the service/VPN label. The outer transport label has been replaced with the segment routing label. A traceroute from CE1 to CE2 will confirm this:

CE1#traceroute 200.200.200.200 so lo0 numeric
Type escape sequence to abort.
Tracing the route to 200.200.200.200
VRF info: (vrf in name/id, vrf out name/id)
  1 10.0.11.10 1 msec 1 msec 1 msec
  2 10.0.12.2 [MPLS: Labels 904000/16001 Exp 0] 4 msec 3 msec 3 msec
  3 10.0.24.4 [MPLS: Label 16001 Exp 0] 3 msec 7 msec 3 msec
  4 10.0.42.2 4 msec *  4 msec

Conclusions

  • Basic segment routing is increadibly easy to enable
  • I don’t see ISPs changing from RSVP-TE to SR anytime soon, but I think it will happen eventually
  • SDN is a great use case for SR, as the controller can inform PEs which segment labels to stack onto a packet as it ingresses the router
  • Perhaps even the host itself could send a packet with an SR stack imposed. Maybe that host has learnt this stack from the SDN controller? Time will tell

© 2009-2019 Darren O'Connor All Rights Reserved -- Copyright notice by Blog Copyright