Segment Routing

Anycast-SID in Segment Routing

Anycast-SID | This article explains Anycast-SID and its usage in the context of Segment routing. Anycast-SID in Segment Routing plays a vital role in achieving node resiliency , traffic load-sharing or even to create separate network planes for different types . Recommend to read few basic articles here , what is segment routing and how segment routing works .

Anycast-SID is a Node Prefix-SID that is advertised by more than one node (typically two ). The set of nodes advertising the same anycast-SID form a group called as anycast set. Using an Anycast-SID in the SID list of an SR policy path provides improved traffic load-sharing and resiliency. Few of the benefits of using  Anycast-SID are,

  1. ECMP – Anycast-SID provides traffic load sharing across nodes
  2. High-Availability (HA) – Usage of Anycast-SID provides high availability in case of node failure
  3. Traffic engineering based on specific region or a set of nodes – Anycast-SID is useful when not specific SRTE path is required through the network, path is required through only set of nodes or region, in that case all nodes in that region are assigned same Node Prefix-SID to serve as Anycast-SID to provide load sharing and HA.

Anycast-SID IGP (or BGP) provides shortest path to the nearest node in the anycast set. If two or more nodes are at the same distance (means having same metric) then the flows are load-balanced among the nodes. Lets understand the concept with example, refer figure below for illustration purpose,  

Anycast-SID in Segment Routing
Figure 1 Anycast-SID

Above topology is shown with two domains connected with two border nodes. Anycast-SID 16820 is assigned to border nodes S4 and S5. This is done by configuring same loopback address and same Node prefix-SID  to both the nodes. Now, SR policy is required to reach Endpoint S8 on headend node S1 for a path between S1 and S8. SID-list is consists of (16820,20220). Anycast-SID 16820 load-balance the traffic from Node S1 to Node S4 and S5. By using Anycast-SID on border nodes instead of individual Prefix-SID , the available paths in the network are better utilized using ECMP.

Usage of Anycast-SID provides node resiliency as well , upon failure of node S4, traffic to Anycast-SID is forwarded through remaining Node S5 without changing the SID-list on headend Node S1. Same is true if Node S5 fails and traffic is forwarded through Node S4.

Hence, Anycast-SID provides load-balancing and node resiliency in the SR network. Usage and benefits of Anycast-cast can be applied to use-cases such as disjoint paths and Flex-algo which we will see in the subsequent articles. I hope this article is helpful in understanding Anycast-SID concept. Also, if you want to be expert on Segment Routing , you can buy these highly recommended books , segment routing part-1 and segment routing part-II

Advertisements

SR and LDP Interworking

SR and LDP Interworking | In this article we will discuss how SR based network can interwork with existing LDP based network. LDP and SR based networks will co-exist for sometime . Suggest to to have basic understanding of Segment Routing to fully grasp this article, if you want to read basics of SR, visit here (Why segment Routing)

Generation old networks are operated using LDP based MPLS and it is not possible to migrate to Segment Routing based network over-night or some part of the network may not support SR due to hardware or software limitations. For that reason , existing LDP and SR will co-exist for some time and there has to be interworking with each other. SR and LDP interworking helps in migration process.

Seamless interworking between LDP and SR is achieved by Mapping server functionality. Mapping server basically map LDP label to Prefix SID and sits at the border of two networks.

Lets understand LDP-SR interworking with example . Refer figure 1 below,

LDP-SR-Interworking
Figure 1. LDP and SR Interworking

Nodes on left side are LDP enabled nodes and on right side are SR enabled nodes. Node S3  on the border of two networks is enabled for both LDP and SR and acts as mapping server. Node N1,N2 and N3 are LDP nodes so they use dynamic label range above 24000 and nodes S1 and S2 are SR nodes so they use SRGB range for prefix segment id (SID) . Node S3 is enabled for both LDP and SR so it uses both. Lets see how LDP Node N1 can reach SR enabled node S1 over label switched path.Here are the steps how forwarding entries are stitches to have end-to-end LSP ,

Step 1 – Node S1 advertise its Prefix SID 16302 for its loopback address , node S2 and  S3 installs the forwarding entry for prefix SID 16302 to Node S1.

Step 2 – LDP on Node S3 dynamically allocates label 90001 for the loopback address of node S1 and advertise this binding information to its LDP neighbours. So , border Node S3 (mapping server ) keeps mapping between LDP label and Prefix SID for the loopback address of node S1.

Step 3 – LDP on Node N3 install local label 90010 with out going label 90001 . Similarly, all other nodes install LDP local label and out going label for the loopback prefix address of Node S1.

Step 4 – Node S3 automatically connects LDP LSP to the prefix segment to reach Node S1 and provides seamless label switch path from node N1 to node S1. This functionality is called mapping server functionality.

Interworking applies to only labeled packets . For unlabeled IP packets with destination to Node S1 above, node S3 imposes prefix SID 16302.

In Summary, interworking is automatic and seamless and no specific configuration is required except mapping server functionality. This is the easiest way that LDP and SR based networks can not only co-exist but also communicate with each other to provide end-to-end LSP path. I hope this article is useful in understanding LDP/SR interworking concept.

Advertisements

Flex-algo and On-demand Next-hop/Automated Steering together

Flex-algo and ODN/Automated Steering | In this topic, we will bring all SR-TE ingredients together like Flex-algo, On-demand Next-hop and Automated Steering.

 

Till now in my earlier articles , we have discussed Flex-algo , ODN and Automated Steering and their usage  in SR traffic engineering . Please refer to below links for those detailed articles,

Flex-algo
On-demand Next-hop
Automated-Steering
SR Policy

Now, we will see how ODN and Automated steering leverages Flex-algo. As a reminder, ODN enables automatic instantiation of SR Policy path when service routes are received from egress node via BGP (VPN routes). Automated Steering steers service routes into the SR policy . SR policy is identified by color of the service route and Next-hop. There is no change in their functionalities  while leveraging Flex-algo to encode SR-TE path.

The way it is done , Flex-algo SID algorithm is mapped to color which expresses the SLA constraint in the ODN template. For example, low-delay SLA constraint which is identified by color 100 and Flex-algo 130 is defined to provide low-delay path. So, SR Policy color is mapped to Flex-algo in the ODN template configured on Headend node. Below is the sample config for that, (using Cisco CLI commands for illustration purpose only).

 

 

Mapping Color with Flex-algo in ODN template example

Now, will use sample topology as given below for further illustration,

Figure 1
 

Suppose there is requirement of L3VPN from Node S1 to Node S4 with SR-TE ODN and SLA optimization of low-delay path.When VPN routes are received on headend node S1 with BGP nexthop as S4 with color 100 , ODN functionality instantiates SR Policy 1 to Node S4  based on the ODN template for color 100.ODN template restricts SR Policy to use Flex-algo SID as described earlier on how SR policy color is mapped with Flex-algo . SID list consists of just single SID , that is, Flex-algo prefix-SID 16304 correspond to Flex-algo 130 of Node S4 as shown .

BGP on Node S1 uses Automated Steering to steer the VPN routes into ODN based SR Policy which is identified by color 100. This is how ODN, Automated steering in SR-TE leverages Flex-algo to fulfil SLA optimization requirements.

Flex-algo is integral part of SR-TE architecture , Flex-algo SIDs are considered for SR-TE path calculation and can be included while creating SR policy.

I hope you will like this articles, please don’t hesitate to write comment below for any clarification or question you may have.

Advertisements

%d bloggers like this: