LDP to SR Coexistence and Migration

Earlier post has explained SR and LDP Interworking when both protocols exists in the network. In this post, I will be covering how the LDP to SR coexist and migration takes place. P5,P6 and PE7 are LDP nodes and we have to enable SR on LDP domain and have to make sure that everything works as it is. Once SR is configured, we can verify the LFIB and remove the mapping server and LDP.

The configuration will be using the same as in the earlier post of SR and LDP Interworking.

Below topology will be used for simulating the scenario.

Let's verify the output of traceroute sr-mpls on L4. Mapping server is configured on S1 as per the previous post. 16007 is the static prefix-sid configured on S1 (Mapping Server).

       
RP/0/0/CPU0:L4#traceroute sr-mpls 7.7.7.7/32
Wed Apr 29 13:57:35.186 UTC
  0 2.4.0.4 MRU 1500 [Labels: 16007 Exp: 0]
L 1 2.4.0.2 MRU 1500 [Labels: 16007 Exp: 0] 20 ms
L 2 2.5.0.5 MRU 1500 [Labels: 24000 Exp: 0] 30 ms
L 3 5.6.0.6 MRU 1500 [Labels: implicit-null Exp: 0] 30 ms
! 4 6.7.0.7 30 ms
RP/0/0/CPU0:L4#

Now configure segment routing on P6 and PE7 without removing the LDP configuration. This will create SR database with existing LDP label without impacting the traffic and configuration.

       

router isis lab
  address-family ipv4 unicast
   segment-routing mpls
  !
  interface Loopback0
   address-family ipv4 unicast
    prefix-sid index X (Replace X with 6 on P6 and 7 on PE7
    !
  !
 !
 segment-routing ! 

Let's do the trace on L4 after enabling the above configuration on P6 and PE7. Now the check the label values. End to End single label which is Prefix-sid. (Compare it with the above traceroute where we have two labels, one is prefix-sid(16007) and other is ldp(24000)

       

RP/0/0/CPU0:L4# traceroute sr-mpls 7.7.7.7/32
  0 2.4.0.4 MRU 1500 [Labels: 16007 Exp: 0]
L 1 2.4.0.2 MRU 1500 [Labels: 16007 Exp: 0] 40 ms
L 2 2.5.0.5 MRU 1500 [Labels: 16007 Exp: 0] 10 ms
L 3 5.6.0.6 MRU 1500 [Labels: implicit-null Exp: 0] 10 ms
! 4 6.7.0.7 10 ms
RP/0/0/CPU0:L4#

Verify the outout of mpls forwarding on P5 router. Below output shows that 7.7.7.7/32 is having LDP as well as SR label. Removed the rest of configuration for brevity purpose.

       

RP/0/0/CPU0:P5#show mpls forwarding
Local  Outgoing    Prefix             Outgoing     Next Hop        Bytes
Label  Label       or ID              Interface                    Switched
------ ----------- ------------------ ------------ --------------- ------------
16007  16007       SR Pfx (idx 7)     Gi0/0/0/2    5.6.0.6         575
24000  24000       7.7.7.7/32         Gi0/0/0/2    5.6.0.6         0

Control plane and SR-MPLS data plane is established. Now we can remove the mapping server confiuration also. It's not required.

       

RP/0/0/CPU0:S1(config)#segment-routing
RP/0/0/CPU0:S1(config-sr)#no mapping-server
RP/0/0/CPU0:S1#show segment-routing mapping-server
RP/0/0/CPU0:S1#show segment-routing mapping-server prefix-sid-map  ipv4
RP/0/0/CPU0:S1(config-sr)#commit

No Output of mapping server

       

RP/0/0/CPU0:S1#show segment-routing mapping-server prefix-sid-map  ?
Wed Apr 29 14:32:52.756 UTC

Below outout shows the cef table of 5.5.5.5 prefix on PE7. Context-label seems to be the backup label because still LDP is prefered protocol.

       

RP/0/0/CPU0:PE7#show cef 5.5.5.5/32
Wed Apr 29 14:35:24.000 UTC
5.5.5.5/32, version 61, labeled SR, internal 0x1000001 0x81 (ptr 0xa141642c) [1], 0x0 (0xa13f8ad0), 0xa28 (0xa173d604)
 Updated Apr 29 14:02:50.764
 local adjacency 6.7.0.6
 Prefix Len 32, traffic index 0, precedence n/a, priority 3
 Extensions: context-label:16005
   via 6.7.0.6/32, GigabitEthernet0/0/0/0, 15 dependencies, weight 0, class 0 [flags 0x0]
    path-idx 0 NHID 0x0 [0xa189b4d8 0x0]
    next hop 6.7.0.6/32
    local adjacency
     local label 24001      labels imposed {24003}
RP/0/0/CPU0:PE7#

RP/0/0/CPU0:PE7#show cef 4.4.4.4/32
Wed Apr 29 14:35:50.878 UTC
4.4.4.4/32, version 62, labeled SR, internal 0x1000001 0x81 (ptr 0xa1416fa8) [1], 0x0 (0xa13f88f0), 0xa28 (0xa173d65c)
 Updated Apr 29 14:02:50.764
 local adjacency 6.7.0.6
 Prefix Len 32, traffic index 0, precedence n/a, priority 3
 Extensions: context-label:16004
   via 6.7.0.6/32, GigabitEthernet0/0/0/0, 15 dependencies, weight 0, class 0 [flags 0x0]
    path-idx 0 NHID 0x0 [0xa189b4d8 0x0]
    next hop 6.7.0.6/32
    local adjacency
     local label 24021      labels imposed {24020}
RP/0/0/CPU0:PE7#

Below output on PE7 shows that PE7 is maintaining two label databases. SR-MPLS trace shows that 16004 prefix-sid. MPLS trace route shows LDP and SR prefix-sid.

       

RP/0/0/CPU0:PE7#traceroute sr-mpls 4.4.4.4/32 source 7.7.7.7
  0 6.7.0.7 MRU 1500 [Labels: 16004 Exp: 0]
L 1 6.7.0.6 MRU 1500 [Labels: 16004 Exp: 0] 10 ms
L 2 5.6.0.5 MRU 1500 [Labels: 16004 Exp: 0] 20 ms
L 3 1.5.0.1 MRU 1500 [Labels: implicit-null Exp: 0] 50 ms
! 4 1.4.0.4 50 ms

RP/0/0/CPU0:PE7#traceroute mpls ipv4 4.4.4.4/32 source 7.7.7.7
  0 6.7.0.7 MRU 1500 [Labels: 24020 Exp: 0]
L 1 6.7.0.6 MRU 1500 [Labels: 24019 Exp: 0] 0 ms
L 2 5.6.0.5 MRU 1500 [Labels: 16004 Exp: 0] 0 ms
L 3 1.5.0.1 MRU 1500 [Labels: implicit-null Exp: 0] 10 ms
F 4 1.4.0.4 MRU 0 [No Label] 20 ms
RP/0/0/CPU0:PE7#

Above output shows that LDP domain has SR and LDP both configured but by default LDP forwarding is preferred. Now let's prefer SR over LDP by adding below configuration on P5,P6 and PE7.

       

router isis lab  
  address-family ipv4 unicast
   segment-routing mpls sr-prefer

Check the CEF output on PE7 and now we can see the context label is removed and everything is with SR only.

       

RP/0/0/CPU0:PE7#show cef 5.5.5.5/32
Wed Apr 29 14:39:11.725 UTC
5.5.5.5/32, version 88, labeled SR, internal 0x1000001 0x83 (ptr 0xa141642c) [1], 0x0 (0xa13f8e68), 0xa28 (0xa173d4a4)
 Updated Mar  3 09:33:15.916
 local adjacency 6.7.0.6
 Prefix Len 32, traffic index 0, precedence n/a, priority 1
   via 6.7.0.6/32, GigabitEthernet0/0/0/0, 13 dependencies, weight 0, class 0 [flags 0x0]
    path-idx 0 NHID 0x0 [0xa189b4d8 0x0]
    next hop 6.7.0.6/32
    local adjacency
     local label 16005      labels imposed {16005}
RP/0/0/CPU0:PE7#

RP/0/0/CPU0:PE7#show cef 4.4.4.4/32
Wed Apr 29 14:40:18.680 UTC
4.4.4.4/32, version 91, labeled SR, internal 0x1000001 0x83 (ptr 0xa1416fa8) [1], 0x0 (0xa13f8eb8), 0xa28 (0xa173d370)
 Updated Mar  3 09:33:15.915
 local adjacency 6.7.0.6
 Prefix Len 32, traffic index 0, precedence n/a, priority 1
   via 6.7.0.6/32, GigabitEthernet0/0/0/0, 13 dependencies, weight 0, class 0 [flags 0x0]
    path-idx 0 NHID 0x0 [0xa189b4d8 0x0]
    next hop 6.7.0.6/32
    local adjacency
     local label 16004      labels imposed {16004}
RP/0/0/CPU0:PE7#

Below output shows once SR is preferred, still the router is maintaining two label data bases. Removed other output brevity purpose. 5.5.5.5/32 is having 24003 as outgoing label and 24001 as incoming label and same is installed in backup cef also.

       

RP/0/0/CPU0:PE7#show mpls forwarding
Local  Outgoing    Prefix             Outgoing     Next Hop        Bytes
Label  Label       or ID              Interface                    Switched
------ ----------- ------------------ ------------ --------------- ------------
16005  16005       SR Pfx (idx 5)     Gi0/0/0/0    6.7.0.6         0
24001  24003       5.5.5.5/32         Gi0/0/0/0    6.7.0.6         0

RP/0/0/CPU0:PE7#show cef 5.5.5.5/32 backup
Wed Apr 29 15:13:20.714 UTC
5.5.5.5/32, version 70, priority 4294967295, flags 0x0, flags2 0x83, source lsd (5), ctx-flags 0xc1
 Updated Apr 29 14:43:15.188
 Prefix Len 32
 Label count = 1, src = 5, label = 24001
   via  Gi0/0/0/0 (0x20) 6.7.0.6, weight 0, class 0 [flags 0x0]
    next hop VRF - 'default', table - 0xe0000000
    Output labels {24003}

Click Here To Read Rest Of The Post...

Segment Routing Mapping Server - Is it mandatory requirement While Deploying Segment Routing

Unified MPLS resolves legacy challenges such as scaling MPLS to support tens of thousands of end nodes, which provides the required MPLS functionality on cost-effective platforms, and the complexity of technologies like traffic engineering fast reroute (TE-FRR) to meet transport SLAs.

Large mobile service providers scales MPLS infrastructure using RFC 3107 hierarchical LSPs based architecture. The other areas PEs routes received as BGP labeled routes instead of distributing in IGP. ABR's work as inline RR with next-hop-self so that every IGP domain can reach to anywhere in the netowork by adding label of it's inline RR.

When SR will deploy along with the same network in hierarchy, question comes in mind how the prefix-SIDs of these labelled BGP routes get distributed in SR domain. Where do I place my segment routing mapping server (SRMS)?

The answer to the question is really don't need to install or create any kind of SRMS functionality in the SR domain. SRMS functionality is only required when we redistribute LDP the routes from LDP to SR domain or vice-versa. But in case of Unified MPLS, PE's loopbacks of other domains will still learn via labelled BGP on ABR's. ABR's are inline route reflectors. ABR's will distribute these labeled prefixes in SR domain.

On ingress SR PE, destination VPNv4 prefix will be learnt by vpnv4 route. The next hop of this VPNv4 prefix will be the ABR (inline RR). So ingress PE will add the VPNv4 label and SR label (prefix-SID) of ABR. Once packet will reach to SR-ABR, SR-ABR will do the stitching of SR to LDP and forward the packet by swaping it's label.

So end to end packet flow will work without installing any kind of SRMS functionality.
Click Here To Read Rest Of The Post...

SR and LDP Interworking - End To End Packet Flow of VPNv4

This post is in continuation of previous post of SR and LDP Interworking which explains how green field deployment of segment routing inter works with brownfield deployment of LDP. In this post I will be covering how VPNv4 will work in the same topology.

       
Do we really need SRMS functionality? Stay tuned for upcoming posts.

We have already setup the SR control plane in the previous post. Let's see how vpnv4 control plane will setup in case of inter working.

RR-8 is route reflector for SR and LDP domain. L3,L4 and PE7 has MP-iBGP established with RR-8.

L4 BGP Neighborship with RR-8

       

RP/0/0/CPU0:L4#show bgp vpnv4 unicast summary
BGP router identifier 4.4.4.4, local AS number 100
Neighbor        Spk    AS MsgRcvd MsgSent   TblVer  InQ OutQ  Up/Down  St/PfxRcd
8.8.8.8           0   100      71      68       18    0    0 00:43:00          2

Output of vrf test on L4

       

RP/0/0/CPU0:L4#show route vrf test
B    100.0.0.3/32 [200/0] via 3.3.3.3 (nexthop in vrf default), 00:43:19
L    100.0.0.4/32 is directly connected, 01:16:50, Loopback100
B    100.0.0.7/32 [200/0] via 7.7.7.7 (nexthop in vrf default), 00:43:19
RP/0/0/CPU0:L4#

Check the below output where 100.0.0.4/32 is advertised with local label 24000

       

RP/0/0/CPU0:L4#show bgp vpnv4 unicast vrf test 100.0.0.4/32
Thu Apr 23 07:22:22.670 UTC
BGP routing table entry for 100.0.0.4/32, Route Distinguisher: 100:100
Versions:
  Process           bRIB/RIB  SendTblVer
  Speaker                  5           5
    Local Label: 24000
Last Modified: Apr 23 06:02:51.935 for 01:19:30
Paths: (1 available, best #1)
  Advertised to peers (in unique update groups):
    8.8.8.8
  Path #1: Received by speaker 0
  Advertised to peers (in unique update groups):
    8.8.8.8
  Local
    0.0.0.0 from 0.0.0.0 (4.4.4.4)
      Origin incomplete, metric 0, localpref 100, weight 32768, valid, redistributed, best, group-best, import-candidate
      Received Path ID 0, Local Path ID 1, version 5
      Extended community: RT:100:100
RP/0/0/CPU0:L4#

Check the below output where 100.0.0.4/32 is received by PE7(LDP Domain) with received label 24000

       

RP/0/0/CPU0:PE7#show bgp vpnv4 unicast vrf test 100.0.0.4/32
Thu Apr 23 07:20:17.429 UTC
BGP routing table entry for 100.0.0.4/32, Route Distinguisher: 100:100
Versions:
  Process           bRIB/RIB  SendTblVer
  Speaker                 15          15
Last Modified: Apr 23 06:34:21.928 for 00:45:55
Paths: (1 available, best #1)
  Not advertised to any peer
  Path #1: Received by speaker 0
  Not advertised to any peer
  Local
    4.4.4.4 (metric 40) from 8.8.8.8 (4.4.4.4)
      Received Label 24000
      Origin incomplete, metric 0, localpref 100, valid, internal, best, group-best, import-candidate, imported
      Received Path ID 0, Local Path ID 1, version 15
      Extended community: RT:100:100
      Originator: 4.4.4.4, Cluster list: 8.8.8.8
      Source AFI: VPNv4 Unicast, Source VRF: test, Source Route Distinguisher: 100:100

Output of end to end vrf traceroute on PE7

       

RP/0/0/CPU0:PE7#traceroute vrf test 100.0.0.4
 1  6.7.0.6 [MPLS: Labels 24020/24000 Exp 0] 29 msec  29 msec  29 msec
 2  5.6.0.5 [MPLS: Labels 24019/24000 Exp 0] 19 msec  19 msec  19 msec
 3  2.5.0.2 [MPLS: Labels 16004/24000 Exp 0] 39 msec  19 msec  29 msec
 4  2.4.0.4 19 msec  *  19 msec

End To End Packet Flow

Click Here To Read Rest Of The Post...

SR and LDP Interworking

Segment Routing Deployment - Control and Data Plane explains how to deploy SR in service provider network. The shared example was very good in case of green field deployment. But most of the service providers or large enterprise have already deployed LDP in the network. So it makes sense to have new networks deployed with SR-MPLS and existing will run on the LDP only. In this design, the SR and LDP interworking is required.

       

Technical Deep Dive Of Segment Routing Control Plane - ISIS

Segment Routing makes use of the Segment Routing Global Block (SRGB). The use of the SRGB allows SR to co-exist with any other control plane protocol installing forwarding entries in the MPLS data plane.

LDP to SR Behavior: An SR node having LDP neighbors MUST create LDP bindings for each Prefix-SID learned in the SR domain by treating SR learned labels as if they were learned through an LDP neighbor. In addition, for each FEC, the SR node stitches the incoming LDP label to the outgoing SR label.

SR to LDP: SR to LDP interworking requires a Segment Routing Mapping Server (SRMS). Each SR capable router installs in the MPLS data plane Node-SIDs learned from the SRMS exactly like if these SIDs had been advertised by the nodes themselves. An SR node having LDP neighbors MUST stitch the incoming SR label (whose SID is advertised by the SRMS) to the outgoing LDP label.

In this post, I will be covering how to configure segment routing mapping server (SRMS) on S1 node which will announce prefix-sid for the LDP neigbors (P6-6.6.6.6/32 and PE7-7.7.7.7/32)

Currently Segment Routing Mapping Server(SRMS) is not configured and check how the control plane mapping is working in SR-LDP network. P6,PE7 and RR-P8 are LDP nodes.

[LDP to SR Path]
Below traceroute output explicitly shows that PE7 has labelled path available for L4

       
RP/0/0/CPU0:PE7#traceroute 4.4.4.4 source 7.7.7.7
 1  6.7.0.6 [MPLS: Label 24020 Exp 0] 19 msec  19 msec  19 msec
 2  5.6.0.5 [MPLS: Label 24019 Exp 0] 19 msec  19 msec  9 msec
 3  1.5.0.1 [MPLS: Label 16004 Exp 0] 9 msec  9 msec  19 msec
 4  1.4.0.4 9 msec  *  19 msec

[SR to LDP Path]
Below traceroute output explicitly shows that L4 has no SR bindings avaiable for PE7.

       
RP/0/0/CPU0:L4#traceroute sr-mpls 7.7.7.7/32 source 4.4.4.4
  0 4.4.4.4 MRU 0 [No Label]
Q 1 *
RP/0/0/CPU0:L4#

Below output shows that L4 doesn't have prefix-sid (labels) avaiable for PE7.

       
RP/0/0/CPU0:L4# show isis segment-routing label table

IS-IS lab IS Label Table
Label         Prefix/Interface
----------    ----------------
16001         1.1.1.1/32
16002         2.2.2.2/32
16003         3.3.3.3/32
16004         Loopback0
16005         5.5.5.5/32

Mapping server is required so that PE7 and P6 loopback prefixes can be installed in SRDB label table. Below are the advantages of mapping server:
1. The Segment Routing Mapping Server (SRMS) is an IGP node advertising mapping between Segment Identifiers (SID) and prefixes.
2. Distribution of mappings for locally prefixes and allows advertisement of mappings on behalf of non-SR capable routers.
3. It's Control plane only function which may be located anywhere in the IGP flooding scope.
4. One mapping server is required for each ISIS area.
Below is configuration on node S1

       
segment-routing  
 mapping-server
   prefix-sid-map
    address-family ipv4
     6.6.6.6/32 6 range 1
     7.7.7.7/32 7 range 1
    ! 
    !
 router isis 
  address-family ipv4 unicast
   segment-routing prefix-sid-map advertise-local
  !
 ! 

With the help of above configuration, we can check the SR label binding locally on S1 and being adveritsed in ISIS to L4 also.

       
RP/0/0/CPU0:S1#show isis segment-routing label table
IS-IS lab IS Label Table
Label         Prefix/Interface
----------    ----------------
16001         Loopback0
16002         2.2.2.2/32
16003         3.3.3.3/32
16004         4.4.4.4/32
16005         5.5.5.5/32
16006         6.6.6.6/32
16007         7.7.7.7/32


RP/0/0/CPU0:L4# show isis segment-routing label table
IS-IS lab IS Label Table
Label         Prefix/Interface
----------    ----------------
16001         1.1.1.1/32
16002         2.2.2.2/32
16003         3.3.3.3/32
16004         Loopback0
16005         5.5.5.5/32
16006         6.6.6.6/32
16007         7.7.7.7/32

Let's verify how traceroute works from L4 to PE7.

       
RP/0/0/CPU0:L4#traceroute sr-mpls 7.7.7.7/32 source 4.4.4.4
Tracing MPLS Label Switched Path to 7.7.7.7/32, timeout is 2 seconds
  0 2.4.0.4 MRU 1500 [Labels: 16007 Exp: 0]
L 1 2.4.0.2 MRU 1500 [Labels: 16007 Exp: 0] 40 ms
L 2 2.5.0.5 MRU 1500 [Labels: 24004 Exp: 0] 30 ms
L 3 5.6.0.6 MRU 1500 [Labels: implicit-null Exp: 0] 50 ms
! 4 6.7.0.7 30 ms

Click Here To Read Rest Of The Post...

Segment Routing Control Plane - ISIS

Segment Routing Deployment - Control and Data Plane gives fair understanding of how to deploy segment routing by using IS-IS on Cisco XR based platforms. In this post, I will be focusing how the segment routing control plane gets established by using IS-IS protocol.

Remember below mentioned points before moving ahead:

1. Every router must know what type of Data Plane capability to use like capable of processing SR-MPLS-encapsulated IPv4 packets on all interfaces or SR-MPLS-encapsulated IPv6 packets on all interfaces [SR-Capability TLV]
2. Every router must know what the SID-Index of the destination route is [Extended IP Reachability TLV]
3. Every router must know about the SRGB block to be used [SR-Capability TLV]
4. Every router must know what the SRLB (Segment Routing Local Block – Mainly Used For Adj-Sids, This is local to router and can be sent to PCE or can be used statically on headed router for Segment Routing Traffic Engineering Use Case) [SR-Capability TLV]

All the above four functions/tasks are taken care by ISIS Router-Capability TLV(242) and Extended IP Reachability TLV – (135,235)

1. Router-Capability TLV(242)
As per RFC 8667, section 3; Router Capability TLV (242) carries below mentioned different Sub-TLV. Router Capability TLV, helps to exchange the SRGB information along with type of data plane used.
a. SR-Capabilities Sub-TLV – This is type 2 sub-TLV. It contains the information of the SRGB Range, SID/Label value and capability of processing SR-MPLS-encapsulated IPv4 packets or IPv6 (Flags).

The SR-Capabilities sub-TLV has the following format:

       

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type        |     Length    |    Flags      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Range                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                SID/Label Sub-TLV (variable)                 //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Example of the advertisement of SRGB ranges by SR capable nodes(routers).
SR-Capable Node Advertises: Range: 100, SID value: 100
Receiving routers build the SRGB as follows: [100,199]. Index 0 means label 100, Index 1 means label 101, Index 99 means label 100.

b. SR-Algorithm Sub-TLV – This is type 19 sub-TLV. SR-Algorithm sub-TLV is optional. A router receiving multiple SR-Algorithm sub-TLVs from the same originator SHOULD select the first advertisement in the lowest-numbered LSP. This sub-TLV is used to calculate reachability to other nodes or to prefixes attached to the nodes. It has 2 values 0 and 1. 0 means SPF algo based on link metric and 1 means strict SPF algo based on link metric but algo 1 requires all the nodes in the path honor the SPF decision and will not bypass by any local policy.

The SR-Algorithm sub-TLV has the following format:

       

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type        |     Length    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Algorithm 1   |  Algorithm 2  | Algorithm ... |  Algorithm n  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

c. SR Local Block Sub-TLV: This is type 22 sub-TLV and it contains the range of labels reserved for local SIDs.
d. SRMS Preference Sub-TLV: This is type 24 sub-TLV. This is associated with Segment Routing Mapping Server advertisements from source. This is optional sub-TLV.

2. Extended IP Reachability TLV – (135,235)
As per RFC 8667 section 2.1, IS-IS sub-TLV is defined: the Prefix Segment Identifier (Prefix-SID) sub-TLV type 3. The Prefix-SID sub-TLV carries the Segment Routing IGP-Prefix-SID as defined in [RFC8402]. The 'Prefix-SID' MUST be unique within a given IGP domain.

The Prefix-SID sub-TLV has the following format:

       
0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type        |     Length    |     Flags     |   Algorithm   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         SID/Index/Label (variable)            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Below is the list of important flags used in Prefix-SID. Flags are nothing but a boolean value.
1. N-Flag – This is node sid or not
2. P-Flag – No-PHP flag, if it set in that case penultimate hop router will not do the PHP
3. E-Flag – No Explicit Null
4. V-Flag – Prefix SID carries absolute value
5. L-Flag – Prefix SID carries index
6. R-Flag – Re-advertisements

Click Here To Read Rest Of The Post...

Segment Routing Deployment - Control and Data Plane

Basics Of Segment Routing covers that node steers a packet through an ordered list of instructions, called segments. A segment can represent any instruction, topological or service based. The advantage of using Segment Routing (SR-MPLS) over LDP and RSVP was clearly explained in earlier post of “Segment Routing Based MPLS Vs Classic MPLS”.

This post is used to learn and practice Segment Routing concepts and configuration on Cisco IOS-XR based platform. By the end of this example, one can easily understand how to enable SR with ISIS, SRGB, SIDs and it’s advertisements.

We will be using the below topology to understand how SR can be used in the network.

In the context of an IGP-based distributed control plane, two topological segments are defined: the IGP Adjacency segment and the IGP-Prefix segment. In the context of a BGP-based distributed control plane, two topological segments are defined: the BGP peering segment and the BGP-Prefix segment.
• IGP-Adjacency Segment: an IGP-Adjacency segment is an IGP segment attached to a unidirectional adjacency or a set of unidirectional adjacencies. By default, an IGP-Adjacency segment is local (unless explicitly advertised otherwise) to the node that advertises it. Also referred to as "Adj-SID".

• IGP-Prefix Segment: an IGP-Prefix segment, also referred to as "prefix-SID", is an IGP segment representing an IGP prefix. When an IGP-Prefix segment is global within the SR IGP instance/topology, it identifies an instruction to forward the packet along the path computed using the routing algorithm specified in the algorithm field, in the topology, and in the IGP instance where it is advertised. It is advertised as an index into the node specific SR Global Block or SRGB.

• IGP-Node Segment: an IGP-Node segment is an IGP-Prefix segment that identifies a specific router (for example, a loopback). Also referred to as "Node Segment".

• SR Global Block (SRGB): the set of global segments in the SR domain (the range of labels reserved for segment routing). In SR-MPLS, SRGB is a local property of a node and identifies the set of local labels reserved for global segments. In SR-MPLS, using identical SRGBs on all nodes within the SR domain is strongly recommended. Doing so eases operations and troubleshooting as the same label represents the same global segment at each node. The SRGB default value is 16000 to 23999.

• SR Local Block (SRLB): local property of an SR node. In SR-MPLS, SRLB is a set of local labels reserved for local segments.

Enter the following commands to enable Segment Routing on Node S1, S2, L3, L4 and P5 as per above figure.

       

router isis 
address-family ipv4 unicast   
segment-routing mpls 
! 
interface Loopback0   
address-family ipv4 unicast    
prefix-sid index 
!  
segment-routing 
!

How does the SID encoding works:
Prefix SID
• Label form SR Global Block (SRGB)
• SRGB advertised within IGP via TLV
• Prefix-SID can be configured as an absolute value or an index
• In the protocol advertisement, Prefix-SID is always encoded as a globally unique index. Index represents an offset from SRGB base, zero-based numbering, i.e. 0 is 1st index E.g. index 1, SID is 16,000 + 1 = 16,001

       
Prefix-Sid index 1 means that S1 router will be having 16000+1=16001 prefix-sid. Similar way, S2 will have Prefix-Sid index 2 means S2 
router will be having 16000+2=16002 prefix-sid.

Adjacency SID - This is used for physical links
• Locally significant
• Automatically allocated by the IGP for each adjacency
• Always encoded as an absolute (i.e. not indexed) value

Below is the output on L4 node which clearly shows that every router is able to generate the SR value by using Prefix-Sid Index value

Show ipv4 interface brief

Output of Show route shows that the destination 5.5.5.5 is getting load balanced and no FRR is configured for the same.

Out of Show cef shows that destination 5.5.5.5 is using SR labeled stack.

Output of Show mpls forwarding plane - This is how the data plane is working. Isn't it like MPLS, the only difference is that under prefix-ID - SR Pfx is used.

       
Where possible, it is recommended that identical SRGBs be configured on all nodes in an SR domain.  This simplifies troubleshooting as the same 
label will be associated with the same prefix on all nodes.  In addition, it simplifies support for anycast.

Output of show mpls forwarding labels 16005 detail

Output of "Traceroute sr-mpls" shows that SR label 16005 is used for forwarding and PHP is taken care by the second last node.

Click Here To Read Rest Of The Post...

gRPC - Quick Refresher

gRPC is a high performance, open source RPC framework initially developed by Google. It helps in eliminating boilerplate code and helps in connecting multiple services in and across data centers. It’s open-source, free-to-use and available on many different development platforms.

The framework is based on a client-server model of remote procedure calls. A client application can directly call methods on a server application as if it was a local object.

gRPC embraces HTTP semantics over HTTP/2, allows for client-server and duplex streaming of data and relies on protocol buffers(protobuf) as a serialization mechanism that allows it to be efficient. It provides low-latency and highly distributed systems such as microservices due to its efficiency, we can call remote methods the same way we call normal methods.

A number of different organizations have adopted gRPC, such as Square, Netflix, CoreOS, Docker, CockroachDB, Cisco, Nokia and Juniper Network and many more for streaming network telemetry instead of using SNMP. Stay tuned for the next post covering telemetry uses cases by using gRPC in networking.


Click Here To Read Rest Of The Post...

Basics of HTTP: HTTP/1.1 and HTTP/2.0 - Required For Telemetry

Remote Procedure Calls (RPC) is not a protocol, it's a principle that is also used in SOAP. SOAP is an application protocol that uses HTTP for transport. HTTP (Hypertext Transfer Protocol) is the most popular client-server application-level protocol used in the Internet. As from RFC2616: "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, protocol which can be used for many tasks beyond its use for hypertext, such as name servers and distributed object management systems, through extension of its request methods, error codes and headers".

Being stateless, the new request doesn't know what has been sent in the previous request. It is purely based on pull model, which means server will only share that information what is being requested by client. It negotiates of data type and it's representation, so as to allow systems to be built independently of the data being transferred.

It typically runs over a TCP/IP connection and requires a reliable transport. But any transport protocols that provide such reliable delivery can be used.

There are 2 classes of HTTP Protocol. HTTP/1.0 is the initial major version of HTTP network protocol. HTTP/2 (originally names HTTP/2.0) is subsequent major version of HTTP. HTTP 1.0 was sensitive to high latency connections, as every request had to be made sequentially. If two requests made simultaneously, you had to wait until the first was completed before making the second.

HTTP 1.1 improved this, by enabling pipelining. If the user wanted to make simultaneously two requests, they could send off both requests and then receive the responses back in order. However this suffered from head-of-line blocking problem, consequences intensive or slow request completed.

HTTP/2 aims to address these issues by changing how the client and server communicate over the wire. To do this it introduces two new concepts: frames and streams:
Frames: The smallest unit of communication in HTTP/2, each containing a frame header, which at a minimum identifies the stream to which the frame belongs.
Stream: A bidirectional flow of bytes within an established connection, which may carry one or more messages.
Message: A complete sequence of frames that map to a logical request or response message.

The utmost focus of HTTP/2 is performance, especially latency as perceived by the end-user while using a browser, with a secondary focus on network and server resource usage. One large benefit of HTTP/2 is the ability to use a single TCP connection from a browser to a website as compared to multiple TCP connections in HTTP/1.1. HTTP/2 uses push model as compared to pull model used by HTTP/1.1. A single TCP connection is all that’s required because HTTP/2 leverages multiplexing and allows asynchronous (parallel) requests. Image credit goes to stackoverflow.

Excerpt from High Performance Browser Networking: HTTP/2 does not modify the application semantics of HTTP in any way. All the core concepts, such as HTTP methods, status codes, URIs, and header fields, remain in place. Instead, HTTP/2 modifies how the data is formatted (framed) and transported between the client and server, both of which manage the entire process, and hides all the complexity from our applications within the new framing layer. As a result, all existing applications can be delivered without modification.

It is important to note that HTTP/2 is extending, not replacing, the previous HTTP standards. The application semantics of HTTP are the same without having any changes in the core HTTP concept. While the high-level API remains the same, it is important to understand how the low-level changes address the performance limitations of the previous protocols. Let’s take a brief tour of the binary framing layer and its features.


Click Here To Read Rest Of The Post...

Remote Procedure Call - Starting Telemetry

Remote procedure call (RPC) architecture is popular in building salable and distributed client/server model applications. RPC allows a client to a make procedure call to a server on a different address space without understanding the network configuration as if the server was in the same network (making a local procedure call). RPC packages all have a simple goal: to make the process of executing code on a remote machine as simple and straightforward as calling a local function. Thus, to a client, a procedure call is made, and some time later, the results are returned. The server simply defines some routines that it wishes to export. The rest of the magic is handled by the RPC system, which in general has two pieces: a stub generator (sometimes called a protocol compiler), and the run-time library.

The earliest computing models utilizing Remote Procedure Calls to frame network operations dates back to early ARPANET documents in the 1970’s, with practical applications of the technology appearing in the 1980’s. The term itself was coined by Bruce Jay Nelson in 1981, and was used to describe the system, saying: "Remote procedure call is the synchronous language-level transfer of control between programs in disjoint address spaces (Local and Remote) whose primary communication medium(TCP/IP/UDP) is a narrow channel."

RPC is a protocol that allows one to relay problems in the same format regardless of whether it is being calculated locally or remotely.

Below is the list of advantages of Remote Procedure Call:
1. RPC supports process oriented and thread oriented models.
2. Internal messaging Pipeline of RPC is hidden from the user.
3. Uses more computational power.
4. Built for local as well as for distributed environment.
In the next post, I will be covering more about gRPC (google remote procedure call). So stay tuned.
Click Here To Read Rest Of The Post...