The Packet Path With Partha

10/09/2026

Day 3 of the 22-day SR-MPLS Learning Journey is live 🎥

How does a router actually learn another router's SRGB, or its Prefix-SID index?

Day 2 gave us the arithmetic — SRGB base plus SID index equals the label. But that only works if the information reaches every router in the domain. So how does it travel?

The answer is more elegant than you'd expect: neither IS-IS nor OSPF needed a redesign. A small new sub-TLV simply rides inside a TLV or LSA the IGP was already flooding.

On the IS-IS side:
• Router Capability TLV 242 carries the SR Capability sub-TLV 2 (the SRGB)
• Extended IP Reachability TLV 135 carries the Prefix-SID sub-TLV 3
• Extended IS Reachability TLV 22 carries the Adjacency-SID sub-TLV 31

On the OSPF side, the same three facts travel in new Opaque LSAs — Extended Prefix (type 7) and Extended Link (type 8).

The part that makes it work in real networks: a router that doesn't understand these sub-TLVs simply ignores them and keeps forwarding normally. That's what let Segment Routing be introduced into live networks without a flag day.

12 minutes, full lesson 👇
https://youtu.be/FA196yiaYzo

🔔 Subscribe on YouTube for a new lesson every day:
https://www.youtube.com/

👍 Like this page for daily lesson summaries:
https://www.facebook.com/ThePacketPathWithPartha

📺 Full 22-day playlist:
https://www.youtube.com/playlist?list=PLYQHPRJxy5xk

04/09/2026

Day 2 of the 22-day SR-MPLS Learning Journey is live 🎥

Where do MPLS label values actually come from in Segment Routing?

Under LDP, every router picks its own label for the same destination. Router A says 3001, Router B says 7412 — and neither is wrong. The number is a private agreement between two neighbours. It means nothing one hop away.

That's why labels change at every hop, why you can't predict a value from a topology diagram, and why troubleshooting means logging into each router in turn.

Segment Routing replaces all of that with arithmetic.

Every router reserves the same label range — the Segment Routing Global Block, usually 16000 to 23999. The IGP then advertises an INDEX, not a label:

label = SRGB base + SID index
16000 + 2 = 16002

The part most people get wrong: the index is global, the label is local. The index is flooded once and means the same thing everywhere. The label is computed by each node from its own reserved base.

In this session I walk a packet across PE1 → P1 → P2 → PE2 where P2 uses a different SRGB base on purpose — and show why forwarding still works perfectly. That single example is what makes the model click.

12 minutes. Full lesson here 👇
https://youtu.be/1CZ7QkoUPV0

Day 1 (Why Segment Routing?):
https://www.youtube.com/watch?v=eDqwu6q8Vrc

Whole series:
https://www.youtube.com/playlist?list=PLYQHPRJxy5xk

03/09/2026

03/09/2026

🚀 SR-MPLS Learning Journey — Day 1 of 22

🎯 Why Segment Routing?

Why was Segment Routing introduced, and what problems does it solve? In Day 1, we explore the motivation behind SR-MPLS and how it simplifies traffic engineering and network operations compared with traditional MPLS approaches.

Follow The Packet Path With Partha for all 22 lessons.

Also watch on YouTube: https://youtu.be/eDqwu6q8Vrc

12/07/2026

📢 FREE Cisco Command Cheat Sheet for Network Engineers! 🚀

I've created a professional Cisco Command Cheat Sheet that brings together the most commonly used Cisco IOS commands into one easy-to-follow visual reference.

It includes commands for:
🔹 Router Configuration
🔹 Static Routing
🔹 RIP & OSPF
🔹 Switch Configuration
🔹 SSH
🔹 VLANs
🔹 Port Security
🔹 Trunking
🔹 VTP
🔹 STP
🔹 EtherChannel
🔹 CDP
🔹 Verification & Troubleshooting
🔹 Configuration Best Practices

Whether you're:
👨‍🎓 Learning CCNA
👨‍💻 Preparing for CCNP
👨‍🔧 Working as a Network Engineer
📚 Teaching networking

I hope this poster becomes a useful desk-side reference for your daily work and studies.

If you find it helpful, please Like 👍, Share 🔄, and Follow The Packet Path With Partha for more networking labs, cheat sheets, and Service Provider learning content.

Happy Learning! 🌐💙

02/07/2026

🚀 Excited to share one of my latest technical learning projects!

📘 **SR-MPLS L3VPN – Complete Lab: Configuration, Verification & Learning Outcomes (Cisco IOS-XR 6.3.1)**

Over the past few weeks, I have been working on designing and documenting a complete **Service Provider SR-MPLS L3VPN lab**. Rather than creating only a working configuration, my objective was to build a comprehensive engineering reference that combines **design, deployment, verification, troubleshooting, and learning outcomes** into a single visual guide.

This project covers:

🔹 End-to-end **SR-MPLS L3VPN** architecture
🔹 OSPF underlay with **Segment Routing (SR-MPLS)**
🔹 MP-BGP VPNv4 overlay for L3VPN services
🔹 PE–P–P–PE service provider topology
🔹 VRF design (Accounting & HR) with Route Targets and Route Distinguishers
🔹 Prefix-SID allocation and SRGB planning
🔹 MPLS label stack analysis and packet forwarding behavior
🔹 Device inventory and complete IP addressing plan
🔹 Configuration summaries for each router
🔹 Verification using operational commands and CLI outputs
🔹 End-to-end connectivity validation
🔹 Troubleshooting matrix and operational best practices
🔹 Interview preparation notes and key learning outcomes

💡 The goal was to produce a **Cisco Live / Service Provider–style engineering poster** that allows engineers to understand not only *how* to configure SR-MPLS L3VPN, but also *why* each protocol and design choice is important.

This project has further strengthened my understanding of:

✅ Segment Routing (SR-MPLS)
✅ MPLS forwarding and label operations
✅ MP-BGP VPNv4
✅ Service Provider VPN architecture
✅ Control Plane vs Data Plane interactions
✅ Network verification and troubleshooting methodology

I'm continuously expanding this series toward more advanced Service Provider technologies, including:

➡️ SR Policy (Traffic Engineering)
➡️ TI-LFA Fast Reroute
➡️ EVPN over SR-MPLS
➡️ SRv6
➡️ IS-IS based Segment Routing
➡️ Network Automation with Python & Ansible

I would love to hear your feedback and discuss best practices with fellow network engineers and architects.

18/05/2026

SR-MPLS Technical Analysis: Part-6
Dynamic Path Computation and Resilience
1. Dynamic vs. Explicit Path Logic
SR-TE policies can be defined using two primary methods:
•Explicit Paths: The operator manually specifies a SID-list (Segment List). This provides absolute control but lacks automatic adaptability to topology changes.
•Dynamic Paths: The router (Head-end/PCC) automatically calculates the path based on constraints (e.g., metric type: IGP, TE, or Delay).

2. Operational Resiliency
A major advantage of dynamic paths is their "self-healing" nature.
•Automatic Re-computation: If a link in the active path fails, the SR-TE process immediately detects the change in the TE Topology Database and re-calculates a new optimal path.
•Policy States:
◦Admin Up / Operational Up: Policy is configured and a valid path exists.
◦Operational Down: Occurs when no valid path can be found that satisfies the constraints (e.g., all paths to the endpoint are severed).

3. Verification Toolkit
•show mpls traffic-eng topology: Displays the link-state database used for path computation.
•show segment-routing traffic-eng policy: Shows the operational status, Binding SID (BSID), and the calculated label stack.
•show segment-routing traffic-eng pcc lsp: Provides a detailed view from the Path Computation Client (PCC) perspective.

Centralized Control with SR-PCE and TE Metrics
1. The Role of the TE Metric
While IGP metrics are used for general reachability, the TE Metric allows operators to influence traffic paths specifically for engineering purposes without affecting standard routing.
•Granular Control: By assigning higher TE metrics to specific links, you can steer SR-TE traffic away from them while standard IGP traffic continues to follow the shortest path.

2. Centralized Computation via SR-PCE
A centralized Path Computation Element (SR-PCE) offloads the math from individual routers and provides a global network view.
•PCEP Sessions: The communication protocol between the PCC (router) and PCE (controller). Verified via show mpls traffic-eng pce peer.
•Dynamic Adaptation: As TE metrics are modified across the network, the PCE dynamically recalculates the SID-lists for all affected policies and pushes the updates to the head-end routers in real-time.

3. Binding SID (BSID) Mapping
The BSID acts as a "pointer" to the SR-TE policy. In the forwarding plane (show mpls forwarding labels), the BSID is mapped to the specific label stack (sequence of SIDs) calculated by the PCE.

12/05/2026

Advanced SR-TE Constraints and Reliability
1. Dynamic Path Computation Objectives
SR-TE allows for path optimization based on multiple metrics, moving beyond simple IGP costs:
•IGP Metric: Traditional shortest path.
•TE Metric: Custom costs for traffic engineering.
•Delay: Real-time latency measurements (distributed via IGP).
•Min-Metric with Margin: Allows for path flexibility and ECMP utilization by accepting paths slightly above the absolute minimum cost.

2. Path Constraints and Disjointness
For high-availability services, SR-TE supports complex constraints:
•Affinity (Link Coloring): Including or excluding links based on administrative "colors."
•Disjointness (Node/Link/SRLG): Computing two paths that share no common nodes, links, or Shared Risk Link Groups (SRLG). This is the foundation for robust backup paths.
•Metric Bounds: Setting absolute limits on cumulative delay or SID-list depth.

3. Automated Steering Mechanisms
•On-Demand Next-hop (ODN): Automatically instantiates an SR policy when a BGP prefix with a specific color community is learned.
•Automated Steering (AS): Maps traffic to policies based on the BGP next-hop and color attribute.

Topology Visibility and BGP-LS
1. The SR-TE Database (TE-DB)
For any traffic engineering (local or centralized) to work, the system must have a comprehensive view of the network. This is achieved by "feeding" the IGP-learned topology into the SR-TE database.
•The "Magic" Command: distribute link-state under the IGP process.
•Components: Nodes, links, prefixes, and SR-specific attributes (SIDs, SRLGs, Latency).

2. BGP-LS (Link-State) Export
BGP-LS acts as the bridge between the network's internal IGP and an external controller (PCE).
•Function: Exports the contents of the SR-TE database to a centralized PCE.
•Benefit: Provides the PCE with a global, multi-domain view of the network, enabling sophisticated path computation that spans beyond a single IGP area or level.

3. Explicit Policy Configuration
The manual definition of a path using a SID-list:
•SID-list: An ordered list of MPLS labels (SIDs) representing the path.
•Policy: A combination of Color and Endpoint, with one or more Candidate Paths.
•Binding SID (BSID): A local label that, when pushed, steers traffic into the policy.

10/05/2026

SR-MPLS Technical Analysis: Part-4
Segment Routing Traffic Engineering (SR-TE) Fundamentals
1. The SR-TE Philosophy
SR-TE evolves traditional traffic engineering by removing state from the core and placing it in the packet header.
•Stateless Core: Transit routers do not maintain per-flow state; they simply execute the segment instructions in the header.
•SR Policy: Replaces traditional tunnel interfaces. Identified by the triplet: (Head-end, Color, End-point).
•BGP Prefix-SID: Enables inter-domain SR-TE by carrying SID information as a BGP attribute, allowing head-ends to build paths across multiple routing domains.

SR Policy, Candidate Paths, and Steering Logic
1. Steering with "Color"
"Color" is a numerical value representing a specific intent or SLA (e.g., Low Latency = Color 100, High Bandwidth = Color 200).
•Intent Mapping: Traffic is steered into an SR Policy based on its destination and associated color.
•Policy Uniqueness: Only one SR Policy with a specific color can exist between a given head-end and end-point.

2. Candidate Paths (Cpaths)
A policy can have multiple candidate paths, but only the one with the highest preference and validity is selected.
•Dynamic Paths: Computed by the head-end or PCE based on constraints (IGP metric, TE metric).
•Explicit Paths: Manually defined SID-lists.
•Binding-SID (BSID): An anchor SID; traffic sent to the BSID is automatically steered into the policy's SID-list.

Centralized Control with SR-PCE and PCEP
1. The Role of SR-PCE
While head-ends can compute paths locally, a centralized Path Computation Element (SR-PCE) provides a global view of the network.
•PCEP (Path Computation Element Protocol): The communication protocol between the PCC (router) and the PCE (controller).
•Stateful PCE: Maintains a database of all active paths, allowing for global optimizations like disjoint path computation for high availability.

2. Path Selection and Preferences
Head-ends can receive candidate paths from multiple sources, each with a default preference:
•BGP: 150
•PCEP: 120
•CLI/Local: 50
•Note: The path with the highest preference is selected for the active forwarding plane.

09/05/2026

SR-MPLS Technical Analysis: Part-3

Lab Architecture and Topology Design

1. Hierarchical Service Provider Model
A robust SR-MPLS lab environment requires a clear distinction between network layers:
•Core (P-Routers): Full-mesh backbone to test ECMP and path redundancy.
•Edge (PE-Routers): Interface between the core and customer sites.
•Customer Edge (CE-Routers): Multi-homed for testing redundancy.
•Centralized Control: Integration of SR-PCE (Path Computation Element) for explicit path steering.

2. Foundational Components
•IOS-XRv (7.1.1): The platform of choice for robust SR-MPLS support.
•IS-IS as the Underlay: Selected for its extensibility via TLVs.
•MPLS OAM: Critical for SID-aware connectivity checks (LSP Ping/Traceroute).

IS-IS Prerequisites and Underlay Reachability
1. IS-IS Configuration for SR-MPLS
Before "turning on" SR, the IGP must be correctly configured:
•Metric Style Wide: Essential for carrying the sub-TLVs needed for SIDs.
•Passive Loopbacks: Advertise loopback prefixes without sending hellos.
•Point-to-Point Interfaces: Optimize adjacency formation on physical links.

2. Underlay Verification
•Ping/Traceroute: Ensure IP reachability between all loopbacks.
•IS-IS Database: Verify prefix distribution across the domain.
•Note: At this stage, MPLS forwarding tables will be empty as SR is not yet enabled.

Activating SR-MPLS and Label Verification
1. The Three-Step Activation
1Define SRGB: Reserve the label range (e.g., global-block 16000 17000).
2Enable SR in IS-IS: Activate under the address family (segment-routing mpls).
3Assign Prefix-SIDs: Assign an index to the loopback interface (e.g., prefix-sid index 1).

2. Verification Commands
Command Purpose
show isis segment-routing label table Maps prefixes to SID indices and labels.
show isis segment-routing prefix-sid-map View all prefix-to-SID mappings in the domain.
show mpls forwarding Confirm SR labels are programmed in the data plane.
show segment-routing mpls gb Verify the active SRGB range.