Segment Routing

I showed how to use MPLS transport tunnel signaling protocols such as LDP and RSVP-TE for establishing LSPs for MPLS network services on Nokia, Cisco and Juniper routers in my earlier blogs. RSVP-TE offers Traffic Engineering (TE) capability where path of each LSP can be manually defined hop-by-hop instead of just following the IGP’s shortest path as in the case of LDP signaled LSPs. TE allows a carrier to maximize the overall network resource utilization beyond IGP’s shortest path.

MPLS allows a carrier to consolidate its legacy networks such as ATM, Frame Relay and TDM, and future network services onto a single IP/MPLS platform. While carriers have been quite successful in consolidating their legacy networks into a single IP/MPLS network in the past decade, many carriers find themselves running both LDP and RSVP-TE MPLS transport tunnel signaling protocols together in their MPLS networks. This is because while RSVP-TE offers TE LSP signaling capability, the protocol generates too many LSP soft-state refresh messages that limit the scalability of the TE signaling protocol. Also, network resource contention during failover is another planning issue for using RSVP-TE. Therefore, many carriers use RSVP-TE only for specific network applications (e.g., VoIP Phone services etc…) but rely on LDP for its simplicity for majority of their MPLS network services and applications.

For the past few years, a new source routing protocol called Segment Routing (SR) is getting a lot of attentions from carriers who want to have a unified, and scalable traffic engineering tunnel signaling protocol that can support multiple domains using transport protocols such as MPLS and IPv6 etc…

In SR, instead of employing a separate label distribution protocol such as RSVP-TE or LDP, SR extends IGP to become ISIS-SR and OSPF-SR for distribute Segment ID / Interface binding information in addition to the regular Link State information. In this way, through ISIS-SR or OSPF-SR IGP route exchange, a head-end or source router can push all the necessary Segment IDs or instructions onto a packet (i.e., source routing) and the next-hop router can understand the instruction or Segment ID embedded in the packet and forward it to its appropriate egress interface towards the destination.

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 protocols for MPLS transport 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. You can re-run all these SR config and verification on the Nokia 7750 routers all on your home Windows PC.

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.

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 can be established for ePipe 100. The following shows the network paths for non-TE (i.e., ISIS shortest path) and TE LSPs for 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 on each packet. You can think of segments as MPLS labels and in fact, the same MPLS label push, swap and pop operations also take place when a Segment Routing packet transit from source to destination. For example, for ePipe 100’s traffic from R1 to R4 using the ISIS shortest path (i.e., R1 – R2 – R4), R1 will push 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 ISIS shortest path perform normal MPLS operations such as Push, Swap and Pop to forward the packet 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.

For a TE LSP, Adjacency-SID and/or Prefix-SIDs are stacked by the egress router onto each packet it sent to the destination using the SR-ISIS’ label database. The following shows a Wireshark capture of a Ping request and response packets over ePipe 100 using the TE LSP 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. 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.

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 is also a very useful routing protocol for SDN, which has the concept of centralized control and management, and supports network programmability. The fact that each SR packet is self sufficient with the complete instructions (i.e., SIDs) to its destination fits SDN very well. The SDN controller can instruct an egress router with the necessary SIDs that reflect the latest status, and utilization of the network for the egress router to forward traffic over the desired TE path to its destination that is most beneficial to the applications and the network. There are already a few IEFT drafts about using SR for SDN-based network services. We will leave the details of  SR for SDN for a future article.

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

Advertisements

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