Segment Routing

I showed how to use MPLS transport tunnel signaling protocols such as LDP and RSVP-TE to establish MPLS transport tunnels to carry Overlay network services such as ePipe, VPLS and VPRN (L3VPN) for Nokia, Cisco and Juniper routers in my earlier articles. RSVP-TE offers Traffic Engineering (TE) capability where the path of an LSP can be manually defined hop-by-hop or signaled based on meeting certain bandwidth requirements instead of just following the IGP’s shortest path as in the case of LDP. TE allows a carrier to maximize its network resource utilization beyond IGP’s shortest paths that sometime overloads certain shortest-path links and routers while other links and routers are being idle and are only used during network failures.

While many carriers have been quite successful in consolidating their legacy networks such as TDM, ATM, Frame Relay, and IP into a single QoS-ready IP/MPLS network in the past decade and use the IP/MPLS QoS-ready platform to offer new network services, many carriers find themselves running both LDP and RSVP-TE transport tunnel signaling protocols in their MPLS networks. This is because while RSVP-TE offers Underlay network TE LSP signaling capability, the protocol generates too many LSP soft-state refresh messages and every router along the RSVP-TE signaled TE path needs to store some RSVP-TE info for each LSP. These limit the scalability of RSVP-TE as the Underlay network TE LSP signaling protocol for large MPLS networks. Also, it is difficult to manually define TE LSPs without some network analytic tools and network traffic historical data. Therefore, many carriers use RSVP-TE only for specific network applications such as VoIP Phone services and rely on LDP for its simplicity for shortest path label switching to carry all other network services’ traffic.

In the past few years, a new source routing TE signaling protocol called Segment Routing (SR) defined in RFC 8402 is getting a lot of attentions from carriers.

Each Segment Identifier (SID) in SR is an instruction to the router and thus it carries more information than the traditional MPLS Label, which simply identifies an egress interface of the router. Each SR router supports the following SID operations to manipulate SID on each packet to the destination:

  • PUSH
    • Similar to MPLS Label PUSH operation
    • SIDs that are pushed onto the packet can present a prefix, a node or an adjacent interface of a router
  • CONTINUE
    • Similar to MPLS Label SWAP operation
    • A SR router receiving this instruction (e.g., node SID) uses its IGP shortest-paths (i.e., ECMP) to forward this packet to the router with the specified node SID similar to RSVP-TE’s loose route traffic forwarding except that RSVP-TE does not support ECMP
  • NEXT
    • Similar to MPLS Label POP operation
    • A SR router receiving this instruction (e.g., node SID) pops the SID and forwards the packet to its specified egress interface
    • If there is no more SID in the packet after the SR’s NEXT operation, the packet has reached its final destination and a standard IPv4 packet is presented to the destination host. Otherwise, the packet resumes on its SR-TE path to its final destination

The benefits of SR are:

  • Only head-end routers need to keep track of the list of Segment IDs (SIDs) for each destination and push the list of SIDs onto every packet to the destination (i.e., source routing). Intermediate routers are not required to keep any TE path or state information and thus SR TE signaling protocol is very scalable for large networks than RSVP-TE
  • Support granular per flow or per application TE routing over a large network. In the regular destination subnet based routing, routers route traffic based on IP subnets (e.g., /24) and occasionally host prefix (e.g., /32). In SR, only the head-end router learns the list of SIDs for a given destination such as a host or an application etc…. Therefore, SR can support more granular per flow or per application routing
  • ECMP for SR traffic forwarding
  • Support manual, distributed and centralized SR signaling. This article focuses on manual SR signaling where the underlay TE LSP is configured manually by users at the head-end router. The distributed and centralized SR signaling methods are more interesting in the era of Software Defined Network (SDN) where a centralized SDN controller can signal, upon applications’ or routers’ network requests, the head-end router with a list of Segment Identifiers (SID) to create an Underlay TE LSP to the destinations. Please refer to my article, Bell Lab’s Smart Network Fabric and Network Function Interconnection for more information about centralized SR TE tunnel signaling
  • More flexible SID format and operation definitions such as using IPv6 address as SID to embed both forwarding and Service Function Chaining instructions
  • No need to run a separate Segment distribution protocol as in the case of MPLS using LDP or RSVP-TE. SR. SR enhanced IGP such as SR-ISIS and SR-OSPF is used to distribute SID mapping info for prefixes, hosts and adjacent interfaces in addition to the regular IGP’s Link-State information

This article discusses the configuration and verification of SR on Nokia’s 7750 routers to signal both IGP’s shortest path and TE LSPs similar to the capabilities of LDP and RSVP-TE MPLS transport label signaling protocols respectively. SR’s built-in capability for Fast ReRoute (FRR) using Loop-Free Alternate (LFA) is also shown. Similar to all my previous blogs, all the Nokia 7750 routers run on GNS3 network emulator on a Windows 10 PC with 16GB RAM.

Network Setup

Below shows the network topology used in this blog for verifying SR. An ePipe 100 is setup between R1 and R4 so that PC1 and PC2 connected to the SAP ports of ePipe 100 can communicate with each other as the two PCs are on the same IP subnet of 192.168.1.0/24. In SR, we call the ePipe as Overlay ePipe network service between R1 and R4 and we need an Underlay network tunnel (i.e., SR Tunnel) to transport the Overlay network traffic.

All routers have ISIS adjacencies with each other for IP connectivity and thus they can reach each others’ system addresses of 10.10.10.X/32.

The ISIS software running on the Nokia 7750 routers support SR (i.e., SR-ISIS). We will show SR-ISIS extended SROS commands and config in the later sections.

SR epipe 100

With SR-ISIS running among the routers, TE and IGP shortest path MPLS LSPs (i.e., Underlay Network Tunnels) can be established for ePipe 100 (i.e., Overlay network service). The following shows the Underlay Network paths for non-TE (i.e., ISIS shortest path) and TE LSPs for Overlay ePipe 100:

segment routing lab.PNG
  • non-TE LSP – R1 – R2 – R4 (or ISIS’ shortest path)
  • TE LSP         – R1 – R3 – R2 – R4 (network designer specified path)

Introduction to Segment Routing

Before we go to far to show SR provisioning on Nokia’s 7750 routers, let us take a step back and explain some key concepts of SR to show why carriers are interested in using it to replace the RSVP-TE tunnel signaling protocol over MPLS transport and how SR can be useful for the future SDN-based network services.

Segment routing is based on source routing. In other words, an egress router can steer a packet through an ordered list of instructions, or segments by stacking the necessary Prefix-SIDs and/or Adjacency-SIDs onto each packet. You can think of a SID as a MPLS label in SR-MPLS but SR operations are Push, Next and Continue instead of MPLS operations Push, Swap and Pop. For SR’s Next and Continue operations, SR router will use ECMP to forward packets to the next SID or segment, whenever possible.

For a non-TE LSP, ePipe 100’s traffic from R1 to R4 using the shortest Underlay Network path (i.e., R1 – R2 – R4). R1 pushs the prefix-SID or Node SID of R4, 519004 onto each packet it sends to R4. Node SID normally means a multi-hop path to the destination. Routers along the path perform shortest path prefix lookup similar to normal destination based routing to the final destination. In the case of R2, since it is the penultimate hop of R4, it will pop the SID or MPLS label before forwarding the packets to R4. Another benefit of using SR for shortest path routing is that all SR routers automatic create ECMP-aware shortest path SR tunnels for redundancy and throughput improvement.

For a TE LSP, Adjacency-SID and/or Prefix-SIDs are stacked by the head-end router onto each packet it sent to the destination using the list of Segments or label either provisioned manually via CLI (this article) or centrally via a SDN controller to the head-end router. The following shows a Wireshark capture of a Ping request and response packets over the Overlay ePipe 100 network service using the Underlay SR-TE LSP or tunnel involving R1 – R3 – R2 – R4). Multiple Adj-SIDs or Link SIDs (e.g., 262141, and 262140) are pushed by R1 to direct the traffic through R3 and R2 to R4 for every Ping Request packet to R4 (i.e., source routing). The 3rd or bottom MPLS label, 262137 refers to ePipe 100 on R4 and thus it is actually the service label. We will examine the TE LSP in more details in SR TE LSP verification in later section.

TE ping request

A interesting design of SR is the use of manually configured network-wide unique Prefix-SID for each router in the network. Adjacency-SIDs representing the link segments in the network are only local significant instead of network-wide unique and are assigned dynamically by SR-ISIS. Both Prefix-SIDs and Adjacency-SIDs and exchanged among the routers via SR-ISIS. Through SR-ISIS, each router in the network has a complete network map of Prefix-SIDs and Adjacency-SIDs for source routing operations. Note again that for any intermediate routers for any traffic, the routers only pop the top Segment or label and forward the traffic to its egress interface according to the Segment or label it distributed earlier using SR-ISIS. Only the head-end routers store state information (e.g., list of Segments for a destination) and thus SR is very scalable as a Underlay TE tunnel signaling protocol. We could even signal a list of Segments to a head-end router on a per-flow or per-application basis without worrying any significant routing table expansion on other routers.

SR also has a built-in Fast ReRoute (FRR) capability similar to RSVP-TE by pre-computing Loop-Free Alternate (LFA) paths for each destination, whenever possible and install them onto the label forwarding table as the backup paths. This enables routers under SR to achieve less than 50ms failover time similar to RSVP-TE’s FRR.

SR Provisioning Procedures

The steps to provision MPLS network services using SR as the MPLS transport tunnel signaling protocol is same as using LDP or RSVP-TE that I have shown in my previous blogs as follows:

  1. Setup IGP (e.g., OSPF or ISIS) among all routers for IP connectivity. In this article, we will use ISIS
  2. Setup MPLS transport tunnel signaling protocol on all routers. Before, we use either LDP (LSP to follow IGP’s shortest path) or RSVP-TE (LSP to follow a desired TE path). In SR, we simply use the SR enhanced IGP protocol for Prefix-SID and Adjacency SID distribution. In this article, we use SR enhanced ISIS or SR-ISIS as the MPLS transport tunnel signaling protocol
  3. Setup service tunnel signaling to use the MPLS transport tunnel or LSP for network services. In this article, we will use TLDP to signal the service tunnel of ePipe 100 for it to send traffic over the MPLS LSP setup in Step 2.

Step 1 – ISIS Setup

The following shows the ISIS setup for R1. Similar ISIS configs are used on R2 to R4.

A:R1>config>router>isis# info 
----------------------------------------------
            level-capability level-2
            area-id 49.01
            ipv6-routing native
            level 2
                wide-metrics-only
            exit
            interface "system"
                no shutdown
            exit
            interface "toR2"
                interface-type point-to-point
                no shutdown
            exit
            interface "toR3"
                interface-type point-to-point
                no shutdown
            exit
            no shutdown

The ISIS configuration on R1 is very standard and we have shown it many times in my earlier blogs.

To make sure the ISIS config is working, run the following commands to verify ISIS adjacency and routing table.

A:R1>config>router>isis# show router isis adjacency 

===========================================================================
Rtr Base ISIS Instance 0 Adjacency 
===========================================================================
System ID                Usage State Hold Interface                   MT-ID
---------------------------------------------------------------------------
R2                       L2    Up    25   toR2                          0
R3                       L2    UP    21   toR3                          0
---------------------------------------------------------------------------
Adjacencies : 2

The following shows the routing table with ISIS routes learnt from remote routers.

A:R1>config>router>isis# show router route-table 

===========================================================================
Route Table (Router: Base)
===========================================================================
Dest Prefix[Flags]                            Type    Proto     Age        Pref
      Next Hop[Interface Name]                                    Metric   
-------------------------------------------------------------------------------
10.1.2.0/28                                   Local   Local     02h12m48s  0
       toR2                                                         0
10.1.3.0/28                                   Local   Local     02h12m48s  0
       toR3                                                         0
10.2.3.0/28                                   Remote  ISIS      02h12m40s  18
       10.1.2.2                                                     20
10.2.4.0/28                                   Remote  ISIS      02h12m40s  18
       10.1.2.2                                                     20
10.2.5.0/28                                   Remote  ISIS      02h12m40s  18
       10.1.2.2                                                     20
10.3.4.0/28                                   Remote  ISIS      00h00m03s  18
       10.1.2.2                                                     30
10.3.7.0/28                                   Remote  ISIS      02h12m00s  18
       10.1.2.2                                                     30
10.10.10.1/32                                 Local   Local     02h14m12s  0
       system                                                       0
10.10.10.2/32                                 Remote  ISIS      02h12m33s  18
       10.1.2.2                                                     10
10.10.10.3/32                                 Remote  ISIS      02h12m01s  18
       10.1.2.2                                                     20
10.10.10.4/32                                 Remote  ISIS      00h00m00s  18
       10.1.2.2                                                     20
-------------------------------------------------------------------------------
No. of Routes: 11
Flags: n = Number of times nexthop is repeated
       B = BGP backup route available
       L = LFA nexthop available
       S = Sticky ECMP requested

Step 2 – SR-ISIS MPLS Transport Signaling Setup

In this step, we use SR enhanced features of ISIS (i.e., SR-ISIS) as the MPLS transport signaling protocol to exchange Prefix-SIDs and Adjacency-SIDs among the routers.

First of all, we need to define the Segment Routing Global Block (SRGB), which is simply the start and end label range for SR operations. In this article, we will use the following SID range from 519000 to 524000.

A:R1>config>router>mpls-labels># info 
----------------------------------------------
            sr-labels start 519000 end 524000 

With SRGB being initialized, we now enhance the ISIS config for SR operations:

A:R1>config>router>isis# info 
----------------------------------------------
            level-capability level-2
            area-id 49.01
            traffic-engineering
            advertise-router-capability as
            loopfree-alternate
            ipv6-routing native
            level 2
                wide-metrics-only
            exit
            interface "system"
                ipv4-node-sid index 1
                no shutdown
            exit
            interface "toR2"
                interface-type point-to-point
                no shutdown
            exit
            interface "toR3"
                interface-type point-to-point
                no shutdown
            exit
            segment-routing           
                prefix-sid-range start-label 519000 max-index 5000
                no shutdown
            exit
            no shutdown

We have mentioned that network-wide unique SID is manually assigned for each router. One commonly used scheme is to use Prefix-SID index:

Prefix-SID = start-label + Prefix-SID index

For ease of illustration, we will use SID index 1 for R1 and index 2 for R2 etc… In other words, with SID start label from 519000, Prefix-SID for R1 is 519001 and Prefix-SID for R4 is 519004.

To verify that SR-ISIS can exchange Prefix-SID for each node, use the following command:

A:R1# show router isis prefix-sids 

===========================================================================
Rtr Base ISIS Instance 0 Prefix/SID Table
===========================================================================
Prefix                            SID        Lvl/Typ    SRMS   AdvRtr
                                                         MT     Flags
---------------------------------------------------------------------------
10.10.10.1/32                     1          2/Int.      N     R1
                                                            0       NnP
10.10.10.2/32                     2          2/Int.      N     R2
                                                            0       NnP
10.10.10.3/32                     3          2/Int.      N     R3
                                                            0       NnP
10.10.10.4/32                     4          2/Int.      N     R4
                                                            0       NnP
---------------------------------------------------------------------------
No. of Prefix/SIDs: 4 (4 unique)
---------------------------------------------------------------------------
SRMS : Y/N  = prefix SID advertised by SR Mapping Server (Y) or not (N)
       S    = SRMS prefix SID is selected to be programmed
Flags: R    = Re-advertisement
       N    = Node-SID
       nP   = no penultimate hop POP  
       E    = Explicit-Null  
       V    = Prefix-SID carries a value  
       L    = value/index has local significance  

We have not yet specified any TE path for the LSP between R1 and R4 and thus the LSP signaled by SR-ISIS will simply follow the ISIS’ shortest path between R1 and R4. The following commands verify that the shortest path (non-TE) LSP is created between R1 and R4 so that we can use it for our ePipe 100 in Step 3:

A:R1# oam lsp-ping prefix 10.10.10.4/32 sr-isis 
LSP-PING 10.10.10.4/32: 80 bytes MPLS payload
Seq=1, send from intf toR2, reply from 10.10.10.4
       udp-data-len=32 ttl=255 rtt=7.21ms rc=3 (EgressRtr)

---- LSP 10.10.10.4/32 PING Statistics ----
1 packets sent, 1 packets received, 0.00% packet loss
round-trip min = 7.21ms, avg = 7.21ms, max = 7.21ms, stddev = 0.000ms
A:R1# oam lsp-trace prefix 10.10.10.4/32 sr-isis 
lsp-trace to 10.10.10.4/32: 0 hops min, 0 hops max, 104 byte packets
1  10.10.10.2  rtt=31.8ms rc=8(DSRtrMatchLabel) rsc=1 
2  10.10.10.4  rtt=85.3ms rc=3(EgressRtr) rsc=1 

Similarly, the LSP path from R4 to R1 follows the same ISIS’ shortest path.

A:R4# oam lsp-trace prefix 10.10.10.1/32 sr-isis 
lsp-trace to 10.10.10.1/32: 0 hops min, 0 hops max, 104 byte packets
1  10.10.10.2  rtt=30.6ms rc=8(DSRtrMatchLabel) rsc=1 
2  10.10.10.1  rtt=25.6ms rc=3(EgressRtr) rsc=1 

Below shows the Wireshark capture of the Ping response from R4 to R1. Note that we have not yet specified any TE LSP for R4 to R1 and thus the same ISIS’ shortest path (Prefix-SID 519001) is found on the trace.

non-TE ping reply from R4

Step 3 – Service Tunnel Setup

With the LSP setup via SR-ISIS between R1 and R4, we can create the SDP and ePipe 100 between the two routers. The following shows the SDP and ePipe 100 config on R1. A similar service config is on R4.

A:R1# configure service 
A:R1>config>service# info 
----------------------------------------------
        sdp 4 mpls create
            far-end 10.10.10.4
            sr-isis
            keep-alive
                shutdown
            exit
        exit
        customer 1 create
            description "Default customer"
        exit
        epipe 100 customer 1 create
            sap 1/1/5 create
                no shutdown
            exit
            spoke-sdp 4:100 create
                no shutdown
            exit
            no shutdown
        exit

Service tunnel signaling for ePipe uses TLDP. Therefore, we should not shutdown LDP in the config. Instead, specify a LDP targeted-session (i.e., TLDP session) between R1 and R4 as follows:

A:R1>config>router# ldp 
A:R1>config>router>ldp# info 
----------------------------------------------
            interface-parameters
            exit
            targeted-session
                peer 10.10.10.4
                    no shutdown
                exit
            exit
            no shutdown

The SDP between R1 and R4 for signaling the MPLS transport tunnel is now up.

A:R1# show service sdp 

===========================================================================
Services: Service Destination Points
===========================================================================
SdpId  AdmMTU  OprMTU  Far End          Adm  Opr         Del     LSP   Sig
---------------------------------------------------------------------------
4      0       8682    10.10.10.4       Up   Up          MPLS    I     TLDP
---------------------------------------------------------------------------
Number of SDPs : 1
----------------------------------------------------------------------------
Legend: R = RSVP, L = LDP, B = BGP, M = MPLS-TP, n/a = Not Applicable
        I = SR-ISIS, O = SR-OSPF, T = SR-TE, F = FPE

The TLDP session for signaling the service tunnel for ePipe 100 between R1 and R4 is also established.

A:R1# show router ldp session 

===========================================================================
LDP IPv4 Sessions
===========================================================================
Peer LDP Id         Adj Type  State         Msg Sent  Msg Recv  Up Time
---------------------------------------------------------------------------
10.10.10.4:0        Targeted  Established   13        15        0d 00:00:32
---------------------------------------------------------------------------
No. of IPv4 Sessions: 1

The vccv-ping and vccv-trace for ePipe 100 between R1 and R4 is successful:

A:R1# oam vccv-ping 4:100 
VCCV-PING 4:100 88 bytes MPLS payload
Seq=1, send from intf toR2 to NH 10.1.2.2
       reply from 10.10.10.4 via Control Channel
       udp-data-len=32 rtt=3.66ms rc=3 (EgressRtr)

---- VCCV PING 4:100 Statistics ----
1 packets sent, 1 packets received, 0.00% packet loss
round-trip min = 3.66ms, avg = 3.66ms, max = 3.66ms, stddev = 0.000ms


*A:R1# oam vccv-trace 4:100                            
VCCV-TRACE 4:100  with 88 bytes of MPLS payload
1  10.10.10.4  rtt=4.31ms rc=3(EgressRtr)

Finally, the end-to-end ping between PC1 and PC2 over ePipe 100 is successful.

PC1> ping 192.168.1.2
84 bytes from 192.168.1.2 icmp_seq=1 ttl=64 time=62.272 ms
84 bytes from 192.168.1.2 icmp_seq=2 ttl=64 time=9.075 ms
84 bytes from 192.168.1.2 icmp_seq=3 ttl=64 time=12.381 ms

Below shows the Wireshark capture on link R1-R2 during the PC ping over ePipe 100:

ping request.PNG

A Prefix-SID 519004 is pushed by R1 for each packet it sent to R4 over ePipe 100. Again, Prefix-SID normally means a multi-hop path and each router along the path will forward the packet until the penultimate hop (e.g., R2) where it will pop the Prefix-SID or MPLS label before delivering the packet to the destined router, R4.

Note that the second MPLS label 262137 refers to ePipe 100 (i.e., service label). We can verify this by using the following commands:

A:R1>config>service>epipe>sap$ show service sdp-using 

===========================================================================
SDP Using
===========================================================================
SvcId      SdpId              Type   Far End              Opr   I.Label E.Label
                                                          State         
---------------------------------------------------------------------------
100        4:100              Spok   10.10.10.4           Up    262137  262137
---------------------------------------------------------------------------
Number of SDPs : 1

Below is the ping response from R4 to R1:

ping reply

Similarly, the first MPLS label from R4 to R1 in the Ping Reply is 519001, which is the Prefix-SID of R1. The service label for ePipe 100 is the same on both side and thus the 2nd MPLS label is 262137 as well.

Segment Routing with TE LSP

We just show how to setup SR on Nokia 7750 routers and map traffic of ePipe 100 onto the SR signaled Underlay Network tunnel or LSP. Only one Prefix-SID 51900X is found on the ePipe traffic according to the Wireshark capture as we have not yet specified any TE LSP to carry ePipe 100’s traffic.

Let us modify R1 to use the TE LSP of R1 – R3 – R2 – R4 (i.e., red TE LSP shown in the previous diagram).

*A:R1>config>router>mpls# info 
----------------------------------------------
            interface "system"
                no shutdown
            exit
            path "R1-R4-TE-strict"
                hop 1 10.10.10.3 strict
                hop 2 10.10.10.2 strict
                hop 4 10.10.10.4 strict
                no shutdown
            exit
            lsp "lsp_R1-R4-TE" sr-te
                to 10.10.10.4
                primary "R1-R4-TE-strict"
                exit
                no shutdown
            exit
            no shutdown

To use SR to signal TE MPLS transport tunnel, change the SDP config from sr-isis to sr-te-lsp:

*A:R1>config>service# sdp 4 
*A:R1>config>service>sdp# info 
----------------------------------------------
            far-end 10.10.10.4
            sr-isis
            sr-te-lsp "lsp_R1-R4-TE"
            keep-alive
                shutdown
            exit
            no shutdown

After changing the SDP to use SR TE signaling, the SDP should still be UP.

*A:R1>config>service>sdp# show service sdp 

===========================================================================
Services: Service Destination Points
===========================================================================
SdpId  AdmMTU  OprMTU  Far End          Adm  Opr         Del     LSP   Sig
----------------------------------------------------------------------------
4      0       8674    10.10.10.4       Up   Up          MPLS    T     TLDP

The following shows the hops defined for SR TE LSP, lsp_R1-R4-TE where traffic from R1 to R4 will go through R3 and R2:

A:R1>config>router>mpls# show router mpls sr-te-lsp "lsp_R1-R4-TE" path detail  
===========================================================================
MPLS SR-TE LSP lsp_R1-R4-TE Path  (Detail)
===========================================================================
Legend : 
    S      - Strict                      L      - Loose
    A-SID  - Adjacency SID               N-SID  - Node SID 
    +      - Inherited 
===========================================================================
---------------------------------------------------------------------------
SR-TE LSP lsp_R1-R4-TE Path R1-R4-TE-strict
---------------------------------------------------------------------------
LSP Name         : lsp_R1-R4-TE
Path LSP ID      : 37888                
From             : 10.10.10.1           To                   : 10.10.10.4
Admin State      : Up                   Oper State           : Up
Path Name        : R1-R4-TE-strict      Path Type            : Primary
Path Admin       : Up                   Path Oper            : Up
Path Up Time     : 0d 01:12:53          Path Down Time       : 0d 00:00:00
Retry Limit      : 0                    Retry Timer          : 30 sec
Retry Attempt    : 1                    Next Retry In        : 0 sec
 
CSPF             : Disabled             Oper CSPF            : Disabled
 
Bandwidth        : No Reservation       Oper Bandwidth       : 0 Mbps
Hop Limit        : 255                  Oper HopLimit        : 255
Setup Priority   : 7                    Oper Setup Priority  : 7
Hold Priority    : 0                    Oper Hold Priority   : 0
Inter-area       : N/A                  
 
PCE Updt ID      : 0                    PCE Updt State       : None
PCE Upd Fail Code: noError
 
PCE Report       : Disabled+            Oper PCE Report      : Disabled
PCE Control      : Disabled             Oper PCE Control     : Disabled
PCE Compute      : Disabled             Oper PCE Compute     : Disabled
 
Include Groups   :                      Oper Include Groups  : 
None                                           None
Exclude Groups   :                      Oper Exclude Groups  : 
None                                           None
 
IGP/TE Metric    : 16777215             Oper Metric          : 16777215
Oper MTU         : 8678                 Path Trans           : 1
Failure Code     : noError
Failure Node     : n/a                  
Explicit Hops    :                      
    10.10.10.3(S)      -> 10.10.10.2(S)      -> 10.10.10.4(S)     
Actual Hops      :                      
    10.1.3.3 (10.10.10.3)(A-SID)                 Record Label        : 262141
 -> 10.2.3.2 (10.10.10.2)(A-SID)                 Record Label        : 262141
 -> 10.2.4.4 (10.10.10.4)(A-SID)                 Record Label        : 262140

LSP Ping through the TE LSP is OK

*A:R1>config>router>mpls# oam lsp-ping  lsp_R1-R4-TE sr-te 
LSP-PING lsp_R1-R4-TE: 96 bytes MPLS payload
Seq=1, send from intf toR3, reply from 10.10.10.4
       udp-data-len=32 ttl=255 rtt=21.6ms rc=3 (EgressRtr)

---- LSP lsp_R1-R4-TE PING Statistics ----
1 packets sent, 1 packets received, 0.00% packet loss
round-trip min = 21.6ms, avg = 21.6ms, max = 21.6ms, stddev = 0.000ms

LSP Trace through the TE LSP shows that traffic from R1 to R4 goes through R3 and R2.

*A:R1>config>router>mpls# oam lsp-trace  lsp_R1-R4-TE sr-te 
lsp-trace to lsp_R1-R4-TE: 0 hops min, 0 hops max, 176 byte packets
1  10.10.10.3  rtt=8.21ms rc=3(EgressRtr) rsc=3 
1  10.10.10.3  rtt=18.5ms rc=8(DSRtrMatchLabel) rsc=2 
2  10.10.10.2  rtt=10.7ms rc=3(EgressRtr) rsc=2 
2  10.10.10.2  rtt=16.8ms rc=8(DSRtrMatchLabel) rsc=1 
3  10.10.10.4  rtt=8.90ms rc=3(EgressRtr) rsc=1 

The following shows the Wireshark captures for ping traffic over ePipe 100 using the SR signaled TE LSP:

TE ping request

The SR Adjacency-SID (262141 and 262140) is same as the labels specified in the command – show router mpls sr-te-lsp “lsp_R1-R4-TE” path detail. Again, the 3rd label 262137 is the service label of ePipe 100 for R4. 

Loop-Free Alternate

Loop-Free Alternate (LFA) is pre-computed path for a given destination. The label for LFA is then installed in the label forwarding table as the backup path so that SR can support less than 50ms network failover recovery.

The following shows the LFA pre-computed for each destination:

A:R1>config>router>mpls# show router route-table alternative 

===========================================================================
Route Table (Router: Base)
===========================================================================
Dest Prefix[Flags]                            Type    Proto     Age        Pref
      Next Hop[Interface Name]                                    Metric   
      Alt-NextHop                                                Alt-      
                                                                Metric     
---------------------------------------------------------------------------
10.1.2.0/28                                   Local   Local     01h48m25s  0
       toR2                                                         0
10.1.3.0/28                                   Local   Local     01h48m25s  0
       toR3                                                         0
10.2.3.0/28                                   Remote  ISIS      00h00m00s  18
       10.1.2.2                                                     20
       10.1.3.3 (LFA)                                               30
10.2.4.0/28                                   Remote  ISIS      00h00m00s  18
       10.1.2.2                                                     20
       10.1.3.3 (LFA)                                               30
10.2.5.0/28                                   Remote  ISIS      00h00m00s  18
       10.1.2.2                                                     20
       10.1.3.3 (LFA)                                               30
10.3.4.0/28                                   Remote  ISIS      01h48m18s  18
       10.1.3.3                                                     20
       10.1.2.2 (LFA)                                               30
10.3.7.0/28                                   Remote  ISIS      01h48m18s  18
       10.1.3.3                                                     20
       10.1.2.2 (LFA)                                               30
10.4.5.0/28                                   Remote  ISIS      00h00m02s  18
       10.1.2.2                                                     30
       10.1.3.3 (LFA)                                               30
10.10.10.1/32                                 Local   Local     01h49m03s  0
       system                                                       0
10.10.10.2/32                                 Remote  ISIS      00h00m02s  18
       10.1.2.2                                                     10
       10.1.3.3 (LFA)                                               20
10.10.10.3/32                                 Remote  ISIS      01h48m18s  18
       10.1.3.3                                                     10
       10.1.2.2 (LFA)                                               20
10.10.10.4/32                                 Remote  ISIS      00h00m02s  18
       10.1.2.2                                                     20
       10.1.3.3 (LFA)                                               20
---------------------------------------------------------------------------
No. of Routes: 12
Flags: n = Number of times nexthop is repeated
       Backup = BGP backup route      
       LFA = Loop-Free Alternate nexthop
       S = Sticky ECMP requested


The backup paths for the FLAs are then installed in the label forwarding table as FRR backup path.

A:R1# show router fp-tunnel-table 1 

===========================================================================
IPv4 Tunnel Table Display

Legend: 
B - FRR Backup
===========================================================================
Destination                                  Protocol            Tunnel-ID
  Lbl                                                             
    NextHop                                                      Intf/Tunnel
---------------------------------------------------------------------------
10.1.2.2/32                                  SR                   -
  3
  10.1.2.2                                                     1/1/2
  519002
  10.1.3.3(B)                                                  1/1/1
10.1.3.3/32                                  SR                   -
  3
  10.1.3.3                                                     1/1/1
  519003
  10.1.2.2(B)                                                  1/1/2
10.10.10.2/32                                SR-ISIS-0            -
  519002                              
  10.1.2.2                                                     1/1/2
  519002
  10.1.3.3(B)                                                  1/1/1
10.10.10.3/32                                SR-ISIS-0            -
  519003
  10.1.3.3                                                     1/1/1
  519003
  10.1.2.2(B)                                                  1/1/2
10.10.10.4/32                                SR-ISIS-0            -
  519004
  10.1.2.2                                                     1/1/2
  519004
  10.1.3.3(B)                                                  1/1/1
10.10.10.4/32                                SR-TE                -
  262140/262141
  10.1.3.3                                                     SR
---------------------------------------------------------------------------
Total Entries : 6
---------------------------------------------------------------------------

Conclusion

We just show Segment Routing (SR) being used to replace RSVP-TE as the TE tunnel signaling protocol over MPLS transport on Nokia’s 7750 routers. SR extends IGP to becomes ISIS-SR and OSPF-SR for distributing Segment ID / Interface binding in addition to the regular Link State information and thus no separate label distribution protocol is needed. There are many standard and draft RFCs (e.g., RFC 8402 etc…) to try to establish Segment Routing as the new traffic engineering cross domain tunnel signaling protocol particularly for WAN and Data Center operations and extension. We will examine these advanced Segment Routing’s features in the future articles.

One thought on “Segment Routing

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s