Segment Routing (SR-MPLS) Fundamentals

Key Takeaways

• Segment Routing encodes a path as an ordered list of instructions — segments — directly in the packet at the source, instead of relying on hop-by-hop label distribution protocols like LDP or complex per-flow state like RSVP-TE.
• Each segment is identified by a SID (Segment ID), a 20-bit value that maps directly onto an MPLS label — SR-MPLS reuses the existing MPLS dataplane, so any MPLS-capable forwarding hardware can run it.
• The two segment types that matter for basic reachability are the Prefix-SID (a path to a specific destination prefix/node, honoring ECMP) and the Adjacency-SID (a specific link to a specific neighbor, used for explicit steering).
• SIDs are distributed domain-wide by the IGP itself (ISIS-SR or OSPF-SR extensions) — no separate label-distribution protocol like LDP is needed for basic reachability.
• Transit routers carry no per-flow or per-path state — they just swap the top label and forward, exactly like traditional MPLS. All the path intelligence lives at the source, in the segment list.

Prerequisites

Basic familiarity with MPLS label switching (label swapping, penultimate-hop popping) and IGP operation (ISIS or OSPF). This article underpins the data-plane transport used in EVPN Multi-Homing over SR-MPLS — read this first if the SR-MPLS references there weren't already familiar.

The Problem Segment Routing Solves

Traditional MPLS networks reach label-switched forwarding one of two ways: LDP, which distributes labels hop-by-hop for shortest-path reachability but has no traffic-engineering capability, or RSVP-TE, which supports explicit traffic-engineered paths but requires every router along the path to signal and maintain per-tunnel state — a real operational burden at scale, and a protocol (RSVP) that has to run and stay synchronized on every node.

Segment Routing removes both problems at once. Reachability comes for free from the IGP already running in the network (no separate LDP session to maintain), and traffic engineering doesn't require any per-flow state on transit routers — the source encodes the explicit path as a label stack, and every router in between just does ordinary label switching.

Segment IDs (SIDs)

A SID is a flat, unsigned integer that identifies a segment — and every SID maps to an MPLS label in the dataplane. There are two kinds that matter for a basic SR-MPLS deployment:

Prefix-SID (Node-SID): bound to an IP prefix, almost always a router's loopback. It's globally significant across the SR domain and represents "forward this along the IGP shortest path to this destination" — which also means it naturally supports ECMP, since the IGP's own shortest-path/multipath calculation still applies underneath it.

Adjacency-SID: bound to one specific link to one specific neighbor. It's only locally significant to the router that owns it, and using one in a segment list forces traffic out that exact interface — this is the primitive that makes explicit, engineered paths possible: a segment list of [Prefix-SID to router C, Adjacency-SID for router C's specific link to router D] forces traffic to take a specific link that the shortest path alone wouldn't have chosen.

SRGB: Turning a SID Into a Label

The Segment Routing Global Block (SRGB) is the range of MPLS labels reserved on a router for Prefix-SIDs — commonly 16000–23999 by default on IOS-XR. A Prefix-SID is normally configured as an index, and the actual local label is computed as:

local label = SRGB lower bound + SID index

So a loopback configured with prefix-sid index 100 gets local label 16100 if the SRGB starts at 16000. For this to work consistently across the network, every router in the domain needs to be configured with the same SRGB range — a mismatch doesn't break connectivity outright (each router still swaps to whatever label it locally believes maps to that SID), but it does defeat the "same SID means the same thing everywhere" property that makes SR simple to reason about, so keeping the SRGB identical fleet-wide is standard practice.

Adjacency-SIDs, by contrast, are usually allocated dynamically from a separate local label range and don't need to be predictable network-wide, since they're only ever used by the router that owns them.

IGP Distribution

ISIS-SR and OSPF-SR are IGP extensions — not a new protocol — that carry SIDs as additional TLVs inside the IGP's existing link-state advertisements. Every router in the domain learns every other router's Prefix-SID the same way it already learns everything else about the topology, and computes the corresponding label automatically. This is the core operational win over LDP: one control-plane protocol, not two.

Segment Lists and Source Routing

A segment list is just a label stack, pushed by the ingress router, where each label corresponds to one segment in order. A single-label stack containing only a destination's Prefix-SID behaves exactly like shortest-path IGP forwarding — most SR-MPLS traffic in a network is this simple case. A multi-label stack — say, a Prefix-SID to get to a general area of the network followed by one or more Adjacency-SIDs to force specific links — is how explicit, traffic-engineered paths get built without RSVP-TE or per-flow state anywhere except the ingress router that pushed the stack.

Configuration (Cisco IOS-XR)

Enable segment routing under the IGP and define the SRGB:

router isis 1
 segment-routing mpls
 segment-routing global-block 16000 23999
 interface Loopback0
  address-family ipv4 unicast
   prefix-sid index 100

Verification

show isis segment-routing label table

Confirms the local label allocated for each configured Prefix-SID, and that it matches SRGB base + index as expected.

show mpls forwarding

Shows the actual forwarding entries — confirm the label for a remote node's Prefix-SID is what you expect given its configured index and its SRGB.

show isis database verbose

Confirms SIDs are actually being advertised and received correctly across the domain, useful when two routers disagree about a label that should be consistent.

Troubleshooting

• A remote Prefix-SID resolves to an unexpected label: almost always an SRGB mismatch between routers — confirm every node in the domain is configured with the same segment-routing global-block range.
• SID collision: two different prefixes configured with the same SID index will cause one to silently fail to install correctly — keep a documented index-allocation scheme (e.g., index = last octet of the loopback) rather than assigning indexes ad hoc.
• Missing Prefix-SID on a loopback: if segment-routing mpls is enabled under the IGP but a specific loopback has no prefix-sid index configured, that node simply won't be reachable via SR — it'll still work over plain IGP/IP forwarding, but nothing arrives with an SR label for it.

Related Articles

EVPN Multi-Homing over SR-MPLS — the EVPN service templates in that article assume the SR-MPLS data plane described here is already up and forwarding; this article is the background for the "SR-MPLS is used as the dataplane transport" line in its Data Plane section.