MPLSVPN - Moving Towards SDN and NFV Based Networks

The Invisible Risk in Your OT Network: Why Standard SPAN Might Be Your Weakest Link

shivlu@mplsvpn.info (Shivlu Jain) — Tue, 31 Mar 2026 14:32:00 +0530

In the world of Industrial Control Systems (ICS), visibility is the foundation of security. To protect what you have, you have to see what’s happening. For most organizations, the "quick win" for visibility is enabling SPAN (Switched Port Analyzer)—otherwise known as port mirroring—to feed traffic into an IDS or monitoring tool.

It’s a solution that works... until the inherent limitations of SPAN collide with the unforgiving requirements of an OT environment.

The Hidden Tax of Port Mirroring

Many teams approach OT networking with an IT mindset, assuming a switch is a switch. However, standard IT switches often handle SPAN through software-based processes. When you toggle that mirror port, you aren't just "copying" data; you are fundamentally changing how the switch operates.

On standard switches, enabling SPAN requires the device to:

Tax the CPU and Memory: Unlike primary switching, SPAN is often a secondary priority for the hardware. If the CPU spikes, the switch will drop SPAN packets first to save itself.
Alter Packet Timing: SPAN changes the timing of frame interactions. What your monitoring tool sees isn't necessarily a perfect chronological reflection of what happened on the wire.
Filter Out "Bad" Data: Most SPAN ports automatically drop corrupted packets or those below minimum size. In a troubleshooting scenario, those "bad" packets are exactly what you need to see.

The OT Reality: Why "Standard" Isn't Enough

In a manufacturing plant, traffic is deterministic. Cycles are time-bound, and stability is non-negotiable. Standard switches struggle here because:

Ingress/Egress Bottlenecks: If you try to mirror a 1Gbps full-duplex link (2Gbps total) into a 1Gbps SPAN port, the math simply doesn't work. The switch will drop packets, creating massive blind spots.
Lack of Fidelity: Because SPAN isn't a passive technology, there is no guarantee of absolute fidelity. In some cases, SPAN-gathered data can even be challenged in legal or compliance audits because it isn't a 100% accurate copy of the raw traffic.
The "Hidden" Cost: While SPAN ports are "free" on the box, they require manual configuration, CLI validation, and constant oversight. One wrong command during a live production cycle can bring an entire line down.

The Industrial Difference: Purpose-Built Hardware

This is where industrial-grade hardware, such as Cisco Industrial Ethernet (IE) Switches, changes the game. These are engineered specifically to overcome the "ABCs" of SPAN limitations:

Hardware-Based Replication (ASIC): Packet duplication happens at the hardware level. SPAN doesn’t load the CPU, ensuring that monitoring stays "invisible" to operations.
High Backplane Capacity: Designed to handle the "double traffic" load of mirroring without bottlenecking the primary data path or dropping packets during bursts.
Advanced QoS for OT: Control traffic always gets the highest priority. Even if the mirror port is saturated, your critical PLC-to-HMI communication remains untouched.
Line-Rate Mirroring: You get visibility at scale without throttling, ensuring that the "blind spots" found in standard IT switches are eliminated.

The Bottom Line: Visibility Without Vulnerability

True OT security isn't just about adding tools; it’s about ensuring your network can safely support them. Using standard SPAN is a "best effort" solution in an environment where "best effort" isn't good enough.

Before turning on SPAN in your plant, ask yourself: Is your network built for IT convenience... or OT reliability?

If you can't guarantee the timing and delivery of every packet, you aren't just missing data—you're risking your production.

ECN in AI/ML Networks

shivlu@mplsvpn.info (Shivlu Jain) — Thu, 4 Sep 2025 08:41:00 +0530

ECN in AI/ML Networks: Smarter Congestion Control for High-Performance Training

Artificial Intelligence (AI) and Machine Learning (ML) workloads are pushing the limits of modern data center networks. Whether it’s distributed deep learning across hundreds of GPUs or real-time inference pipelines, the network fabric must deliver ultra-low latency, high throughput, and predictable performance. One key enabler for this is Explicit Congestion Notification (ECN) — a mechanism in IP networks that signals congestion before packets are dropped. For AI/ML clusters, where packet loss can mean massive slowdowns in training jobs, ECN is becoming a critical tool in ensuring efficient communication.

What is ECN?

Traditionally, when routers or switches face congestion, they drop packets. Endpoints detect this loss and throttle back, but this reactive approach can hurt performance, especially in high-bandwidth, low-latency environments like AI/ML networks.
ECN changes the game:

Instead of dropping packets, congested switches mark them with an ECN flag in the IP header.
The receiving endpoint detects the mark and signals the sender to reduce its transmission rate.
This avoids packet loss while still providing congestion feedback.
In short: ECN enables early warning signals of congestion, reducing retransmissions and keeping throughput steady.

Why ECN Matters for AI/ML Networks

1. Distributed Training Traffic

Large AI models (like GPTs or computer vision pipelines) use distributed training across multiple GPUs and servers. This involves heavy all-to-all traffic patterns (e.g., gradient exchange). Even minor congestion can lead to synchronization delays.
ECN helps by ensuring:

Fewer packet drops → less retransmission overhead.
Stable throughput → consistent training times.

2. RDMA and RoCE v2 Optimization

Most AI/ML clusters rely on RDMA (Remote Direct Memory Access) over Converged Ethernet (RoCE v2). RDMA is extremely sensitive to packet loss; even a single dropped packet can stall GPU-to-GPU communication.
With ECN + Priority Flow Control (PFC):

ECN provides early congestion signals.
PFC ensures lossless transport.
Together, they minimize latency spikes during training.

3. Better GPU Utilization

Every millisecond counts when you’re training multi-billion parameter models. If GPUs are waiting due to retransmissions or congestion stalls, utilization drops, wasting costly resources.
ECN enables:

Faster convergence in distributed workloads.
Higher GPU efficiency → better ROI on infrastructure.

ECN in Practice: Deployment Considerations

Switch Support: Modern data center switches (Cisco, Arista, NVIDIA/Mellanox) support ECN marking with configurable thresholds.
Transport Layer Integration: Works best with DCTCP (Data Center TCP) or RDMA protocols tuned for ECN.
Fine-Tuning: ECN thresholds must be carefully tuned per workload. Too aggressive → underutilized bandwidth. Too lax → congestion before feedback kicks in.

The Future: ECN and AI Fabrics

As AI/ML models grow in size and complexity, the pressure on network fabrics will only increase. ECN is emerging as a must-have feature for AI supercomputing clusters, cloud providers offering GPU-as-a-Service, and enterprises scaling private AI workloads. In combination with advanced telemetry, adaptive routing, and congestion control algorithms, ECN will form the backbone of self-optimizing AI fabrics.

Final Thoughts

ECN may be a small field in the IP header, but its impact on AI/ML performance is huge. By enabling smarter congestion management, ECN keeps packets flowing, GPUs humming, and training jobs on schedule. For anyone designing AI/ML networks today, ECN isn’t optional—it’s essential.

IOT Vs Purdue Model

shivlu@mplsvpn.info (Shivlu Jain) — Wed, 3 May 2023 08:43:00 +0530

The Internet of Things (IoT) and the Purdue model are both related to the field of industrial automation and control systems.

The IoT refers to the network of physical objects embedded with sensors, software, and connectivity capabilities that enable them to collect and exchange data over the internet. IoT devices can include sensors, actuators, and other devices that are used in industrial automation systems.

The Purdue model, on the other hand, is a hierarchical reference architecture that organizes the different levels of an industrial control system into five layers. It provides a framework for integrating the different components of an industrial control system, from the physical equipment to the enterprise-level business systems.

In the context of industrial automation and control systems, IoT devices can be integrated into the different layers of the Purdue model to provide real-time monitoring and control of physical processes. For example, sensors and other IoT devices can be used in Level 0 to collect data on the physical equipment and processes, while devices like PLCs and DCSs in Level 1 can be used to control the physical processes based on the data collected by the IoT devices.

At higher levels of the Purdue model, IoT devices can be used to provide real-time data to systems like MES and SCADA, allowing for improved process monitoring and control. Additionally, IoT data can be used in production planning and enterprise business planning systems to inform decision-making and improve overall efficiency.

Overall, the integration of IoT devices into the Purdue model can enable better real-time monitoring and control of industrial processes, leading to improved efficiency, productivity, and cost savings.

What is Purdue Model ?

shivlu@mplsvpn.info (Shivlu Jain) — Wed, 3 May 2023 08:40:00 +0530

The Purdue model, also known as the Purdue Enterprise Reference Architecture (PERA), is a reference architecture for industrial automation systems. It was developed in the late 1980s by researchers at Purdue University as a way to organize the different levels of an industrial control system into a hierarchical structure.

The Purdue model consists of five levels, each representing a different aspect of the industrial control system:
Level 0: Physical processes - This level represents the physical equipment and processes that are being controlled, such as sensors, actuators, and machinery.
Level 1: Basic control - This level includes the devices and systems that directly control the physical processes, such as programmable logic controllers (PLCs) and distributed control systems (DCSs).
Level 2: Supervisory control - This level includes the systems that monitor and control multiple processes, such as manufacturing execution systems (MES) and supervisory control and data acquisition (SCADA) systems.
Level 3: Production planning - This level includes the systems that plan and schedule production activities, such as enterprise resource planning (ERP) systems.
Level 4: Enterprise business planning - This level includes the business systems that support the overall goals and objectives of the organization, such as customer relationship management (CRM) and financial management systems.

The Purdue model provides a framework for organizing and integrating the various components of an industrial control system, from the physical processes to the enterprise-level business systems. It has been widely adopted as a reference architecture for industrial automation systems, and is used by many organizations and vendors in the industry.

What is Internet of Things?

shivlu@mplsvpn.info (Shivlu Jain) — Wed, 3 May 2023 08:36:00 +0530

The Internet of Things (IoT) refers to the network of physical objects or "things" embedded with sensors, software, and connectivity capabilities that allow them to collect and exchange data over the internet. These devices can be anything from household appliances and cars to industrial machinery and medical equipment.

IoT devices use sensors and other technologies to collect data on various aspects of the physical world, such as temperature, humidity, motion, and location. This data can then be analyzed and used to inform decisions, automate processes, and improve efficiency in a wide range of industries, from manufacturing and transportation to healthcare and agriculture.

The connectivity capabilities of IoT devices allow them to communicate with each other and with other systems, such as cloud-based platforms and applications. This enables real-time monitoring and control of physical systems and processes, as well as the ability to remotely manage and troubleshoot devices.

The IoT is expected to have a significant impact on a range of industries, enabling new business models, improving efficiency and productivity, and creating new opportunities for innovation and growth. However, the rapid proliferation of IoT devices also raises concerns about data security and privacy, as well as the need for interoperability and standardization in IoT systems.

The simplicity and complexity of hybrid work

shivlu@mplsvpn.info (Shivlu Jain) — Thu, 4 Aug 2022 09:41:00 +0530

While hybrid work unlocks flexibility, productivity and transparency for the workforce, it exposes the backend networks to vulnerabilities and operational complexities India was one of the first economies to offset losses from the global health crisis of 2020. Thanks to a massive workforce and adoption of new-age technologies, businesses in India – including Indian entities of global organizations – were quick to recover and reset. But everything isn’t hunky dory yet. The new normal of a distributed workplace and a distributed workforce has opened up new challenges of data security, distributed operations and long-term resilience.

Flexibility of time and space
During the critical phase of recovery, businesses in India witnessed eye-boggling statistics of employee attrition, which consequently led to unrealistic salaries and incentive structures that were not viable for business in the long run. Businesses that refused to adapt a work-from-home ideology saw mass exodus of the workforce leaving and seeking more flexible working options. In short, the new-age employee has morphed into a superhero that feeds on a hybrid lifestyle. And to get the most out of this superhero, businesses need to enable flexibility – of time and space, security of the IT network, and simplicity of operations. The good news is that all of these capabilities are now available in a SaaS model for businesses to adopt and grow.

Multi-layer distributed business
Today, the workforce no longer operates from a head or branch office, which is secured by a cosy, well-guarded network. Employees use devices of their choice to connect to networks of their choice from locations of their choice, at a time of their choice. Suddenly, the challenge for the CIO has manifested into a four-legged monster. Suddenly there is a need to one, secure the employee’s endpoint device, two, secure the broadband internet that flows into the device, three, pay attention to protocols and compliance policies of the respective city and country, and four, secure the network at all times, round-the-clock. In short, the network just moved out of the head office into the whole wide world, and suddenly, all of the critical data is floating all over town! The only way to ensure security and transparency is to deploy a combination of software and hardware solutions that provide all-round security while having the ability to unlock business-critical insights from the network.

The need to simplify, automate and secure the network
Today, businesses need to realize that the network is at the heart of hybrid work and ensure that the IT has the network infrastructure to simplify, automate and secure the network. In the new era of distributed work, businesses to need to adopt a ‘security everywhere’ approach that eliminates threats, secures endpoint devices and verifies user identities, while flagging vulnerabilities in real-time and providing remedial insights. The goal of all-encompassing security can be achieved by successfully bridging wired and wireless networks with an intelligent management platform.

In order to provide a powerful yet simplified management experience, technologies like AI and ML can be leveraged to achieved seamless automation and visibility across multiple domains, leading to simplified IT operations and network management. By deploying AI -enabled security at scale, your business can achieve unparalleled visibility within the framework of zero-trust security.

The four key pillars to transform your access network are:
Switching
Wireless solutions
Software
Management platforms

Interoperability and on-demand IT
By deploying secure and resilient switches, your network can achieve interoperability across connectivity protocols, while leveraging AI to unlock insights from capacity, traffic and bandwidth utilization data, to optimize network performance end-to-end. A cloud-first network management platform aligns with your changing business needs by uncovering insights from network data. As we move on to an uncertain future, all of these solutions can be deployed through on-demand, pay-as-you-go subscription models allowing you to ramp-up and ramp-down at will.

Segment Routing - Ti-LFA - Node Protection

shivlu@mplsvpn.info (Shivlu Jain) — Sun, 14 Jun 2020 12:19:00 +0530

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

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

As per previous post, Ti-LFA node protection is already configured and now we will be configuring Ti-LFA node protection.

       
router isis 1
  !
 interface GigabitEthernet0/0/0/0
  point-to-point
  address-family ipv4 unicast
   fast-reroute per-prefix
   fast-reroute per-prefix ti-lfa
   fast-reroute per-prefix tiebreaker node-protecting index 100 -> Ti-LFA Node Protection With Priority 100
   metric 500
  !
!
 interface GigabitEthernet0/0/0/1
  point-to-point
  address-family ipv4 unicast
   fast-reroute per-prefix
   fast-reroute per-prefix ti-lfa
   fast-reroute per-prefix tiebreaker node-protecting index 100 -> Ti-LFA Node Protection With Priority 100
   metric 500
  !


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







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





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





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


With maximum of 3 transport labels, we can reach to the destination.





Here is the beginning of my post. And here is the rest of it.

http://www.mplsvpn.info



Segment Routing - Ti-LFA - Adjacency Sid Protection
shivlu@mplsvpn.info (Shivlu Jain) — Sat, 6 Jun 2020 19:45:00 +0530


Brief overview was shared in earlier post of "Segment Routing - Topology Independent LFA". In this post, I am showing some simulated results of per prefix Ti-LFA where in case of primary link failure, SR-MPLS with Ti-LFA enabled seamlessly re-route the destined traffic by excluding the direct link. If direct adjacent node need to be exclude from Ti-LFA calculation, it is called Ti-LFA node protection.



Below is SR-MPLS enabled topology used for simulation. XR-11 is sending traffic to loopback 1.1.1.12 (XR-12). There is no Ti-LFA configured on XR-11.








Verify that Ti-LFA is not configured
       
RP/0/0/CPU0:xrvr-11#show isis fast-reroute 1.1.1.12/32 detail
L2 1.1.1.12/32 [1020/115] medium priority
     via 99.1.11.1, GigabitEthernet0/0/0/0, xrvr-1, SRGB Base: 16000, Weight: 0
       No FRR backup        (Check here)
     src xrvr-12.00-00, 1.1.1.12, prefix-SID index 12, R:0 N:1 P:0 E:0 V:0 L:0
RP/0/0/CPU0:xrvr-11#




ISIS adjacency is configured for IPv4 and IPv6 address family. 
       
RP/0/0/CPU0:xrvr-11#show isis adjacency systemid xrvr-1  detail
IS-IS 1 Level-2 adjacencies:
System Id      Interface        SNPA           State Hold Changed  NSF IPv4 IPv6
                                                                       BFD  BFD
xrvr-1         Gi0/0/0/0        *PtoP*         Up    21   00:08:59 Yes None None
  Area Address:           49.0001
  Neighbor IPv4 Address:  99.1.11.1*
  Adjacency SID:          24000           -> Adjacency SID for IPv4 address family. This is not protected, so no backup interface
  Non-FRR Adjacency SID:  24001
  Neighbor IPv6 Address:  fe80::f816:3eff:fe8b:9b27*
  Adjacency SID:          24002    -> Adjacency SID for IPv6 address family. This is not protected, so no backup interface
  Non-FRR Adjacency SID:  24003
  Topology:               IPv4 Unicast
  Topology:               IPv6 Unicast
RP/0/0/CPU0:xrvr-11#





Verify MPLS forwarding. Most of the output is deleted for brevity
       
RP/0/0/CPU0:xrvr-11#show mpls forwarding
Local  Outgoing    Prefix             Outgoing     Next Hop        Bytes
Label  Label       or ID              Interface                    Switched
------ ----------- ------------------ ------------ --------------- ------------
16001  Pop         SR Pfx (idx 1)     Gi0/0/0/0    99.1.11.1       0
16002  16002       SR Pfx (idx 2)     Gi0/0/0/0    99.1.11.1       0
16003  16003       SR Pfx (idx 3)     Gi0/0/0/0    99.1.11.1       0
16004  16004       SR Pfx (idx 4)     Gi0/0/0/0    99.1.11.1       2553
16005  Pop         SR Pfx (idx 5)     Gi0/0/0/1    99.5.11.5       0
16006  16006       SR Pfx (idx 6)     Gi0/0/0/0    99.1.11.1       0
16007  16007       SR Pfx (idx 7)     Gi0/0/0/0    99.1.11.1       0
16012  16012       SR Pfx (idx 12)    Gi0/0/0/0    99.1.11.1       18048
16013  16013       SR Pfx (idx 13)    Gi0/0/0/0    99.1.11.1       0
24000  Pop         SR Adj (idx 1)     Gi0/0/0/0    99.1.11.1       0
24001  Pop         SR Adj (idx 3)     Gi0/0/0/0    99.1.11.1       0
24002  Pop         SR Adj (idx 1)     Gi0/0/0/0    fe80::f816:3eff:fe8b:9b27   \
                                                                   0
24003  Pop         SR Adj (idx 3)     Gi0/0/0/0    fe80::f816:3eff:fe8b:9b27   \
                                                                   0
RP/0/0/CPU0:xrvr-11#





Verify end to end path for XR-12
       
RP/0/0/CPU0:xrvr-11#traceroute 1.1.1.12
Tracing the route to 1.1.1.12
 1  99.1.11.1 [MPLS: Label 16012 Exp 0] 9 msec  9 msec  9 msec
 2  99.1.2.2 [MPLS: Label 16012 Exp 0] 9 msec  9 msec  9 msec
 3  99.2.3.3 [MPLS: Label 16012 Exp 0] 9 msec  9 msec  9 msec
 4  99.3.12.12 9 msec  9 msec  9 msec




Configure Ti-LFA for IPv4 address family only on XR-11:
       
router isis 1
  !
 interface GigabitEthernet0/0/0/0
  point-to-point
  address-family ipv4 unicast
   fast-reroute per-prefix
   fast-reroute per-prefix ti-lfa
   metric 500
  !
!
 interface GigabitEthernet0/0/0/1
  point-to-point
  address-family ipv4 unicast
   fast-reroute per-prefix
   fast-reroute per-prefix ti-lfa
   metric 500
  !




Once configured Ti-LFA, XR-11 will consider path via XR-5 in case failure between XR-11 and XR-1 as shown in the below topology.





Verify ISIS adjacency towards XR-1
       
RP/0/0/CPU0:xrvr-11#show isis adjacency systemid xrvr-1  detail
IS-IS 1 Level-2 adjacencies:
System Id      Interface        SNPA           State Hold Changed  NSF IPv4 IPv6
                                                                       BFD  BFD
xrvr-1         Gi0/0/0/0        *PtoP*         Up    26   00:16:29 Yes None None
  Area Address:           49.0001
  Neighbor IPv4 Address:  99.1.11.1*
  Adjacency SID:          24000 (protected)      -> Adjacency SID is protected
   Backup label stack:    [16001]   -> Adjacency SID 24000 is protected with 16001 backup
   Backup stack size:     1
   Backup interface:      Gi0/0/0/1              -> Now backup interface is showing
   Backup nexthop:        99.5.11.5   -> Next hop address is XR-5
   Backup node address:   1.1.1.1          -> Backup node is XR-1
  Non-FRR Adjacency SID:  24001         
  Neighbor IPv6 Address:  fe80::f816:3eff:fe8b:9b27*
  Adjacency SID:          24002                  -> We have configured Ti-LFA for IPv4. Still IPv6 traffic is not protected
  Non-FRR Adjacency SID:  24003
  Topology:               IPv4 Unicast
  Topology:               IPv6 Unicast
RP/0/0/CPU0:xrvr-11#





Verify Ti-LFA for XR-12 (show the below config - prefix-SID index 12)
       
RP/0/0/CPU0:xrvr-11#show isis fast-reroute 1.1.1.12/32 detail
L2 1.1.1.12/32 [1020/115] medium priority
     via 99.1.11.1, GigabitEthernet0/0/0/0, xrvr-1, SRGB Base: 16000, Weight: 0
       FRR backup via 99.5.11.5, GigabitEthernet0/0/0/1, xrvr-5, SRGB Base: 16000, Weight: 0, Metric: 1030
       P: No, TM: 1030, LC: No, NP: No, D: Yes, SRLG: Yes
     src xrvr-12.00-00, 1.1.1.12, prefix-SID index 12, R:0 N:1 P:0 E:0 V:0 L:0
RP/0/0/CPU0:xrvr-11#





Below output is showing that Gi0/0/0/0 is protected with Gi0/0/0/1. In case of failure of Gi0/0/0/0 link, XR-11 will add 16001 as outgoing label which is prefix sid of XR-1.
       
RP/0/0/CPU0:xrvr-11#show mpls forwarding labels 24000
Tue May 26 17:42:12.824 UTC
Local  Outgoing    Prefix             Outgoing     Next Hop        Bytes
Label  Label       or ID              Interface                    Switched
------ ----------- ------------------ ------------ --------------- ------------
24000  Pop         SR Adj (idx 1)     Gi0/0/0/0    99.1.11.1       0
       16001       SR Adj (idx 1)     Gi0/0/0/1    99.5.11.5       0            (!)
RP/0/0/CPU0:xrvr-11#






The above output can be cross verify by running below command.
       
RP/0/0/CPU0:xrvr-11#show mpls forwarding labels 24000 detail
Local  Outgoing    Prefix             Outgoing     Next Hop        Bytes
Label  Label       or ID              Interface                    Switched
------ ----------- ------------------ ------------ --------------- ------------
24000  Pop         SR Adj (idx 1)     Gi0/0/0/0    99.1.11.1       0
     Path Flags: 0x400 [  BKUP-IDX:1 (0xa18d01fc) ]
     Version: 120, Priority: 1
     Label Stack (Top -> Bottom): { Imp-Null }
     NHID: 0x0, Encap-ID: N/A, Path idx: 0, Backup path idx: 1, Weight: 500
     MAC/Encaps: 14/14, MTU: 1500
     Packets Switched: 0

     16001          SR Adj (idx 1)     Gi0/0/0/1    99.5.11.5       0            (!)
     Path Flags: 0x100 [  BKUP, NoFwd ]
     Version: 120, Priority: 1
     Label Stack (Top -> Bottom): { 16001 }   -> Backup label
     NHID: 0x0, Encap-ID: N/A, Path idx: 1, Backup path idx: 0, Weight: 500
     MAC/Encaps: 14/18, MTU: 1500
     Packets Switched: 0
     (!): FRR pure backup
RP/0/0/CPU0:xrvr-11#




Now finally verify the forwarding plane:
       
RP/0/0/CPU0:xrvr-11#show cef 1.1.1.12/32 detail
1.1.1.12/32, version 112, labeled SR, internal 0x1000001 0x81 (ptr 0xa12e5a7c) [2], 0x0 (0xa12ca878), 0xa28 (0xa18b607c)
 Updated May 26 15:27:01.779
 local adjacency 99.1.11.1
 Prefix Len 32, traffic index 0, precedence n/a, priority 1
 Extensions: context-label:16012           -> Check the special label
  gateway array (0xa122fdb4) reference count 21, flags 0xa00068, source rib (7), 0 backups
                [8 type 5 flags 0x8401 (0xa15618c0) ext 0x0 (0x0)]
  LW-LDI[type=5, refc=3, ptr=0xa12ca878, sh-ldi=0xa15618c0]
  gateway array update type-time 1 May 26 15:27:01.779
    via 99.1.11.1/32, GigabitEthernet0/0/0/0, 9 dependencies, weight 0, class 0, protected [flags 0x400]
    path-idx 0 bkup-idx 1 NHID 0x0 [0xa18d00e4 0x0]
    next hop 99.1.11.1/32
     local label 16012      labels imposed {16012}
   via 99.5.11.5/32, GigabitEthernet0/0/0/1, 9 dependencies, weight 0, class 0, backup (Local-LFA) [flags 0x300]
    path-idx 1 NHID 0x0 [0xa15fd4a8 0x0]
    next hop 99.5.11.5/32
    local adjacency
     local label 16012      labels imposed {16012}
    Hash  OK  Interface                 Address
    0     Y   GigabitEthernet0/0/0/0    99.1.11.1
RP/0/0/CPU0:xrvr-11#




Now shutdown the link between XR-11 and XR-1 and check the backup path
       
RP/0/0/CPU0:xrvr-11#traceroute 1.1.1.12
Tracing the route to 1.1.1.12
 1  99.5.11.5 [MPLS: Label 16012 Exp 0] 39 msec  9 msec  9 msec
 2  99.1.5.1 [MPLS: Label 16012 Exp 0] 9 msec  9 msec  9 msec
 3  99.1.2.2 [MPLS: Label 16012 Exp 0] 9 msec  9 msec  9 msec
 4  99.2.3.3 [MPLS: Label 16012 Exp 0] 9 msec  9 msec  9 msec
 5  99.3.12.12 9 msec  9 msec  9 msec
RP/0/0/CPU0:xrvr-11#


http://www.mplsvpn.info


Segment Routing  - Topology Independent LFA
shivlu@mplsvpn.info (Shivlu Jain) — Sun, 31 May 2020 22:01:00 +0530

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. 


http://www.mplsvpn.info


What is data model - Yang ?
shivlu@mplsvpn.info (Shivlu Jain) — Sun, 24 May 2020 15:28:00 +0530

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.





http://www.mplsvpn.info