MPLSVPN - Moving Towards SDN and NFV Based Networks

Frame Preemption in OT Networks: Ensuring Deterministic Performance for SCADA Traffic

shivlu@mplsvpn.info (Shivlu Jain) — Mon, 4 May 2026 11:39:00 +0530

In modern industrial environments, the convergence of IT and OT networks has introduced both opportunities and challenges. While a unified network improves visibility, scalability, and cost efficiency, it also creates a critical problem—how to ensure that time-sensitive industrial traffic, such as SCADA and control system communication, is not impacted by heavy IT data flows. This is where advanced Ethernet features like frame preemption come into play, particularly on industrial-grade switches such as the Cisco Industrial Ethernet 3500 Series.

In a conventional Ethernet network, once a device starts transmitting a frame, it must complete the transmission before another frame can be sent. This becomes a bottleneck when large packets—such as video streams, file transfers, or backup data—occupy the link. During this time, even the most critical SCADA or PLC communication must wait, introducing latency and unpredictability into the system. Traditional Quality of Service (QoS) mechanisms can prioritize traffic in queues, but they cannot interrupt a frame that is already in transmission. This limitation is significant in OT environments where even microseconds of delay can affect control system performance.

Frame preemption, based on standards like IEEE 802.1Qbu and 802.3br, fundamentally changes this behavior. With this feature enabled, the network switch can interrupt the transmission of a large, low-priority Ethernet frame mid-way and immediately transmit a smaller, high-priority frame, such as SCADA traffic. Once the critical packet has been transmitted, the switch resumes the interrupted frame from where it left off. This ensures that high-priority traffic does not get stuck waiting behind large packets, effectively eliminating serialization delay for critical communications.

The impact of this capability in OT networks is substantial. It enables near real-time responsiveness without requiring complete physical separation of networks. Industries can now run mixed traffic—combining enterprise IT data and industrial control traffic—on the same infrastructure while still maintaining deterministic performance for mission-critical operations. This is particularly valuable in sectors like manufacturing, oil and gas, and utilities, where delays in control signals can lead to production losses, safety risks, or system instability.

Another key advantage is the improvement in network predictability. By minimizing latency variation and ensuring that critical packets are transmitted immediately, frame preemption supports consistent and reliable communication between PLCs, SCADA systems, and field devices. This aligns closely with the goals of Industry 4.0, where real-time data exchange and synchronized operations are essential.

In summary, frame preemption is not just an incremental improvement over QoS—it is a transformative capability that enables deterministic Ethernet in converged IT/OT networks. By allowing critical SCADA traffic to “cut through” larger packets, it ensures low latency, high reliability, and better overall network performance. For organizations looking to modernize their industrial networks without compromising on control system integrity, leveraging features like frame preemption on platforms such as the Cisco IE 3500 series is a significant step forward.

Jumbo Frames vs 1500 MTU in OT Networks: Efficiency, Performance, and Why It Matters

shivlu@mplsvpn.info (Shivlu Jain) — Thu, 23 Apr 2026 18:17:00 +0530

In most industrial networks, Ethernet continues to run on the default MTU of 1500 bytes. It’s reliable, widely supported, and sufficient for basic communication. But as manufacturing environments evolve—with vision systems, MES integrations, historians, and high-frequency sensor data—the limitations of this default start to surface. What looks like a minor network setting often becomes a bottleneck in performance, scalability, and even system stability.

At its core, MTU (Maximum Transmission Unit) defines how much data can be transmitted in a single Ethernet frame. With a 1500-byte MTU, any payload larger than this must be fragmented into multiple packets. Each packet carries its own headers—Ethernet, IP, and TCP/UDP—along with processing requirements such as checksum validation and interrupt handling. This creates additional overhead, both on the network and on the devices handling the data.

To understand the impact, consider a simple OT scenario. A vision inspection system generating a 9000-byte data block per image needs to send this to an industrial PC for processing. With a standard 1500 MTU, this data is split into roughly six packets. Each of these packets must be individually transmitted, processed, and reassembled. This means six times the headers, six interrupts, and six processing cycles. Now scale this to 1000 images per second, and the system is dealing with around 6000 packets per second.

With jumbo frames (typically around 9000 bytes MTU), the same payload can be transmitted as a single frame. The number of packets drops from six to one. In the same example, packet flow reduces from 6000 packets per second to just 1000. This reduction has a direct and measurable impact on system efficiency. Interrupts drop by nearly 80–85%, CPU utilization on edge devices and industrial PCs reduces significantly, and the overall system becomes more stable under load.

From a bandwidth perspective, the improvement is equally compelling. Each Ethernet packet carries approximately 78 bytes of overhead when you account for headers and framing. With a 1500-byte MTU, this results in about 95% efficiency. Jumbo frames increase this efficiency to over 99%. While a ~4% gain may sound small, in a 1 Gbps network this translates to roughly 40 Mbps of additional usable bandwidth. On a 10 Gbps backbone, that becomes a 400 Mbps gain—without any infrastructure upgrade.

Latency and jitter also improve. In OT environments, determinism matters as much as speed. Multiple small packets introduce queuing delays and variability in packet arrival times. Fewer, larger frames reduce congestion points and improve flow consistency. This is particularly relevant when systems interact with time-sensitive applications or when large volumes of data are continuously streamed for analytics.

However, jumbo frames are not a plug-and-play solution. They require end-to-end compatibility. Every device in the network path—switches, routers, network interface cards—must support and be configured for the same MTU size. Any mismatch can result in fragmentation or dropped packets, often degrading performance instead of improving it. This is why careful network design and validation are essential before implementation.

Industrial networking platforms like IE 3500 from companies like Cisco Systems are designed to handle such requirements. With support for configurable MTU sizes, high-performance buffering, and reliable traffic handling across IT and OT layers, these solutions enable manufacturers to adopt jumbo frames without compromising network stability. This becomes especially important in converged environments where enterprise applications and shopfloor systems share the same infrastructure.

In practical terms, jumbo frames are most beneficial in use cases involving large data transfers—vision systems, MES-to-historian communication, backup operations, and analytics pipelines. For control-level traffic such as PLC communication or SCADA polling, where packet sizes are small and timing behavior is tightly controlled, the benefits are less pronounced and standard MTU often remains sufficient.

The broader takeaway is that 1500-byte MTU is a legacy default, not an optimized setting for modern manufacturing. As plants become more connected and data-driven, network efficiency becomes a critical lever for performance. Jumbo frames, when implemented correctly, offer measurable gains in bandwidth utilization, processing efficiency, and system stability. They don’t just make networks faster—they make them more scalable and resilient, which is exactly what smart factories demand.

Time Synchronization in Smart Factories: A Practical Guide for Indian Manufacturing

shivlu@mplsvpn.info (Shivlu Jain) — Tue, 21 Apr 2026 10:03:00 +0530

A few weeks ago, I came across a situation in a manufacturing setup where the same production batch showed different timestamps across systems. The production team recorded completion at one time, while QC logs showed testing had already begun earlier. Dispatch records added another variation. Everything seemed to be working fine individually, but collectively the data didn’t make sense. The issue wasn’t with machines or people—it was with time synchronization.

In today’s connected factories, every system—MES, ERP, QC, dispatch—relies on timestamps to create traceability and enable decision-making. If these systems are not aligned to a common clock, even accurate data becomes unreliable. This is where time synchronization becomes a foundational layer of smart manufacturing, though it is often overlooked.

Most manufacturing environments rely on NTP RFC 5905, which synchronizes systems over standard networks with millisecond-level accuracy. For industries like chemicals, adhesives, and general manufacturing, this level of precision is usually sufficient. It ensures that production logs, inventory updates, and dispatch records remain consistent across systems.

However, as manufacturing becomes more automated, the requirement changes. In high-speed environments such as automotive or advanced assembly lines, machines don’t just record events—they act in coordination. In such cases, even a few milliseconds of delay can cause inefficiencies or errors. This is where IEEE 1588 becomes critical, enabling synchronization at microsecond-level precision and ensuring machines operate in perfect alignment.

The challenge in many Indian manufacturing plants is not the lack of technology, but the lack of a unified time architecture. Different systems often run on different clocks, leading to inconsistencies in data and making root cause analysis difficult. Over time, this impacts productivity, quality control, and overall operational visibility.

This is where companies like Cisco Systems play a key role. By enabling reliable time distribution across both IT and OT networks and supporting protocols like NTP and PTP within industrial infrastructure, they help ensure that all systems—from enterprise applications to shopfloor machines—operate on a synchronized timeline. This alignment directly translates into better traceability, improved decision-making, and reduced downtime.

As manufacturing in India continues its transition toward Industry 4.0, time synchronization should not be seen as just an IT configuration. It is a strategic enabler of operational efficiency. When systems share the same sense of time, data becomes trustworthy—and when data is trustworthy, decisions become faster and more accurate.

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