Showing posts with label MPLS. Show all posts
Showing posts with label MPLS. Show all posts

Sunday, June 14, 2020

Segment Routing - Ti-LFA - Node Protection

In the previous post we have seen how does "Segment Routing - Ti-LFA - Adjacency Sid Protection - Link Protection" works when Segment Routing is enabled. The main advantage of using Ti-LFA link protection is that primary link is excluded during post convergence backup path calculations. Ti-LFA Link protection provides 50ms resilience during the time of failure of link. There might be possibility of link failure due to node failure but XR-11 will never come to know till IGP convergence is completed.

Now node xr-11 can calculate the backup path by using TI-LFA node protection which provides protection from neighbor node failures. The neighbor node (XR-1) is excluded during the post convergence backup path calculation.



As per previous post, Ti-LFA node protection is already configured and now we will be configuring Ti-LFA node protection.
       
router isis 1
  !
 interface GigabitEthernet0/0/0/0
  point-to-point
  address-family ipv4 unicast
   fast-reroute per-prefix
   fast-reroute per-prefix ti-lfa
   fast-reroute per-prefix tiebreaker node-protecting index 100 -> Ti-LFA Node Protection With Priority 100
   metric 500
  !
!
 interface GigabitEthernet0/0/0/1
  point-to-point
  address-family ipv4 unicast
   fast-reroute per-prefix
   fast-reroute per-prefix ti-lfa
   fast-reroute per-prefix tiebreaker node-protecting index 100 -> Ti-LFA Node Protection With Priority 100
   metric 500
  !


Point To Remember
Both link-protecting and node-protecting TI-LFA backup paths will be computed. If the priority(index) associated with the node-protecting tiebreaker is higher than any other tiebreakers, then node-protecting post-convergence backup paths will be selected, if it is available.


Verify below configuration which shows that node protection post-convergence backup is selected. Now instead XR-1, XR-6 is selected. For more details on PQ Node, refer to post "Segment Routing - Topology Independent LFA"
       
RP/0/0/CPU0:xrvr-11#show isis fast-reroute 1.1.1.12/32 detail
L2 1.1.1.12/32 [1020/115] medium priority
     via 99.1.11.1, GigabitEthernet0/0/0/0, xrvr-1, SRGB Base: 16000, Weight: 0
         Backup path: TI-LFA (node), via 99.5.11.5, GigabitEthernet0/0/0/1 xrvr-5, SRGB Base: 16000, Weight: 0
           P node: xrvr-5.00 [1.1.1.5], Label: ImpNull
           Q node: xrvr-6.00 [1.1.1.6], Label: 24001
           Prefix label: 16012
       P: No, TM: 1050, LC: No, NP: Yes, D: Yes, SRLG: No
     src xrvr-12.00-00, 1.1.1.12, prefix-SID index 12, R:0 N:1 P:0 E:0 V:0 L:0
RP/0/0/CPU0:xrvr-11#


Check the routing table to verify that backpath is installed or not:
       
RP/0/0/CPU0:xrvr-11#show route 1.1.1.12/32 detail
Routing entry for 1.1.1.12/32
  Known via "isis 1", distance 115, metric 1020, labeled SR, type level-2
  Installed May 30 17:49:13.744 for 00:04:26
  Routing Descriptor Blocks
    99.1.11.1, from 1.1.1.12, via GigabitEthernet0/0/0/0, Protected
      Route metric is 1020
      Label: 0x3e8c (16012)
      Tunnel ID: None
      Binding Label: None
      Extended communities count: 0
      Path id:1       Path ref count:0
      NHID:0x6(Ref:24)
      Backup path id:65
    99.5.11.5, from 1.1.1.12, via GigabitEthernet0/0/0/1, Backup (TI-LFA)
      Repair Node(s): 1.1.1.5, 1.1.1.6
      Route metric is 1050
      Labels: 0x100004 0x5dc1 0x3e8c (1048580 24001 16012)  -> 1048580 label is used for impicit null
      Tunnel ID: None
      Binding Label: None
      Extended communities count: 0
      Path id:65              Path ref count:1
      NHID:0x5(Ref:24)
  Route version is 0x3d (61)
  Local Label: 0x3e8c (16012)
  IP Precedence: Not Set
  QoS Group ID: Not Set
  Flow-tag: Not Set
  Fwd-class: Not Set
  Route Priority: RIB_PRIORITY_NON_RECURSIVE_MEDIUM (7) SVD Type RIB_SVD_TYPE_LOCAL
  Download Priority 1, Download Version 838
  No advertising protos.
RP/0/0/CPU0:xrvr-11#


Veriy CEF table and match the labels imposed with the above mentioned labels.
       
RP/0/0/CPU0:xrvr-11#show cef 1.1.1.12/32
Sat May 30 17:54:39.252 UTC
1.1.1.12/32, version 838, labeled SR, internal 0x1000001 0x81 (ptr 0xa12fcb8c) [2], 0x0 (0xa12e1cd4), 0xa28 (0xa18b61dc)
 Updated May 30 17:49:13.764
 local adjacency 99.1.11.1
 Prefix Len 32, traffic index 0, precedence n/a, priority 1
 Extensions: context-label:16012
   via 99.1.11.1/32, GigabitEthernet0/0/0/0, 11 dependencies, weight 0, class 0, protected [flags 0x400]
    path-idx 0 bkup-idx 1 NHID 0x0 [0xa18d05d0 0xa18d00e4]
    next hop 99.1.11.1/32
     local label 16012      labels imposed {16012}
   via 99.5.11.5/32, GigabitEthernet0/0/0/1, 11 dependencies, weight 0, class 0, backup (TI-LFA) [flags 0xb00]
    path-idx 1 NHID 0x0 [0xa15fd560 0xa15fd4a8]
    next hop 99.5.11.5/32, Repair Node(s): 1.1.1.5, 1.1.1.6        -> Verify Repair Nodes. Node 1 is not coming in the path
    local adjacency
     local label 16012      labels imposed {ImplNull 24001 16012}
RP/0/0/CPU0:xrvr-11#
With maximum of 3 transport labels, we can reach to the destination. Here is the beginning of my post. And here is the rest of it.
Click Here To Read Rest Of The Post...

Saturday, May 9, 2020

SRTE - Traffic Steering By Using Adjacency-Sid

Segment Routing with traffic engineering steers the traffic without maintaining the state in the network. The state is being maintained in the packet itself which provides lot of advantages in terms of savings of network resources.

In previous post, we have seen how to steer traffic by using "Segment Routing Explicit Path", "Segment Routing On Demand Next Hop for L3VPN (ODN)" and "Deploy Network Slice By Using Flex-Algo". "Deploy Network Slice By Using Flex-Algo" also leverages the affinity links so that Flex-Algo(k) must not take the path which is having affinity-map configured.

In today's post, we will see how to steer traffic with constraints by using dynamic path. In other words, we can also say that how we can leverage adjacency-SID while we steer the traffic on headend router. Below is topology used for demonstration purpose only. Configurations will remain be the same as per the earlier post of segment routing.

As per above topology, L4 shows the best path to reach PE7 (7.7.7.7) via GigabitEthernet0/0/0/1 -> Interface towards node S2. On L4, will color GigabitEthernet0/0/0/1 with blue affnity and GigabitEthernet0/0/0/0 with red infinity. SR-TE policy is created with contraint that don't use affinity blue link which is GigabitEthernet0/0/0/1 for color 128 and destination node 7.7.7.7. By default GigabitEthernet0/0/0/1 is selected by IGP but using adjacency-sid (affinity) we can steer the traffic to GigabitEthernet0/0/0/0.

Below output is showing the best path to reach 7.7.7.7/32 (PE7)
       
RP/0/0/CPU0:L4#show route isis
i L2 1.1.1.1/32 [115/30] via 2.4.0.2, 21:45:34, GigabitEthernet0/0/0/1
i L2 1.3.0.0/24 [115/30] via 2.4.0.2, 21:45:34, GigabitEthernet0/0/0/1
i L2 1.5.0.0/24 [115/30] via 2.4.0.2, 21:45:34, GigabitEthernet0/0/0/1
i L2 2.2.2.2/32 [115/10] via 2.4.0.2, 21:45:34, GigabitEthernet0/0/0/1
i L2 2.3.0.0/24 [115/20] via 2.4.0.2, 21:45:34, GigabitEthernet0/0/0/1
i L2 2.5.0.0/24 [115/20] via 2.4.0.2, 21:45:34, GigabitEthernet0/0/0/1
i L2 3.3.3.3/32 [115/20] via 2.4.0.2, 21:45:34, GigabitEthernet0/0/0/1
i L2 3.10.0.0/24 [115/30] via 2.4.0.2, 21:45:34, GigabitEthernet0/0/0/1
i L2 3.11.0.0/24 [115/30] via 2.4.0.2, 21:45:34, GigabitEthernet0/0/0/1
i L2 5.5.5.5/32 [115/20] via 2.4.0.2, 21:45:34, GigabitEthernet0/0/0/1
i L2 5.6.0.0/24 [115/30] via 2.4.0.2, 21:45:34, GigabitEthernet0/0/0/1
i L2 5.8.0.0/24 [115/30] via 2.4.0.2, 21:45:34, GigabitEthernet0/0/0/1
i L2 6.6.6.6/32 [115/30] via 2.4.0.2, 21:45:34, GigabitEthernet0/0/0/1
i L2 6.7.0.0/24 [115/40] via 2.4.0.2, 21:45:34, GigabitEthernet0/0/0/1
i L2 6.8.0.0/24 [115/40] via 2.4.0.2, 21:45:34, GigabitEthernet0/0/0/1
i L2 7.7.7.7/32 [115/40] via 2.4.0.2, 21:45:34, GigabitEthernet0/0/0/1
i L2 7.12.0.0/24 [115/50] via 2.4.0.2, 21:45:34, GigabitEthernet0/0/0/1
i L2 7.13.0.0/24 [115/50] via 2.4.0.2, 21:45:34, GigabitEthernet0/0/0/1
i L2 8.8.8.8/32 [115/30] via 2.4.0.2, 21:45:34, GigabitEthernet0/0/0/1
RP/0/0/CPU0:L4#


Tracerute before configuring link affinity
       
RP/0/0/CPU0:L4#traceroute vrf test 100.0.0.7
 1  2.4.0.2 [MPLS: Labels 16007/24009 Exp 0] 19 msec  9 msec  29 msec
 2  2.5.0.5 [MPLS: Labels 16007/24009 Exp 0] 9 msec  9 msec  9 msec
 3  5.6.0.6 [MPLS: Labels 16007/24009 Exp 0] 9 msec  9 msec  9 msec
 4  6.7.0.7 9 msec  *  9 msec
RP/0/0/CPU0:L4#


Apply below configuration for link affinity
       
RP/0/0/CPU0:L4#sh run segment-routing
segment-routing
 traffic-eng
  interface GigabitEthernet0/0/0/0
   affinity
    name red
   !
  !
  interface GigabitEthernet0/0/0/1
   affinity
    name blue
   !
  !
  policy L4toL7
   color 128 end-point ipv4 7.7.7.7  -> candidate path instantiation whenever color is 128 and destination will 7.7.7.7 
   candidate-paths
    preference 100
     dynamic
      metric
       type igp
      !
     !
     constraints
      affinity
       exclude-any                       -> exclude blue link which GigabitEthernet0/0/0/1
        name blue
       !
      !
     !
    !
   !
  !
  affinity-map
   name red bit-position 1
   name blue bit-position 2
  !
 !
!
RP/0/0/CPU0:L4#


Check the output of SR-TE database L4:
       
RP/0/0/CPU0:L4#show segment-routing traffic-eng policy
SR-TE policy database
---------------------
Name: L4toL7 (Color: 128, End-point: 7.7.7.7)
  Status:
    Admin: up  Operational: up for 00:01:52 (since May  2 07:46:40.533)
  Candidate-paths:
    Preference 100:
      Constraints:
        Affinity:
          exclude-any:
           blue
      Path Metrics:
        Margin Absolute: 0
        Margin Relative: 0%
        Maximum SID Depth: 10
      Dynamic (active)
        Metric Type: IGP,   Path Accumulated Metric: 130
          24002 [Adjacency-SID, 1.4.0.4 - 1.4.0.1]             -> Adjacency Sid
          16007 [Prefix-SID, 7.7.7.7]                           -> Prefix-Sid
  Attributes:
    Binding SID: 24014                                          -> Binding Sid
      Allocation mode: dynamic
      State: Programmed
      Policy selected: yes
    Forward Class: 0
    Steering BGP disabled: no
    IPv6 caps enable: no
RP/0/0/CPU0:L4#


Check the below output to see adjacency-sid is allocated to Gi0/0/0/0 which is red link affinity.
       
RP/0/0/CPU0:L4#show mpls forwarding
Local  Outgoing    Prefix             Outgoing     Next Hop        Bytes
Label  Label       or ID              Interface                    Switched
------ ----------- ------------------ ------------ --------------- ------------
16001  16001       SR Pfx (idx 1)     Gi0/0/0/1    2.4.0.2         0
16002  Pop         SR Pfx (idx 2)     Gi0/0/0/1    2.4.0.2         0
16003  16003       SR Pfx (idx 3)     Gi0/0/0/1    2.4.0.2         0
16005  16005       SR Pfx (idx 5)     Gi0/0/0/1    2.4.0.2         0
16006  16006       SR Pfx (idx 6)     Gi0/0/0/1    2.4.0.2         0
16007  16007       SR Pfx (idx 7)     Gi0/0/0/1    2.4.0.2         0
17001  17001       SR Pfx (idx 1001)  Gi0/0/0/1    2.4.0.2         0
17002  Pop         SR Pfx (idx 1002)  Gi0/0/0/1    2.4.0.2         0
17003  17003       SR Pfx (idx 1003)  Gi0/0/0/1    2.4.0.2         0
17005  17005       SR Pfx (idx 1005)  Gi0/0/0/1    2.4.0.2         0
17006  17006       SR Pfx (idx 1006)  Gi0/0/0/1    2.4.0.2         0
17007  17007       SR Pfx (idx 1007)  Gi0/0/0/1    2.4.0.2         0
24000  Aggregate   test: Per-VRF Aggr[V]   \
                                      test                         14272
24001  Pop         SR Adj (idx 1)     Gi0/0/0/0    1.4.0.1         0
24002  Pop         SR Adj (idx 3)     Gi0/0/0/0    1.4.0.1         0     -> Adjacency-Sid
24003  Pop         SR Adj (idx 1)     Gi0/0/0/1    2.4.0.2         0
24004  Pop         SR Adj (idx 3)     Gi0/0/0/1    2.4.0.2         0
24009  Aggregate   test_without_odn: Per-VRF Aggr[V]   \
                                     test_without_odn             1784
RP/0/0/CPU0:L4#


Below output is showing whenever the color 128 prefix is received from PE7, BSID (24014) is attached to it.
       
RP/0/0/CPU0:L4#show bgp vpnv4 unicast vrf test 100.0.0.7
BGP routing table entry for 100.0.0.7/32, Route Distinguisher: 100:100
  Not advertised to any peer
  Local
    7.7.7.7 C:128 (bsid:24014) (metric 40) from 8.8.8.8 (7.7.7.7)
      Received Label 24009
      Origin incomplete, metric 0, localpref 100, valid, internal, best, group-best, import-candidate, imported
      Received Path ID 0, Local Path ID 1, version 78
      Extended community: Color:128 RT:100:100
      Originator: 7.7.7.7, Cluster list: 8.8.8.8
      SR policy color 128, up, not-registered, bsid 24014
      Source AFI: VPNv4 Unicast, Source VRF: test, Source Route Distinguisher: 100:100
RP/0/0/CPU0:L4#


Run traceroute to 100.0.0.7 which is vrf test and being advertised by 7.7.7.7. Below output shows that the path is changed to Gi0/0/0/0 which is red link affinity. Earlier it was going via Gi0/0/0/1. Check the above traceroute output and match it with the below one. Difference can be seen easily.
       
RP/0/0/CPU0:L4#traceroute vrf test 100.0.0.7
 1  1.4.0.1 [MPLS: Labels 16007/24009 Exp 0] 19 msec  19 msec  9 msec
 2  1.5.0.5 [MPLS: Labels 16007/24009 Exp 0] 0 msec  9 msec  9 msec
 3  5.6.0.6 [MPLS: Labels 16007/24009 Exp 0] 9 msec  9 msec  19 msec
 4  6.7.0.7 9 msec  *  9 msec
RP/0/0/CPU0:L4#

Click Here To Read Rest Of The Post...

Friday, May 8, 2020

Segment Routing Explicit Path

Segment routing for traffic engineering (SR-TE) uses a SR policy to steer traffic through the network. An SR-TE policy path is expressed as a list of segments that specifies the path, called a segment ID (SID) list. Each segment is an end-to-end path from the source to the destination and instructs the routers in the network to follow the specified path instead of following the shortest path calculated by the IGP. If a packet is steered into an SR-TE policy, the SID list is pushed on the packet by the head-end. The rest of the network executes the instructions embedded in the SID list. An SR-TE policy is identified as an ordered list (head-end, color, end-point):

1. Head-end - L3: Where the SR-TE policy is instantiated
2. Color - 128 and 129: A numerical value that distinguishes between two or more policies to the same node pairs (Headend – End point)
3. End-point - PE7: The destination of the SR-TE policy.

By the end of the post, we will understand how two different services originating from same PE router can have different path. The paths are created on the basis of the offered SLA.

The basic configuration is used as the same as in the earlier post of Segment Routing On Demand Next Hop for L3VPN (ODN). Below topology is used for reference purpose.



On PE7 we have created two vrf, vrf test and vrf test_without_odn. 100.0.0.7/32 is part of vrf test and 111.0.0.7 is part of vrf test_without_odn. Both are VPNv4 routes. Color 128 is set for 100.0.0.7 and color 129 is set for 111.0.0.7. In this post, we will be creating two explicit SR path policies and instantiate it to same end point which is PE7 but both VPNv4 service prefixes will be having different treatment. This all will be programmed on headend node which is L3.



Below is the output of node L3 beefore explicit path being implemented. The below traceroute is based on the path selected by IGP.
       
RP/0/0/CPU0:L3#traceroute sr-mpls 7.7.7.7/32. From L3, prefix-sid is used to reach PE7.
  0 2.3.0.3 MRU 1500 [Labels: 16007 Exp: 0]
L 1 2.3.0.2 MRU 1500 [Labels: 16007 Exp: 0] 10 ms
L 2 2.5.0.5 MRU 1500 [Labels: 16007 Exp: 0] 0 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:L3#


Under Segment Routing Traffic Engineering, we have created a explicit segment list 142567 which is having the loopback address or node address of each node. By default IGP selects L3-S1-P5-P6-PE7 path but the below explicit segment-list defines L3-S1-L4-S2-P5-P6-PE7 path. This path can be defined by using prefix-sid also. For same destination, one more explicit path is created PATH_TEST_COLOR_129 which is having only SIDs and path is different. So based on offered services, paths can be defined.
       
segment-routing
 traffic-eng
  segment-list 142567
   index 10 address ipv4 1.1.1.1       -> Using Loopback IP address of Nodes
   index 20 address ipv4 4.4.4.4
   index 30 address ipv4 2.2.2.2
   index 40 address ipv4 5.5.5.5
   index 50 address ipv4 6.6.6.6
   index 60 address ipv4 7.7.7.7
  !
  segment-list PATH_TEST_COLOR_129     
   index 10 mpls label 16004  -> Using prefix-sid value of Nodes
   index 20 mpls label 16007
  !
  policy 3-to-7
   color 128 end-point ipv4 7.7.7.7    -> Whenever L3 receives route with end-point 7.7.7.7 with color 128, it used segmen-list 142567
   candidate-paths
    preference 100
     explicit segment-list 142567
    !
    !
   !
  !
  policy L3toL7_Color129
   color 129 end-point ipv4 7.7.7.7
   candidate-paths
    preference 100
     explicit segment-list PATH_TEST_COLOR_129  -> Whenever L3 receives route with end-point 7.7.7.7 with color 129, it used segment-list 142567
     !
RP/0/0/CPU0:L3#


Check the output on L3 and confirms that 100.0.0.7 and 111.0.0.7 are receiving with C:128 adn C:129.
       
RP/0/0/CPU0:L3#show bgp vpnv4 unicast
   Network            Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 100:100 (default for vrf test)
*> 100.0.0.3/32       0.0.0.0                  0         32768 ?
*>i100.0.0.4/32       4.4.4.4                  0    100      0 ?
*>i100.0.0.7/32       7.7.7.7 C:128            0    100      0 ?
Route Distinguisher: 111:111 (default for vrf test_without_odn)
*> 111.0.0.3/32       0.0.0.0                  0         32768 ?
*>i111.0.0.4/32       4.4.4.4                  0    100      0 ?
*>i111.0.0.7/32       7.7.7.7 C:129            0    100      0 ?
RP/0/0/CPU0:L3#


Check the VPNv4 labels for 100.0.0.7(24009) and 111.0.0.7 (24023) on PE7. We will be reciving the same labels on L3 as Rcvd labels.
       
RP/0/0/CPU0:PE7#show bgp vpnv4 unicast labels
   Network            Next Hop        Rcvd Label      Local Label
Route Distinguisher: 100:100 (default for vrf test)
*>i100.0.0.3/32       3.3.3.3         24000           nolabel
*>i100.0.0.4/32       4.4.4.4         24000           nolabel
*> 100.0.0.7/32       0.0.0.0         nolabel         24009
Route Distinguisher: 111:111 (default for vrf test_without_odn)
*>i111.0.0.4/32       4.4.4.4         24009           nolabel
*> 111.0.0.7/32       0.0.0.0         nolabel         24023


Below output shows the SR-TE policies are attached to both colors destined to same end point:7.7.7.7
       
RP/0/0/CPU0:L3#show segment-routing traffic-eng policy
SR-TE policy database
---------------------
Name: 3-to-7 (Color: 128, End-point: 7.7.7.7)      -> Color 128
  Status:
    Admin: up  Operational: up for 00:59:27 
  Candidate-paths:
    Preference 100:
      Path Metrics:
        Margin Absolute: 0
        Margin Relative: 0%
        Maximum SID Depth: 10
      Explicit: segment-list 142567 (active)
        Weight: 1, Metric Type: TE
          16001 [Prefix-SID, 1.1.1.1]
          16004 [Prefix-SID, 4.4.4.4]
          16002 [Prefix-SID, 2.2.2.2]
          16005 [Prefix-SID, 5.5.5.5]
          16006 [Prefix-SID, 6.6.6.6]
          16007 [Prefix-SID, 7.7.7.7]
  Attributes:
    Binding SID: 24006                         -> Local Binding SID is used
      Allocation mode: dynamic
      State: Programmed
      Policy selected: yes
    Forward Class: 0
    Steering BGP disabled: no
    IPv6 caps enable: no

Name: L3toL7_Color129 (Color: 129, End-point: 7.7.7.7)        -> Color 129
  Status:
    Admin: up  Operational: up for 00:02:55        
  Candidate-paths:
    Preference 100:
      Path Metrics:
        Margin Absolute: 0
        Margin Relative: 0%
        Maximum SID Depth: 10
      Explicit: segment-list PATH_TEST_COLOR_129 (active)
        Weight: 1, Metric Type: TE
          16004 [Prefix-SID, 4.4.4.4]
          16007
  Attributes:
    Binding SID: 24009                          -> Local Binding SID is used
      Allocation mode: dynamic
      State: Programmed
      Policy selected: yes
    Forward Class: 0
    Steering BGP disabled: no
    IPv6 caps enable: no
RP/0/0/CPU0:L3#
Below is the output of MPLS forwarding table.
       
RP/0/0/CPU0:L3#show mpls forwarding
Local  Outgoing    Prefix             Outgoing     Next Hop        Bytes
Label  Label       or ID              Interface                    Switched
------ ----------- ------------------ ------------ --------------- ------------
24000  Aggregate   test: Per-VRF Aggr[V]   \
                                      test                         8880
24006  Pop         No ID              3-to-7       point2point     0    ->In the FIB, SR-TE is attached to vrf and showing local Binding SID value of 24006
24007  Aggregate   test_without_odn: Per-VRF Aggr[V]   \
                                      test_without_odn             2852
24009  Pop         No ID              L3toL7_Color point2point     0    ->In the FIB, SR-TE is attached to vrf and showing local binding SID value of 24006
RP/0/0/CPU0:L3#


Let's do the tracerout of vrf test 100.0.0.7 and see what type of path it is taking.
       
RP/0/0/CPU0:L3#traceroute vrf test 100.0.0.7
 1  1.3.0.1 [MPLS: Labels 16004/16002/16005/16006/16007/24009 Exp 0] 19 msec  29 msec  9 msec
 2  1.4.0.4 [MPLS: Labels 16002/16005/16006/16007/24009 Exp 0] 19 msec  9 msec  19 msec
 3  2.4.0.2 [MPLS: Labels 16005/16006/16007/24009 Exp 0] 9 msec  9 msec  9 msec
 4  2.5.0.5 [MPLS: Labels 16006/16007/24009 Exp 0] 9 msec  9 msec  9 msec
 5  5.6.0.6 [MPLS: Labels 16007/24009 Exp 0] 9 msec  9 msec  9 msec
 6  6.7.0.7 9 msec  *  9 msec
RP/0/0/CPU0:L3#


Let's do the tracerout of vrf test_without_odn 111.0.0.7 and see what type of path it is taking.
       
RP/0/0/CPU0:L3#traceroute vrf test_without_odn 111.0.0.7
 1  2.3.0.2 [MPLS: Labels 16004/16007/24023 Exp 0] 19 msec  19 msec  9 msec
 2  2.4.0.4 [MPLS: Labels 16007/24023 Exp 0] 19 msec  9 msec  9 msec
 3  2.4.0.2 [MPLS: Labels 16007/24023 Exp 0] 19 msec  19 msec  9 msec
 4  2.5.0.5 [MPLS: Labels 16007/24023 Exp 0] 9 msec  9 msec  9 msec
 5  5.6.0.6 [MPLS: Labels 16007/24023 Exp 0] 9 msec  9 msec  9 msec
 6  6.7.0.7 9 msec  *  39 msec
RP/0/0/CPU0:L3#


Above both traceroutes shows that for single PE, we have two different paths and both the paths are mapped to different services. So with the help of SR-TE we can create service aware paths which can be mapped to the network as per the offered SLA.

Click Here To Read Rest Of The Post...

Wednesday, May 6, 2020

Segment Routing On Demand Next Hop for L3VPN (ODN)

Segment routing for traffic engineering (SR-TE) uses a SR policy to steer traffic through the network. An SR-TE policy path is expressed as a list of segments that specifies the path, called a segment ID (SID) list or it can be defined as next hop prefix-sid too. Each segment is an end-to-end path from the source to the destination and implemented on headend node only. SR-TE policy instructs the headend routers to program the specified path instead of following the path calculated by the IGP. If packet is steered into an SR-TE policy, the SID list is pushed on the packet by the head-end and rest of the network executes it.

Let's understand how ODN works?
Segment Routing On-Demand Next Hop (SR-ODN) allows a service head-end router to automatically instantiate an SR policy to a BGP next-hop when required. SR-ODN works by encoding the intent as a BGP color extended community at the egress PE (PE who is advertising routes); the ingress PE(receiver or headend) is pre-configured with an ODN template that provides the node with the steps to follow in case a route with the intended color appears.

SR-ODN automates the instantiation of SR-TE policy without the need of SDN controller as the template has to be locally configured on headend router. If you are having SDN controller installed, in that case PCEP can be leverage for the dynamic instantiation of SR-ODN. In our topology, as soon as L4 received VPNv4 color route from PE7; L4 automattically instantiate locally configured ODN template on L4. Now the selected candidate path will be ODN instantiated path.

Another concept is of Binding SID which may be defined by candidate path. Binidng SID is also known as BSID also. The Binding SID (BSID) is fundamental to Segment Routing and provides scaling, network opacity and service independence. (Excerpt from Segment Routing Policy for Traffic Engineering). BSID can be locally configured on router with SID-Lists attached to it or headend node can allocate BSID locally from the SRGB block too. A valid SR Policy installs a BSID entry in the forwarding plane with the action of steering the packets matching this entry to the selected path of the SR Policy.

Traffic Steering into an SR Policy A headend can steer a packet flow into a valid SR Policy in various ways: o Incoming packets have an active SID matching a local BSID at the head-end. o Per-destination Steering: incoming packets match a BGP/Service route which recurses on an SR policy. [We will be testing this scenario) o Per-flow Steering: incoming packets match or recurse on a forwarding array of where some of the entries are SR Policies. o Policy-based Steering: incoming packets match a routing policy which directs them on an SR policy. For demo purpose, we will be using the below topology. Network slicing is already configured as per the earlier post "Deploy Network Slice By Using Flex-Algo". Now the next step is to color the VRF test VPNv4 prefix on router from PE7. On PE4, create ODN template, match color and steer the traffic into ODN instantiated candidate path.

Look at the output of vrf test, this is vpnv4 prefixes received by L3 and PE7.
       
RP/0/0/CPU0:L4#show bgp vpnv4 unicast vrf test
   Network            Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 100:100 (default for vrf test)
*>i100.0.0.3/32       3.3.3.3                  0    100      0 ?
*> 100.0.0.4/32       0.0.0.0                  0         32768 ?
*>i100.0.0.7/32       7.7.7.7                  0    100      0 ?

M/br>Configure PE7 with below given configuration. vrf TEST (100.0.0.7 router) is exporting color128 to RR and RR is further sending the same to the respective PEs.
       
vrf test
  address-family ipv4 unicast
   export route-policy SET_COLOR_128
  !
 !
 !
 extcommunity-set opaque color128 128 end-set
 !
 route-policy SET_COLOR_128
   set extcommunity color color128
   pass end-policy
 !


Now check whether we are receiving color128 as extended community on L4 node by issuing the following command. Few points to check, extended community with 100:100 ; Color:128 is also added. Received label is 24009.
       
RP/0/0/CPU0:L4#show bgp vpnv4 unicast vrf test 100.0.0.7/32
BGP routing table entry for 100.0.0.7/32, Route Distinguisher: 100:100
  Local
    7.7.7.7 (metric 40) from 8.8.8.8 (7.7.7.7)
      Received Label 24009
      Origin incomplete, metric 0, localpref 100, valid, internal, best, group-best, import-candidate, imported
      Received Path ID 0, Local Path ID 1, version 36
      Extended community: Color:128 RT:100:100
      Originator: 7.7.7.7, Cluster list: 8.8.8.8
      Source AFI: VPNv4 Unicast, Source VRF: test, Source Route Distinguisher: 100:100
RP/0/0/CPU0:L4#


RP/0/0/CPU0:L4#show bgp vpnv4 unicast vrf test (Check that 100.0.0.7 is receiving with C:128)
Origin codes: i - IGP, e - EGP, ? - incomplete
   Network            Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 100:100 (default for vrf test)
*>i100.0.0.3/32       3.3.3.3                  0    100      0 ?
*> 100.0.0.4/32       0.0.0.0                  0         32768 ?
*>i100.0.0.7/32       7.7.7.7 C:128            0    100      0 ?


Below is the CEF output of vrf test 100.0.0.7/32, which shows that 24009 is vpnv4 label and 16007 is prefix-sid label of PE7. Remember the prefix-sid label as this will change once we apply ODN and it will use underneath flex-algo(128) as network slice which we created in earlier post.
       
RP/0/0/CPU0:L4#show cef vrf test 100.0.0.7/32
100.0.0.7/32, version 24, internal 0x5000001 0x0 (ptr 0xa14165d0) [1], 0x0 (0x0), 0x208 (0xa1757268)
 Updated May  1 09:52:29.665
 Prefix Len 32, traffic index 0, precedence n/a, priority 3
   via 7.7.7.7/32, 3 dependencies, recursive [flags 0x6000]
    path-idx 0 NHID 0x0 [0xa17cc058 0x0]
    recursion-via-/32
    next hop VRF - 'default', table - 0xe0000000
    next hop 7.7.7.7/32 via 16007/0/21
     next hop 2.4.0.2/32 Gi0/0/0/1    labels imposed {16007 24009}
RP/0/0/CPU0:L4#


Apply the following configuration on L4 to enable ODN. SR-TE On Demand Next-Hop (ODN) feature can be used to steer the BGP traffic towards the Flexible Algorithm paths - Flex-Algo(128).
       
segment-routing
  traffic-eng
   on-demand color 128
    dynamic
     sid-algorithm 128


After applying above mentioned ODN configuration, we check the output how does ODN template behaves when receives route with color 128. SR policy color 128 can be seen on the last output. It also shows one important thing which is bsid: binding sid 24008. VPNv4 label is 24009.
       
RP/0/0/CPU0:L4#show bgp vpnv4 unicast vrf test 100.0.0.7/32
BGP routing table entry for 100.0.0.7/32, Route Distinguisher: 100:100
Versions:
  Process           bRIB/RIB  SendTblVer
  Speaker                 57          57
Last Modified: May  1 10:14:32.836 for 00:00:46
Paths: (1 available, best #1)
  Not advertised to any peer
  Path #1: Received by speaker 0
  Not advertised to any peer
  Local
    7.7.7.7 C:128 (bsid:24008) (metric 40) from 8.8.8.8 (7.7.7.7)
      Received Label 24009
      Origin incomplete, metric 0, localpref 100, valid, internal, best, group-best, import-candidate, imported
      Received Path ID 0, Local Path ID 1, version 54
      Extended community: Color:128 RT:100:100
      Originator: 7.7.7.7, Cluster list: 8.8.8.8
      SR policy color 128, up, registered, bsid 24008, if-handle 0x000000b0
RP/0/0/CPU0:L4#


Below output shows that BSID 24008 is having prefix SID which is 17007 and 17007 is apped to Flex Algo 128. So for traffic destined to 100.0.0.7 will follow the flex algo(128) path. Remeber from the above output before applying ODN, it was prefix sid of node which was 16007 but after ODN SRTE policy instantiation it changes to flex-algo(128) prefix sid which is 17007.
       
RP/0/0/CPU0:L4#show segment-routing traffic-eng policy name bgp_AP_2
SR-TE policy database
---------------------
Name: bgp_AP_2 (Color: 128, End-point: 7.7.7.7) (bgp_AP_2 is dynamically created)
    Status:
      Admin: up  Operational: up for 00:09:27 (since May  1 10:14:33.304)
    Candidate-paths:
      Preference 100:
        Constraints:
         Prefix-SID Algorithm: 128
        Path Metrics:
          Margin Absolute: 0
          Margin Relative: 0%
          Maximum SID Depth: 10
        Dynamic (active)
            17007 [Prefix-SID: 7.7.7.7, Algorithm: 128]
    Attributes:
      Binding SID: 24008
        Allocation mode: dynamic
        State: Programmed
        Policy selected: yes
      Forward Class: 0
      Steering BGP disabled: no
      IPv6 caps enable: yes
      Distinguisher: 0
    Auto-policy info:
      Creator: BGP
RP/0/0/CPU0:L4#


Output of vrf test 100.0.0.7 which shows that it is taking flex-algo (128) created path.
       
RP/0/0/CPU0:L4#traceroute vrf test 100.0.0.7
Tracing the route to 100.0.0.7
 1  2.4.0.2 [MPLS: Labels 17007/24009 Exp 0] 9 msec  9 msec  9 msec
 2  2.5.0.5 [MPLS: Labels 17007/24009 Exp 0] 9 msec  9 msec  9 msec
 3  5.6.0.6 [MPLS: Labels 17007/24009 Exp 0] 9 msec  9 msec  9 msec
 4  6.7.0.7 9 msec  *  9 msec


For testing purpose I have created another vrf named test_without_odn on L3, L4 and PE7. PE7 is advertising another VPNv4 router 111.0.0.7 with no color attached to it for test_without_odn 111.0.0.7. Now PE7 has two vrfs one is advertising routes with color and another is advertising routes without color. For vrf test ODN will be instantiated and flex-algo(128) will be considered but for non color routes it will follow the standard path.
       
RP/0/0/CPU0:L4#traceroute vrf test_without_odn 111.0.0.7
Tracing the route to 111.0.0.7
 1  2.4.0.2 [MPLS: Labels 16007/24023 Exp 0] 9 msec  9 msec  9 msec
 2  2.5.0.5 [MPLS: Labels 16007/24023 Exp 0] 9 msec  0 msec  9 msec
 3  5.6.0.6 [MPLS: Labels 16007/24023 Exp 0] 9 msec  9 msec  9 msec
 4  6.7.0.7 0 msec  *  9 msec
References

Click Here To Read Rest Of The Post...

Tuesday, May 5, 2020

Segment Routing Policy For Traffic Engineering


Segment Routing policy is used when Automatic Traffic Steering is required. Doesn't matter that traffic steering in specific network slice or based on some constraints. Below is the excerpt from Segment Routing Policy for Traffic Engineering IETF draft.
Segment Routing Policy: Segment Routing (SR) allows a headend node to steer a packet flow along any path. The headend node steers a flow into an Segment Routing Policy aka SR Policy.

How to Identify SR Policy: An SR Policy is identified through the tuple . The headend is the node where the policy is instantiated/implemented. The headend is specified as an IPv4 or IPv6 address.

What is Candidate Path: An SR Policy is associated with one or more candidate paths. A candidate path can either be explicit or dynamic.

What is explicit path: An explicit candidate path is associated with a SID-List or a set of SID-Lists or loopback addresses of nodes also.

What is dynamic path: A dynamic candidate path expresses an optimization objective and a set of constraints. The headend with PCE computes the solution SID-List that solves the optimization problem.

How and when candidate path becomes valid and invalid?
Explicit Path:
A SID-List of an explicit candidate path MUST be declared invalid when:
a. It is empty.
b. Its weight is 0.
c. The headend is unable to resolve the first SID into one or more outgoing interface(s) and next-hop(s).
d. The headend is unable to resolve any non-first SID of type 3-to-11 into an MPLS label or an SRv6 SID. (Type3-11 will be covering in my upcoming post)

Dynamic Path:
The headend of the policy leverages its SRTE-DB to compute a SID-List that solves this optimization problem. When local computation is not possible or not desired, the head-end MAY send path computation request to a PCE supporting PCEP. If no solution is found to the optimization objective and constraints, then the dynamic candidate path is declared invalid.


Click Here To Read Rest Of The Post...

Wednesday, April 29, 2020

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

Monday, April 27, 2020

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

Sunday, April 26, 2020

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

Friday, April 24, 2020

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

Wednesday, April 22, 2020

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

Tuesday, April 21, 2020

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