Segment routing arrived with a traffic engineering story attached, and for most enterprises that is the least interesting thing about it. What an enterprise core actually gets is the removal of a protocol. Labels stop being distributed by a separate process with its own neighbours, its own sessions and its own failure modes, and start being carried by the routing protocol that was already running.
That is a smaller change than it sounds and a larger improvement than it sounds. Nothing about forwarding changes — packets still carry a label stack and routers still swap and pop. What changes is where the labels came from, and with it an entire category of faults where the routing protocol was healthy and the label path was not, because there is no longer a separate thing to be unhealthy.
This article covers what the technology actually solves for an enterprise, the two segment types and which one is used for what, where label values come from and why the global block should be identical everywhere, how this coexists with an existing label distribution deployment during a migration, and what it changes about day-to-day troubleshooting. It is written for the lab rather than for the written exam, and sits alongside the rest of the CCIE Enterprise Infrastructure lab certification track.
A prefix segment identifier is advertised as an index and turned into a label by adding the local global block base, so identical blocks across the network produce identical labels for the same destination everywhere.What Does Segment Routing Solve for an Enterprise?
What is the actual benefit?
Removing a protocol. Labels are advertised as attributes of prefixes the routing protocol is already carrying, so there is no separate label distribution process, no sessions to establish, no transport addresses to be reachable, and no possibility of a healthy routing protocol sitting above a broken label path. The traffic engineering capability is real and is a second-order benefit for most enterprises. The first-order benefit is that an entire class of quiet failures no longer exists.
A Deeper Dive into the Case for It
What gets deleted
A neighbour discovery mechanism. A session per adjacency. A transport address that must be routable before the session can form. A binding table holding labels from every neighbour. A synchronisation feature to stop the routing protocol using a link before labels exist on it. And a protection feature to keep sessions alive across link flaps.
All of that exists to solve problems created by having a second protocol. Carrying the label information inside the routing protocol removes the problems and the solutions together, and the operational simplification is larger than the feature list suggests because each of those items also had its own monitoring, its own documentation and its own troubleshooting procedure.
The label that is the same everywhere
Under the older arrangement each router assigns its own label to each prefix, so one destination has as many different labels as there are routers. A capture taken at one hop cannot be compared with a capture taken at another without translating.
Under segment routing the label is derived from a locally configured base plus an index advertised by the routing protocol. Make the base the same on every router — which costs nothing and is the default in most deployments — and the label for a destination is a single number network-wide. A packet seen anywhere can be attributed to a destination immediately, without inspecting any router's tables.
This is the point at which the technology stops being an architectural preference and starts being an operational one. Anyone who has traced a label path across five hops under the old arrangement recognises the size of the difference.
Protection that actually covers the topology
The older fast-reroute mechanisms depend on a neighbour that happens to have a loop-free path to the destination, and in many real topologies — rings especially — no such neighbour exists for some destinations. Coverage is therefore partial and topology dependent, and calculating which destinations are protected is an exercise nobody enjoys.
Segment routing removes the dependency by allowing the repair path to be expressed as a stack of segments rather than as a single next hop. The repair can be sent along a path no single neighbour could have provided, which gives full coverage regardless of topology. For an enterprise core built as a ring — which many are, for cost reasons — this is the difference between partial protection and complete protection.
What does not change
Forwarding. Packets carry a label stack, routers swap and pop, penultimate hop popping works as before, and the hardware path is the same one. Services layered on top are unaffected: a virtual private network carried over the core does not know or care how the transport label was learned.
That continuity is what makes migration feasible. The thing being replaced is the control plane's label distribution, not the data plane, so a network can run both mechanisms simultaneously and move destinations across gradually.
| Concern | With LDP | With segment routing |
|---|---|---|
| Protocols to run in the core | Two | One |
| Label for one destination | Different at every hop | One number, everywhere |
| IGP healthy, labels broken | The characteristic fault | Not possible |
| Fast reroute coverage | Topology dependent | Complete |
| State held per path in the core | Per prefix | Per prefix, from the IGP |
| Traffic engineering | Requires a further protocol | A segment stack |
What Are the Segment Types, and Which One Is Used?
How many are there?
Two that matter. A prefix segment identifies a destination and means "take the shortest path to this prefix"; it is understood identically by every router because it is advertised network-wide. An adjacency segment identifies one specific link on one specific router and means "leave by this link"; it is meaningful only on the router that allocated it. Ordinary forwarding uses a single prefix segment and nothing else. Adjacency segments appear when a path must deviate from the shortest one.
A Deeper Dive into the Segment Types
The prefix segment, which does most of the work
Assigned to a prefix — in practice a router's loopback — and advertised by the routing protocol to everyone. Every router computes the same forwarding behaviour for it: send toward that prefix by the shortest path. The label is swapped unchanged at each hop because the instruction has not changed, and it is popped at the penultimate hop as usual.
A prefix segment assigned to a loopback that identifies a single node is often called a node segment, and the distinction is a flag in the advertisement rather than a different mechanism. For an enterprise assigning one identifier per router loopback, every prefix segment in the network is a node segment and the distinction never arises in practice.
The adjacency segment, which is local
Allocated automatically for each adjacency and advertised so that others know it exists, but meaningful only on the router that allocated it. A packet carrying it must have arrived at that specific router, which is why it is always used as part of a stack rather than on its own — a prefix segment to get to the router, then the adjacency segment to leave by a chosen link.
Because they are allocated dynamically, adjacency segment values change when an adjacency is rebuilt. Anything referring to a specific value has to tolerate that, which in practice means adjacency segments are used by systems that compute paths rather than by configuration written by hand.
! What this router allocated, and what it learned
P1# show segment-routing mpls connected-prefix-sid-map ipv4
PREFIX SID RANGE FLAGS
10.255.0.1/32 1 1
!
P1# show ip ospf segment-routing sid-database
SID Prefix Adv-Rtr-Id Source
1 10.255.0.1/32 10.255.0.1 Connected
2 10.255.0.2/32 10.255.0.2 Remote
5 10.255.0.5/32 10.255.0.5 Remote
A path is a stack, and usually a stack of one
Expressing a path as a list of segments is the whole idea, and the common case is a list with one entry: go to the destination by the shortest path. Only when the path must differ from the shortest one does the stack grow, and then it grows by the minimum needed — typically two or three entries expressing "go here, then take this link, then continue normally".
This matters for hardware. Every platform has a limit on how many labels it can impose, and a design that requires deep stacks may exceed it on the older equipment in the estate. For ordinary enterprise forwarding the question never arises, because the stack is one label deep.
Configuring it, which is shorter than expected
Three things. Enable the feature and declare the global block. Map each loopback to an index. Enable it under the routing protocol. That is the whole core configuration, and it replaces everything that was previously needed for label distribution.
! Global: the block, and the index for this router's loopback
P1(config)# segment-routing mpls
P1(config-srmpls)# global-block 16000 23999
P1(config-srmpls)# connected-prefix-sid-map
P1(config-srmpls-conn)# address-family ipv4
P1(config-srmpls-conn-af)# 10.255.0.1/32 index 1 range 1
!
! And enable it in the IGP - this is what advertises the index
P1(config)# router ospf 1
P1(config-router)# segment-routing mpls
P1(config-router)# segment-routing area 0 mpls
! The IS-IS form, for a core running IS-IS instead
P1(config)# router isis CORE
P1(config-router)# segment-routing mpls
P1(config-router)# address-family ipv4 unicast
!
! Point-to-point on core links, as always
P1(config)# interface GigabitEthernet0/1
P1(config-if)# isis network point-to-point
Assigning indexes, which needs a plan
An index is a number and two routers must not use the same one. That sounds trivial and it is the most common operational mistake in a first deployment, because indexes are assigned per router by whoever configures that router and there is nothing stopping two people choosing the same value.
The plan that works is the boring one: a documented range per site or per role, allocated from a single list, with the router's index recorded alongside its loopback in the same document. Deriving the index arithmetically from the loopback's last octet is tempting and works until two sites reuse a last octet.
Where Do the Label Values Come From?
How is a label computed?
The routing protocol advertises an index, not a label. Each router adds its own configured base value to that index to get the label it will use. If every router uses the same base, every router computes the same label for the same destination and the value is consistent network-wide. If the bases differ, forwarding still works — each router computes correctly for its neighbour — and the operational benefit of a single consistent number is lost.
A Deeper Dive into Label Derivation
Why an index rather than a label
Advertising a label directly would require every router to have the same label space available, which cannot be assumed across different platforms and software versions. Advertising an index and letting each router map it into its own space removes that requirement, and the cost is one addition per prefix.
It also makes the block relocatable. A network that needs to move its range — because something else is using it, or because a platform limit requires it — changes a base value rather than every advertisement.
Why the base should be identical everywhere
Nothing requires it. Everything about operating the network benefits from it. With identical bases, a label seen in a capture, in a forwarding table, in a traffic engineering policy or in a support case names a destination unambiguously. With differing bases, every one of those requires knowing which router the observation came from and what its base is.
The default range is generally suitable and the correct decision in most enterprises is to leave it alone everywhere. Where it must be changed, change it everywhere at once and record why, because a network with two different bases in it will have them for years.
What the mapping looks like in practice
A router's loopback with index five, on a network with a base of sixteen thousand, has the label sixteen thousand and five everywhere. Every forwarding entry toward that loopback on every router shows the same incoming and outgoing label, which is visually obvious the first time it is seen and is the clearest demonstration of the difference from the older arrangement.
! The block in use, and how full it is
P1# show segment-routing mpls gb
Global block (SRGB): Start 16000, Range 8000
Status: Enabled
!
! And the same destination, from two different routers
P1# show mpls forwarding-table | include 10.255.0.5
16005 16005 10.255.0.5/32 4821062 Gi0/1 10.1.12.2
!
P2# show mpls forwarding-table | include 10.255.0.5
16005 Pop Label 10.255.0.5/32 4821062 Gi0/2 10.1.25.5
Sizing the block
One index per router loopback, so the block needs to be at least as large as the number of routers that will ever be in the network, with room for whatever else is given an identifier. The default range is large enough for most enterprises by a wide margin, and allocating a larger one for safety costs nothing because the space is not consumed until used.
The one real constraint is that platforms differ in the ranges they support and in how much of the label space is available. Confirming that the intended range is supported on every platform in the estate — including the oldest — belongs in the design phase rather than in the first deployment window.
What happens when the blocks differ
Forwarding works. Each router computes the outgoing label using the downstream neighbour's base rather than its own, so the packet is always labelled with something the next router understands. The mechanism handles the mismatch correctly and by design.
What is lost is the property this article argues is the main benefit. The label for a destination is now different at different points, captures cannot be compared directly, and the troubleshooting improvement disappears. It is a self-inflicted loss of the reason for deploying the technology, and it is easy to inflict during a phased rollout where the first site chose a base and the second chose another.
show segment-routing mpls gb across routers from different phases. Fix: align the bases, which requires a window because changing the base changes every label the router uses; and record the chosen range in the design document so the next phase inherits it.Verifying it end to end
The label path test works exactly as before and remains the conclusive check that a path exists. What changes is that its result is easier to interpret, because the label it reports is the one you expected to see rather than a value that has to be looked up. Reading this once is not the same as being able to do it under time pressure, which is what repetition against realistic CCIE lab practice scenarios is for.
! Same test as always, easier to read
P1# ping mpls ipv4 10.255.0.5/32
!
P1# traceroute mpls ipv4 10.255.0.5/32
!
! And the feature's own state view
P1# show segment-routing mpls state
P1# show segment-routing mpls mapping-server ipv4
| Question | Command | Answers |
|---|---|---|
| Is the feature enabled and healthy? | show segment-routing mpls state |
Overall state |
| What base is this router using? | show segment-routing mpls gb |
The value to align |
| Which indexes exist network-wide? | The IGP identifier database | Collisions, and who advertised what |
| What label is actually installed? | show mpls forwarding-table |
The forwarding entry in use |
| Does the path work? | ping mpls ipv4 |
End to end, conclusively |
How Does This Coexist With What Is Already Running?
Can both run at once?
Yes, and that is how a migration is done. A router can hold labels from both mechanisms for the same destination and is told which to prefer. Sections of the network that have been converted use segment routing between themselves; sections that have not continue as before; and a mapping function advertises identifiers on behalf of routers that cannot advertise their own, so that a converted router can still reach an unconverted one by label. The migration is incremental and reversible at every stage.
A Deeper Dive into Migration
Both mechanisms, one forwarding table
When both are active, a router may learn two labels for the same destination. A preference setting decides which is installed. Setting the preference to the new mechanism converts the router's forwarding without removing the old one, which means the change can be reversed by setting the preference back — a far more comfortable position than removing a protocol and hoping.
The practical migration runs in that order: enable the new mechanism everywhere while the old one still carries traffic, verify that the identifiers and labels are as intended, switch the preference, observe, and only then remove the old configuration. Each stage is independently reversible.
! Both active; choose which one installs
P1(config)# segment-routing mpls
P1(config-srmpls)# set-attributes
P1(config-srmpls-attr)# address-family ipv4
P1(config-srmpls-attr-af)# sr-label-preferred
!
! Confirm which mechanism supplied the installed entry
P1# show mpls forwarding-table 10.255.0.5 32 detail | include SR|LDP
The mapping function, for routers that cannot advertise
Some devices in an estate will not support the new mechanism, or will not be upgraded on the same schedule. Their prefixes have no index, so a converted router has no segment label for them and the two halves of the network cannot reach each other by label.
The mapping function solves this. A router is configured with the prefix-to-index mappings for those devices and advertises them on their behalf. The rest of the network then has identifiers for prefixes whose owners never advertised any, and label paths exist across the boundary. Two such routers should be configured for redundancy, with identical mappings.
! Advertise identifiers for prefixes that cannot advertise their own
P1(config)# segment-routing mpls
P1(config-srmpls)# mapping-server
P1(config-srmpls-ms)# prefix-sid-map
P1(config-srmpls-ms-map)# address-family ipv4
P1(config-srmpls-ms-map-af)# 10.255.0.20/32 index 20 range 8
!
! And tell the IGP to advertise what the mapping server holds
P1(config)# router ospf 1
P1(config-router)# segment-routing mpls
P1(config-router)# segment-routing prefix-sid-map advertise-local
!
P1# show segment-routing mpls mapping-server ipv4
The boundary, which is where the care goes
Between a converted region and an unconverted one, a router holds labels from both mechanisms and must stitch them together. That works, and it is the part of the migration where the verification effort belongs, because it is the only place where the two mechanisms interact rather than simply coexisting.
The specific check is that a label path exists in both directions across the boundary for destinations on both sides. Testing one direction, or testing only destinations inside the converted region, proves considerably less than it appears to.
Services above the core
A virtual private network or any other service carried over the core is indifferent to how the transport label was learned. It requires a label path between the edge routers, which segment routing provides exactly as the older mechanism did. No service configuration changes.
The one thing worth verifying is that the edge routers' loopbacks have identifiers and are advertised as host routes, for the same reason they always had to be: a summary removes the specific prefix, and a prefix with no advertisement has no identifier, and a destination with no identifier has no label path. The failure mode is identical to the older one and so is the fix.
Fast reroute, which is worth enabling at the same time
The protection mechanism that gives full topological coverage is a routing protocol feature that depends on segments being available. Enabling it during the same migration is sensible because the verification effort overlaps and because the protection is one of the main reasons for doing the work.
It should be enabled after the basic deployment is stable rather than at the same moment, so that a problem during the rollout has one candidate cause rather than two. That is a sequencing preference rather than a technical requirement.
! Full-coverage protection, once the base deployment is stable
P1(config)# router ospf 1
P1(config-router)# fast-reroute per-prefix enable area 0 prefix-priority low
P1(config-router)# fast-reroute per-prefix ti-lfa area 0
!
! Which destinations are protected, and by what repair path
P1# show ip ospf fast-reroute ti-lfa
P1# show ip route repair-paths 10.255.0.5
What Does This Change About Troubleshooting?
What is different?
The most common fault class disappears. There is no separate label distribution protocol, so there is no session to fail, no transport address to be unreachable and no possibility of a healthy routing protocol above a broken label plane. What replaces it is a smaller set of faults that are all about consistency: an index used twice, a base that differs between sites, and a prefix that has no identifier because it was summarised. The investigation starts from the identifier database rather than from a neighbour list.
A Deeper Dive into the New Procedure
Four questions, in order
Does this prefix have an identifier, and who advertised it? Is the index unique across the network? Is the base the same here as everywhere else? And is the resulting label installed in the forwarding table? Four commands, and between them they cover essentially every fault this technology has.
Compared with the older procedure — interface, discovery, session, binding, forwarding, path — this is shorter by two stages, and the two that were removed were the ones that produced the confusing failures.
! The four questions, in order
!
! 1. Does the prefix have an identifier at all?
P1# show ip ospf segment-routing sid-database | include 10.255.0.5
!
! 2. Is that index claimed by anything else?
P1# show ip ospf segment-routing sid-database | include " 5 "
!
! 3. Is the base the same as everywhere else?
P1# show segment-routing mpls gb
!
! 4. Is the label installed?
P1# show mpls forwarding-table 10.255.0.5 32
The summarised loopback, which survives the change
An identifier is attached to a prefix. Summarise the prefix away and the identifier goes with it, exactly as a label did under the older mechanism. This is the one significant failure that carries across unchanged, and it deserves the same treatment: edge loopbacks are advertised as host routes, whatever else is summarised.
The symptom is also unchanged — ordinary reachability fine, label path gone, every routing check passing. The diagnosis is quicker because the identifier database makes the absence explicit rather than requiring a binding table to be read.
Reading a capture, which is now worth doing
With a consistent base, a label observed anywhere identifies its destination by arithmetic. Subtract the base and look up the index. That single property makes packet capture a practical first-line tool on an MPLS core, which under the older arrangement it largely was not, because a label meant nothing without knowing which router had assigned it.
It also makes escalation easier. A label value in a support case or an incident note is now unambiguous, where previously it required the router and its tables to interpret.
What to monitor
Three things, none of which is expensive. The count of identifiers known network-wide, which should equal the number of routers and changes only when one is added or removed. The base value on every router, compared, which should never differ. And the count of installed label entries against the number of destinations, which detects a missing identifier before a service does.
The second of those is the one worth automating, because the failure it catches is silent, permanent and costs the main benefit of the deployment without producing any symptom at all.
! Three collections, per router, on a schedule
!
! Identifier count - should equal the router count
P1# show ip ospf segment-routing sid-database | count Prefix
!
! The base - this is the one that must never differ
P1# show segment-routing mpls gb | include Start
Global block (SRGB): Start 16000, Range 8000
!
! Installed label entries, against the destinations expected
P1# show mpls forwarding-table | count 16[0-9][0-9][0-9]
Where the traffic engineering complexity would come in
Everything in this article describes the shortest-path case, which is what an enterprise core needs. Steering traffic along a non-shortest path introduces policies, path computation and an additional set of identifiers, and with them a genuinely larger operational surface.
The advice is to deploy the shortest-path case first, operate it, and add steering only when there is a specific requirement that cannot be met otherwise. The base deployment delivers the protocol removal and the label consistency on its own, and those are the benefits most enterprises are actually buying.
Documenting the allocation
The index allocation is the one piece of state that exists outside the routers and must be maintained. A list of loopbacks, indexes and the resulting labels, kept with the addressing plan, is sufficient and is the thing whose absence causes the collision described earlier.
It should also record the base, once, prominently, so that the next site to be deployed inherits it rather than choosing. That single line in a document prevents the most expensive mistake available in this technology.
Blueprint framing
The CCIE Enterprise Infrastructure v1.1 blueprint covers segment routing within its transport technologies domain at a conceptual level. What is asked tends to be the mechanism — the difference between a prefix segment and an adjacency segment, how a label is derived from a global block and an index, and why no separate label distribution protocol is needed — rather than a full configuration.
| Symptom | Cause | First check |
|---|---|---|
| One destination has no label path | No identifier, or summarised | Identifier database |
| A router lost its label path when another was added | Index collision | The index, across the database |
| Labels differ between sites | Different global block bases | Compare the base everywhere |
| Converted region cannot reach unconverted | No mapping function | Identifier for the far loopback |
| Protection not covering some destinations | Fast reroute not enabled | The repair path view |
Conclusion
For an enterprise core the case for segment routing is not the traffic engineering it is usually sold on. It is that labels stop being distributed by a second protocol and start being attributes of prefixes the routing protocol already carries. A session that could fail, a transport address that had to be reachable, a synchronisation feature to stop traffic using a link before labels existed on it — all of that disappears along with the problems it existed to solve.
The second benefit is consistency, and it depends entirely on one decision. The routing protocol advertises an index and each router adds its own base to get a label, so identical bases produce a single label value per destination across the whole network. That turns a capture into something readable, an escalation into something unambiguous, and a label trace into arithmetic. Differing bases cost nothing in forwarding and cost all of that, which makes the base the most important value in the deployment and the easiest one for a phased rollout to get wrong.
What is left to go wrong is a short list. An index claimed by two routers, which produces a destination that is reachable by IP and not by label. A loopback summarised away, taking its identifier with it, which is the same failure the older mechanism had and has the same fix. And a boundary between converted and unconverted equipment that needs a mapping function to bridge it. All three are visible in a database the routing protocol maintains, which is the whole point — there is no longer a second place to look. More CCIE Enterprise Infrastructure material — labs, protocol breakdowns and study guides — is collected on the SPOTO CCIE site.
External Links
- RFC 8402 — Segment Routing Architecture
- RFC 8660 — Segment Routing with the MPLS Data Plane
- RFC 8665 — OSPF Extensions for Segment Routing
- RFC 8667 — IS-IS Extensions for Segment Routing
- RFC 8661 — Segment Routing MPLS Interworking with LDP
- RFC 3031 — Multiprotocol Label Switching Architecture
- Cisco Learning Network — CCIE Enterprise Infrastructure
Reference Notes
- RFC 8402 defines the segment routing architecture, in which a source encodes a path as an ordered list of segments carried in the packet.
- RFC 8402 defines the prefix segment as a global segment associated with a prefix, instructing forwarding along the shortest path to it, and the adjacency segment as a local segment associated with one link.
- RFC 8402 defines the Segment Routing Global Block as the range of labels reserved for global segments, and states that a prefix segment is advertised as an index into that block.
- RFC 8402 notes that using the same global block on every node results in the same label being used network-wide for a given prefix segment.
- RFC 8660 specifies segment routing with the MPLS data plane, in which the segment list is the MPLS label stack and forwarding operations are the existing push, swap and pop.
- RFC 8660 describes how a node computes the outgoing label for a prefix segment from the downstream neighbour's advertised global block, which allows different nodes to use different blocks.
- RFC 8665 specifies the OSPF extensions carrying segment routing information, including the prefix SID and the SR-Algorithm and SID/Label Range TLVs.
- RFC 8667 specifies the equivalent IS-IS extensions for carrying segment routing information.
- RFC 8661 specifies interworking between segment routing and LDP, including the Segment Routing Mapping Server that advertises prefix SIDs on behalf of nodes that do not support segment routing.
- RFC 3031 specifies the MPLS architecture, including the label stack and the label switching operations that segment routing reuses unchanged.
- Cisco documentation describes topology independent loop-free alternate protection, which uses a segment list to express a repair path and therefore provides coverage independent of topology.
- The CCIE Enterprise Infrastructure v1.1 unified exam topics include MPLS and segment routing within the transport technologies and virtualisation domain.