Sunday, May 31, 2020

Segment Routing - Topology Independent LFA

Combination of segment routing and Loop Free Alternate is known as Topology Independent LFA or Ti-LFA. The main reason for configuring LFA is to provide the protection against the destination prefixes. In case of failure of primary link, source node calculates the backup the path as described in the "Loop Free Alternate: IP Fast Reroute (FRR)". The biggest disadvantage of the existing RSVP-TE-Fast reroute, Loop Free Alternate (LFA) and remote LFA, which has seen wide adoption can't guarantee 100% coverage for all failure scenarios. As per the RFC 6571, section 4.3, simulation results proves that LFA provides average 89% coverage across various topologies.

Below are the various types of issues which can be seen with Loop Free Alternate(LFA) and Remote Loop Free Alternate(rLFA)

1. LFA has issue with topology more than 3 nodes. With 3 nodes topology it perfectly works good. If the topology has more than 3 nodes, micro loop can occur as per shown in the image.
2. Micro-Loop avoidance can be taken care by finding PQ node as per RFC 7490. XR-1 will create T-LDP session with XR-3, XR-3 has the best path to XR-5 via XR-4.
3. Now increase the metric to 100 between XR-3 and XR-4. In this case, if XR-1 creates T-LDP session XR-3, XR-3 will again finds XR-1 as best and forward the traffic back to XR-3. This will be same as of micro loop.
Implementing Segment Routing with Topology Independent LFA (TI-LFA) provides 100% loop-free guaranteed coverage against any link, SRLG and node failure. Ti-LFA protects both labelled as well as unlabelled traffic. Stay tuned for the upcoming post how Ti-LFA solves the above issues by leveraging Segment Routing.

Click Here To Read Rest Of The Post...

Sunday, May 24, 2020

What is data model - Yang ?

Data model provides the definition of any "anything" which can be easily understood and agreed upon. Using the generic data model, you can describe an individual in a way that is easy for others to understand.

Whatever the communication is done by using the API's are actually encoding in some data format and most of them uses the data model underneath. This is what we will be discussing in this post. Let's see how this can be understood by creating data model of car:
       
Module CAR
OEM: Ford, Volkswagen, Maruti
Engine: Diesel, Pertol
Color: Blue, Green,Black
Type: Sedan, Hatchback


Which language is used to define data models?
YANG is not name of any person but YANG (Yet Another Next Generation) is a data modelling language uses YANG language to write YANG models, providing a standardized way to model the operational and configuration data of a network device. YANG, being a language protocol independent, can then be converted into any data format encoding like XML or JSON. YANG is a language for describing any type of data models. But it was originally designed for networking data models. Below are good aspects of YANG to remember:
       
It is a very structured language
Every data model is a module
Containers are used to group related type of nodes.
Lists (It's same programming list) is used to identify nodes that are stored in sequence. 
Data types can be imported from another YANG module or defined within a module.
Each individual attribute of a node is represented by a leaf.


Where do these YANG models come from? Who writes these data models? Anyone having knowledge of YANG programming can easily write a YANG model. These data models mainly categorized into as open models and native models.
       
Open Models:  Designed to be platform and OEM independent models. These are mainly written by standard bodies like IETF and Open Config
Native Models: These models are mainly written by OEM and specific to platform or operating system. 


Open and Native data models can further classified into two different data models:
Device Data Models: Interfaces, Vlans, OSPF, ACL
Service Data Models: layer 3 vpn, layer 2 vpn, 


YANG model is made up from various components as shown in the image (Image copied from Cisco Live Dev Net Presentation)
       



Container - Infomration is logically grouped into form of containers. Such container is for configuration and one for state. List - Container contains list or even multiple lists. Such as a list of interfaces. Key - Each item within the list is references via a key (unique key). Leaf - Inside list we have leaf's. It contains information. Data Type - Each leaf is associated with a data type.

Click Here To Read Rest Of The Post...

Friday, May 22, 2020

What is Application Programming Interface?


As per wiki, "An application programming interface (API) is a computing interface which defines interactions between multiple software intermediaries. It defines the kinds of calls or requests that can be made, how to make them, the data formats that should be used, the conventions to follow, etc."

I also like one more definition from Kin Lane API 101 guide, "API allows your product or service to talk to other products or services".

APIs can work with any programming language, with the most popular approach to delivering web APIs being REST, or Representational State Transfer. REST is an API framework built on the top of HTTP protocol.By using REST API, request sent to the server and JSON and XML is received as response.

For network engineers, all need to understand that client(web app) will request the data in some data format from server. Server will send the response in particular data format to application.



Before moving ahead, need to understand the URI syntax as most of API calls will be in the given as per below format
       
Host:
IP address, Web Address and Port Numbers

Resource:
Location of Interested Data On Server

Parameters:
What need to be fetched  



Below are the different type of HTTP requests which can be sent to server:
       
FunctionPurposeRemarks
PostCreate RequestCreate New Object
GetRead RequestRead The Existing Object Or Fetch Existing Resources Details
PutUpdate RequestUpdate the Existing Resources
DeleteDelete RequestDelete Existing Resources


Once request is sent, we have to wait for the response. Response can have below mentioned codes which can be used to understand in case of successful response or unsuccessful response.
       
Status CodePurpose
200Create Request
201OK
400Created
401Unauthorised
403Forbidden
404Not Found
500Internal Server Error
503Service Unavailable


Let's get our hands dirty. I am using CISCO always on apic controller sandbox for simulating restapi along with POSTMAN as restapi client. Open you postman client add the static info or if you want to use it for multiple requst during that case better you create enviorment varibles. I have already created a variable enviorment and sending the GET request to APIC controller: {{ apic}} = sandboxapicem. Replace apic with sandboxapicem
       

HTTP GET Request: After autnrication, this request is requesting server to share the list of network devices.
https://{{apic}}.cisco.com/api/v1/network-device

HTTP GET Response: The below response will come in JSON. Removed rest of the part due to brevity.
{
    "response": [
        {
            "location": null,
            "type": "Cisco 3500I Unified Access Point",
            "serialNumber": "FGL1548S2YF",
            "errorCode": "null",
            "role": "ACCESS",
            "family": "Unified AP",
            "macAddress": "68:bc:0c:63:4a:b0",
            "softwareVersion": "8.1.14.16",
            "lastUpdateTime": 1590153808018,
            "locationName": null,
            "tagCount": "2",
            "hostname": "AP7081.059f.19ca",
            "inventoryStatusDetail": "NA",
            "upTime": null,
            "series": "Cisco 3500I Series Unified Access Points",
            "errorDescription": null,
            "lastUpdated": "2020-05-22 13:23:28",
            "roleSource": "AUTO",
            "apManagerInterfaceIp": "10.1.14.2",
            "bootDateTime": null,
            "collectionStatus": "Managed",
            "interfaceCount": null,
            "lineCardCount": null,
            "lineCardId": null,
            "managementIpAddress": "10.1.14.3",
            "memorySize": "NA",
            "platformId": "AIR-CAP3502I-A-K9",
            "reachabilityFailureReason": "NA",
            "reachabilityStatus": "Reachable",
            "snmpContact": "",
            "snmpLocation": "default location",
            "tunnelUdpPort": "16666",
            "instanceUuid": "cd6d9b24-839b-4d58-adfe-3fdf781e1782",
            "id": "cd6d9b24-839b-4d58-adfe-3fdf781e1782"
        },



Click Here To Read Rest Of The Post...

Saturday, May 16, 2020

Automation: How Important Data Format Is?


Programming Fundamentals: Data Formats: In my earlier post "Do I need to be programmer before learning Automation, SDN and NFV technologies?". The answer was no, all we need to understand how the data can be used to get various outputs which can be used for decision making process. One of the most important concept in programming language is how do we present the data to machines. In this post, I am trying to cover what is the importance of data formats in the programming language. How to choose which data format over the another?

Data format is nothing but the way how the data is being presented. Look at the below output which is easily readable by any human being as it is designed for human beings only but if machine has to read this data and take any action against it, unfortunately machine can't do anything. So we have to provide the data to machine in some data format which can be easily understood by machines and even for humans too :). See my earlier post of Junos Automation: Display Static Routes With PyEZ Table and View

Read the below which can be easily understood by any network engineer but might not be useful for any machine.
       
RP/0/0/CPU0:XR-1#show bgp vpnv4 unicast vrf VPN_ACME labels
Network            Next Hop        Rcvd Label      Local Label
Route Distinguisher: 1.1.1.1:0 (default for vrf VPN_ACME)
*> 100.100.100.1/32   0.0.0.0         nolabel         24000
*>i100.100.100.2/32   2.2.2.2         21              nolabel
RP/0/0/CPU0:XR-1#


How machine can read the data and take action against it. To get this done, data has to be sent to machine in some format. So now the point is clear why data format is important in programming world. There are many data formats can be used in the programming world, but JSON, XML and YAML are the most popular one. We can represrnt any type of data by leveraging the any of the data format language. It's all about the developer or application comfort which data format they would like to use. Below is the data format for interface configuration in XML and JSON format:
       
XML Format
JSON Format { "ietf-interfaces:interface": { "name": "GigabitEthernet2", "description": "Configured by NETCONF", "type": "iana-if-type:ethernetCsmacd", "enabled": true, "ietf-ip:ipv4": { "address": [ { "ip": "10.255.255.1", "netmask": "255.255.255.0" }, { "ip": "192.168.1.1", "netmask": "255.255.255.0" } ] }, "ietf-ip:ipv6": {} } }


Doesn't matter which data format lanaguage is used but we have below mentioned common data elements in any type of data format: 1. Syntax
2. Representation
3. Key/Value
4. Lists or Arrays

Let's dig more how to use common data elements:
1. Syntax: XML syntax can be easliy recoganized as it starts with XMLNS and every data is represented in . However in JSON data format is represnetd in { Curly Braces for Arrays} and [ Square Brackets For List].

2 & 3. Representation and Key Value: In XML every data element is represented with KEY and VALUE notation. In the below example ip is KEY and "10.255.25.1" is it's VALUE. netmask is KEY and "255.255.255.0" is value.
       

10.255.255.1
255.255.255.0


4. List or Arrays: There is difference in Key and Value representation in JSON. ietf-interfaces:interface is main object KEY and name, description, type are all type of Key and Value. "," is used to seperate Key:Value. We can see [] square brackets which are showing the list of IP addresses.
       
{
  "ietf-interfaces:interface": {
    "name": "GigabitEthernet2",
    "description": "Configured by NETCONF",
    "type": "iana-if-type:ethernetCsmacd",
    "enabled": true,
    "ietf-ip:ipv4": {
      "address": [
        {
          "ip": "10.255.255.1",
          "netmask": "255.255.255.0"
        },
        {
          "ip": "192.168.1.1",
          "netmask": "255.255.255.0"
        }
      ]
    },
    "ietf-ip:ipv6": {}
  }
}


Click Here To Read Rest Of The Post...

Sunday, May 10, 2020

Machine Learning For New Comers


Sharing collection of machine learning algorithms which can be used by anyone. The algorithms are very good for new comers who are willing to learn machine learning without having any prior knowledge. I have used SCIKIT Learn library in python to write the basic code

What is machine learning?

Difference Between Artificial Intelligence, Machine Learning and Deep Learning

All About Machine Learning Algorithms: When To Use Which Machine Learning Algorithm

What is neuron and artificial neuron in deep learning?

What is Perceptron in Deep Learning?

Loading First Data Set In Machine Learning

Predicting Values By Using k-nearest Neighbors Machine Learning Algorithm

Predict Prices By Using Linear Regression Algorithm In Machine Learning

Predict Probability By Using Logistic Regression In Machine Learning

When To Use Softmax Activation Algorithm In Deep Learning

Architecture Of Predicting Hand Written Digits

What is Data Pre-Processing In Machine Learning?

Rectified Linear Unit Activation Function In Deep Learning

Neural Network Mathematics

Understanding Back propagation In Neural Networks

Machine Learning Use Cases in Networking


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

Monday, May 4, 2020

Docker Guide For DEVNET Engineers


Almost 2 years ago, I have written post on docker containers which covers basic and advanced topics. Below is the summary of all posts and can be utilized if anyone is preparing for DEVNET or trying to become DEVNET engineer.

1. Beginners Guide To Docker

2. Docker Beginners Guide - Troubleshooting

3. Types Of Docker Installations

4. How Secure The Data Within The Container: Mounting Container Files With Host

5. Building Docker Image From Scratch

6. Understanding Layered Architecture of Docker Container Images


Click Here To Read Rest Of The Post...

Sunday, May 3, 2020

Deploy Network Slice By Using Flex-Algo


Previous post "Network Slice - Flex-Algo" explains how segment routing with flex also can help operators to create network slice and serve different type of business requirements.

In this post, I will be covering how to create network slice in service provider network by using segment routing. By default, IGP uses metric as constraint to calculate the shortest path tree. But while using flex-algo, delay will be used as metric to calculate end to end shortest path tree. Once the flex-algo topology will be created, after that we will be using link affinity to color the links and create constraints for flex-also also.

Have to follow below steps to create network slice:
1. Configure flex-algo(K) where K=128 in every router which will partipate in network slice.
2. Configure pre-fix sid for flex-algo(K). We already have prefix-sid configured for flex-algo(0) and now we have to configure one more value for flex-algo(K) where K=128. This is different from the previous prefix-sid but will be configured under same loopback.
3. Advertise fixed delay number to make the calulcations easy. I will be using delay as 100 micro seconds.

Apply link affinity to color the links and create constraints for flex-also.
1. Color links with any name like RED.
2. Exclude RED color links in Flex-algo

We will be using the above topology for creating network slice. Basic setup and configurations can be used from the segment routing post. Configuration to create network slice:
Apply the following configuration to all routers S1, S2, L3, L4, P5, P6 and PE7
       
router isis lab
  flex-algo 128           -> Flex-Algo(128) will be created and advertised
   metric-type delay      -> Delay will be used for path calculation
   advertise-definition
  !
  interface Loopback0
   address-family ipv4 unicast
    prefix-sid index  -> This is already configured. Please check the earlier post of Segment Routing - Control and Data Plane
    prefix-sid algorithm 128 absolute 1700X -> Replace X with Router Number. E.g. S1 will be using 17001 and PE7 will be suing 17007
 !
 performance-measurement
  interface GigabitEthernet0/0/0/X -> Replace X with all the interfaces which will be advertising delay
   delay-measurement
    advertise-delay 100   
! 


This new flex-algo(128) for IS-IS uses delay as metric (instead of cost) and assigns new SIDs(1700X) for each loopback interface apart from standard SIDs. We are using Performance Measurement to advertise the link delay.

Below is the output of flex-algo 128 topology. Instead of cost, it is using delay as metric to build SPT. {L4-S1 = 100}, {L4-S2 = 100}, {L4-S1/S2-L3} = 200},{L4-S1/S2-P5 = 200}, {L4-S1/S2-P5-P6 = 300}, {L4-S1/S2-P5-P6-PE7 = 400}. Also remember the output as the traffic is load balancing between GigabitEthernet0/0/0/0 and GigabitEthernet0/0/0/1 from L4 node towards L3,P5,P6 and PE7. (Compare this output with final output showing in last)
       
RP/0/0/CPU0:L4#show isis route flex-algo 128
L2 1.1.1.1/32 [100/115]
     via 1.4.0.1, GigabitEthernet0/0/0/0, S1, SRGB Base: 16000, Weight: 0
L2 2.2.2.2/32 [100/115]
     via 2.4.0.2, GigabitEthernet0/0/0/1, S2, SRGB Base: 16000, Weight: 0
L2 3.3.3.3/32 [200/115]
     via 1.4.0.1, GigabitEthernet0/0/0/0, S1, SRGB Base: 16000, Weight: 0
     via 2.4.0.2, GigabitEthernet0/0/0/1, S2, SRGB Base: 16000, Weight: 0
L2 5.5.5.5/32 [200/115]
     via 1.4.0.1, GigabitEthernet0/0/0/0, S1, SRGB Base: 16000, Weight: 0
     via 2.4.0.2, GigabitEthernet0/0/0/1, S2, SRGB Base: 16000, Weight: 0
L2 6.6.6.6/32 [300/115]
     via 1.4.0.1, GigabitEthernet0/0/0/0, S1, SRGB Base: 16000, Weight: 0
     via 2.4.0.2, GigabitEthernet0/0/0/1, S2, SRGB Base: 16000, Weight: 0
L2 7.7.7.7/32 [400/115]
     via 1.4.0.1, GigabitEthernet0/0/0/0, S1, SRGB Base: 16000, Weight: 0
     via 2.4.0.2, GigabitEthernet0/0/0/1, S2, SRGB Base: 16000, Weight: 0
RP/0/0/CPU0:L4#


Below output is also showing different prefix-SID like 1007 instead of 17007,Both values 1007 and 17007 are same, as we have defined absolute value 17007 for PE7. SRGB base block starts with 16000, If we substract 17007-16000, we will get 1007. This is being shown in the below output. The same true for other values too.
       
RP/0/0/CPU0:L4#show isi route flex-algo 128 7.7.7.7/32 detail
L2 7.7.7.7/32 [400/115] Label: 16007, medium priority
     via 1.4.0.1, GigabitEthernet0/0/0/0, S1, SRGB Base: 16000, Weight: 0
     via 2.4.0.2, GigabitEthernet0/0/0/1, S2, SRGB Base: 16000, Weight: 0
     src PE7.00-00, 7.7.7.7, prefix-SID index 1007, R:0 N:1 P:0 E:0 V:0 L:0,  -> Read More About Flags - Segment Routing Control Plane - ISIS
         Alg:128
RP/0/0/CPU0:L4#


Below output of forwarding table will club the above two outputs. Removed the rest of output for brevity
       
RP/0/0/CPU0:L4#show mpls forwarding
Sat May  2 07:49:26.312 UTC
Local  Outgoing    Prefix             
Label  Label       or ID              
16001  16001       SR Pfx (idx 1)     
16002  Pop         SR Pfx (idx 2)     
16003  16003       SR Pfx (idx 3)     
16005  16005       SR Pfx (idx 5)     
16006  16006       SR Pfx (idx 6)     
16007  16007       SR Pfx (idx 7)     
17001  17001       SR Pfx (idx 1001)  
17002  Pop         SR Pfx (idx 1002)  
17003  17003       SR Pfx (idx 1003)  
17005  17005       SR Pfx (idx 1005)  
17006  17006       SR Pfx (idx 1006)  
17007  17007       SR Pfx (idx 1007)  


So far, we have two network slices configured for the network i.e. Default(0) and Flex-Algo(128). Let's Color the links with any name like RED and exclude RED color from the Flex-Algo(128). This means Flex-Algo(128) will not be using the links which are color as RED in topology building and makes these links out of the network slice.

Color the links of S1 (Gi0/0/0/0) and L4 (Gi0/0/0/2)
       
Node S1 Config
router isis lab
  affinity-map red bit-position 1  -> Bit-position range is from 0 to 255. Every Color defines one bit-position. Max 32 colors can be mapped in affinity-map 
  !
  interface GigabitEthernet0/0/0/0
   affinity flex-algo red             -> Coloring Gi0/0/0/0 as red and advertising in flex-algo
  !
 !  

Node L4 Config
router isis lab
  affinity-map red bit-position 1
  !
  interface GigabitEthernet0/0/0/2
   affinity flex-algo red
  !
 !  


Now we exclude the link "red" from Flex-Algo 128 in every router where Flex-Algo 128 is configured.
       
router isis lab
  affinity-map red bit-position 1
  flex-algo 128
   affinity exclude-any red    ->The same red color used in the above config. Now Gi0/0/0/0 of S1 and Gi0/0/0/2 of L4 will not participate in flex-algo(128)
  !
 !  


Check the below out of L4 which says that only Gi0/0/0/1 is used as outgoing interface. Now Gi0/0/0/0 will not participate in flex-algo(128) as we have exclude it by using the above configuration.
       
RP/0/0/CPU0:L4#show isis route flex-algo 128
IS-IS lab IPv4 Unicast routes Flex-Algo 128
L2 1.1.1.1/32 [300/115]
     via 2.4.0.2, GigabitEthernet0/0/0/1, S2, SRGB Base: 16000, Weight: 0
L2 2.2.2.2/32 [100/115]
     via 2.4.0.2, GigabitEthernet0/0/0/1, S2, SRGB Base: 16000, Weight: 0
L2 3.3.3.3/32 [200/115]
     via 2.4.0.2, GigabitEthernet0/0/0/1, S2, SRGB Base: 16000, Weight: 0
L2 5.5.5.5/32 [200/115]
     via 2.4.0.2, GigabitEthernet0/0/0/1, S2, SRGB Base: 16000, Weight: 0
L2 6.6.6.6/32 [300/115]
     via 2.4.0.2, GigabitEthernet0/0/0/1, S2, SRGB Base: 16000, Weight: 0
L2 7.7.7.7/32 [400/115]
     via 2.4.0.2, GigabitEthernet0/0/0/1, S2, SRGB Base: 16000, Weight: 0
RP/0/0/CPU0:L4#show isis route flex-algo 128

Click Here To Read Rest Of The Post...

Saturday, May 2, 2020

Network Slicing - Flex Algo


GSMA defines, "5G networks, in combination with network slicing, permit business customers to enjoy connectivity and data processing tailored to the specific business requirements that adhere to a Service Level Agreement (SLA) agreed with the mobile operator. The customisable network capabilities include data speed, quality, latency, reliability, security, and services."

What is customisable network? Every network is fixed network like monolithic and fully dependent on the underneath resource availability. Fixed or monolithic sort of networks can only provide the connectivity with basic business SLAs. But 5G has different network requirements to support different type of business use cases like enhanced mobile broadband, massive machine to machine and ultra reliable low latency. To support different type of use cases, we need network which is like cloud native, we need network like micro-services, we need network like docker. To have these different customization we have to slice the network into different logical layers and use cases can be mapped to logical layers as per the signed business SLA. Dividing monolithic network into different layers or slices by using segment routing along with flexible algorithm is called customisable network or "Network Slicing".

What is Network Slicing?
Network slicing is an end-to-end concept that divides the physical network into logical parallel layers. It enables deployment of multiple logical, self-contained and independent shared or partitioned networks concurrently on a common infrastructure by abstracting, isolating and orcestrating it.

How do we create slicing in service provider network?
We can use flexible algorithm along with Segment Routing to create different slices in the network.

What is Flex Algrithm?
Segment Routing Control Plane - ISIS post explains about the Router Capability TLV (242). Router capability TLV has SR-Algorithm(Segment Routing Algorithm, Flex Algo, Flex 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: Shortest Path First (SPF) algorithm based on link metric. This is the well-known shortest path algorithm as computed by the IS-IS process. Consistent with the deployed practice for link-state protocols, algorithm 0 permits any node to overwrite the SPF path with a different path based on local policy.

1: Strict Shortest Path First (SPF) algorithm based on link metric. The algorithm is identical to algorithm 0 but algorithm 1 requires that all nodes along the path will honor the SPF routing decision. Local policy MUST NOT alter thevforwarding decision computed by algorithm 1 at the node claiming to support algorithm.

Flexible Algo means that this is flexible rather than fixed and the algorithm is defined by the operator based on per deployment basis.

Below are the steps used to discover and deploy Flex-Algo Topology:
Topology Discovery
1. A node computes Flex-Algo(K) if it is enabled for K. K is nothing but mathematical value starts from 128 till 255.
2. Flex Algo Topology is defined by pruning any nodes and links that is not advertising participation to K.
3. Advertises prefix-sid for that flex also node.
Compute Shortest Path
1. Compute shortest-path tree on Flex-Algo Topo(K) with the metric defined by K. Metric could be IGP, TE or Delay.

Build FIB Table
1. Install any reachable Prefix-SID of Flex-Algo(K) in the forwarding table

By using the above steps, let's see how Flex Algo(K) builds its topology. As per above figure, Node 10 supports 0,128 and 138. Node 1,2,3 and 4 supports flex algo 0 and 128. Nodes 5,6,7 and 8 supports flex algo 0 and 138. Node 9 supports flex also 0,128 and 138.

Node10 will be advertising prefix sid 16010 for flex algo 0, 17010 for flex also 128 and 18010 for flex algo 138. Similarly Nodes 1 will be advertising 16001 for flex algo 0 and 17001 for flex also 128.

By using the flex algo or flexible algorithm we can easily create network slices. Nodes below to same flex algo be part of same network slice. Once we create the slice, accordingly we can apply route the traffic on to the slices as per the business SLA.

Stay tuned for my next post, which will be discussing how to implement network slice on Cisco IOS-XR based platform. References

Click Here To Read Rest Of The Post...