Click Here To Read Rest Of The Post...
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 (Segment Routing - Ti-LFA - Adjacency Sid Protection) how Ti-LFA solves the above issues by leveraging Segment Routing.
Click Here To Read Rest Of The Post...
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:
Click Here To Read Rest Of The Post...
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.
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:
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.
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 
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)
Click Here To Read Rest Of The Post...
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.
Click Here To Read Rest Of The Post...
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.
Click Here To Read Rest Of The Post...
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.
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
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.
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.
Click Here To Read Rest Of The Post...
Subscribe to:
Posts (Atom)