Hands-On Lab: Configuring Segment Routing with MPLS (SR-MPLS)

This hands-on lab configures Segment Routing over an OSPF-enabled network, assigning a global segment ID to each router's loopback and verifying traffic follows label-based forwarding without requiring LDP, contrasting SR against the traditional MPLS control plane.

Segment Routing ConfigurationPrefix-SID AssignmentLDP-Free Label Forwarding

~3 min read · Updated Sep 26, 2026

Lab Objective

Enable Segment Routing on an OSPF network, assign a unique Prefix-SID to each router's loopback address, verify segment IDs are advertised via OSPF extensions rather than a separate label distribution protocol, and confirm traffic forwards using SR labels end to end.

Lab Purpose

Traditional MPLS label distribution, not covered in depth in this series, typically requires a separate protocol like LDP running alongside the IGP purely to distribute labels. Segment Routing eliminates this entirely by piggybacking label information directly onto OSPF's own link-state advertisements, so no separate label distribution protocol is needed at all.

Lab Topology

R1 ---- R2 ---- R3

R1 Loopback0: 1.1.1.1/32
R2 Loopback0: 2.2.2.2/32
R3 Loopback0: 3.3.3.3/32

OSPF already running across all links,
area 0

Task 1: Enable Segment Routing for OSPF

Enable the Segment Routing MPLS feature within the OSPF process on all three routers.

Task 2: Assign a Prefix-SID to Each Router's Loopback

Configure a unique, globally significant Prefix-SID index for each router's loopback interface.

Task 3: Verify SR Is Advertised via OSPF

Confirm the OSPF database now carries segment routing information without any LDP configuration present.

Task 4: Verify the SR Label Forwarding Table

Examine R1's MPLS forwarding table and confirm labels derived from the configured Prefix-SIDs are populated.

Task 5: Verify End-to-End Label-Switched Connectivity

Confirm traffic from R1 to R3's loopback is forwarded using MPLS labels rather than plain IP lookups.

Solution and Verification

R1(config)# router ospf 1
R1(config-router)# segment-routing mpls

R2(config)# router ospf 1
R2(config-router)# segment-routing mpls

R3(config)# router ospf 1
R3(config-router)# segment-routing mpls

R1(config)# interface loopback0
R1(config-if)# ip address 1.1.1.1 255.255.255.255
R1(config-if)# ip ospf network point-to-point
R1(config)# segment-routing mpls
R1(config-sr-mpls)# connected-prefix-sid-map
R1(config-sr-mpls-conn)# address-family ipv4
R1(config-sr-mpls-conn-af)# 1.1.1.1/32 index 1

R2 configured similarly with index 2 for 2.2.2.2/32
R3 configured similarly with index 3 for 3.3.3.3/32

R1# show ip ospf database opaque-area | include SR|Segment

...
Extended Prefix Opaque LSA
  Prefix: 2.2.2.2/32, SID Index: 2
  Prefix: 3.3.3.3/32, SID Index: 3
-- OSPF's own extended LSAs carry the SID
-- information -- confirmed with no LDP
-- process running anywhere in this topology

R1# show mpls forwarding-table

Local  Outgoing   Prefix           Outgoing   Next Hop
Label  Label      or Tunnel Id     interface
16002  16002      2.2.2.2/32       Gi0/0      10.1.1.2
16003  16003      3.3.3.3/32       Gi0/0      10.1.1.2
-- Labels 16002 and 16003 derive directly
-- from the configured SID indices (16000
-- being the default SRGB base, plus the
-- index) -- no LDP session was ever needed
-- to populate this table

R1# traceroute mpls ipv4 3.3.3.3/32

Type escape sequence to abort.
Tracing MPLS Label Switched Path...
  0 10.1.1.1 MRU 1500 [Labels: 16003 Exp: 0]
L 1 10.1.1.2 MRU 1500 [Labels: implicit-null Exp: 0] 8 ms
L 2 10.2.2.2 8 ms
-- Confirms the path from R1 to R3's
-- loopback is genuinely label-switched
-- across the entire topology, using
-- exactly the labels derived from the
-- Prefix-SID assignments

Key Takeaway

Segment Routing's core simplification is architectural: rather than running a separate label distribution protocol (LDP) alongside the IGP, SR extends the IGP itself (OSPF or IS-IS) to carry label information directly within its existing link-state advertisements — eliminating an entire protocol and its associated adjacency/synchronization concerns while still achieving the same MPLS label-switched forwarding behavior end to end.

Written & researched by Dr. Shahin Siami

Related Articles

Hands-On Lab: Configuring EIGRP Stub Routing

This hands-on lab configures a branch router as an EIGRP stub, verifying it advertises only its own connected and summary routes while the hub router correctly avoids querying the stub during a topology change elsewhere in the network.

Continue

Hands-On Lab: Configuring EIGRP Named Mode

This hands-on lab reconfigures a classic EIGRP setup into EIGRP named mode, organizing address-family and interface-specific configuration into a more structured hierarchy, and verifies functional equivalence with the classic configuration style used throughout earlier EIGRP labs in this series.

Continue

Hands-On Lab: Configuring ERSPAN Across a Routed Network

This hands-on lab configures Encapsulated RSPAN (ERSPAN) to mirror traffic across a Layer 3-routed network rather than a single Layer 2 trunk, extending the RSPAN concept from the previous lab beyond the boundaries of a single VLAN or switched domain.

Continue

Hands-On Lab: Configuring RSPAN Across Switches

This hands-on lab configures Remote SPAN (RSPAN) using a dedicated RSPAN VLAN carried across a trunk, allowing traffic mirrored on one switch to be monitored by a capture device connected to an entirely different switch, extending the local SPAN concept covered in an earlier lab across the network.

Continue

Hands-On Lab: Configuring In-Service Software Upgrade (ISSU) on a Stack

This hands-on lab performs an In-Service Software Upgrade across a StackWise stack, upgrading each member's IOS image one at a time while the stack continues forwarding traffic throughout, verifying zero downtime compared to the disruptive reload approach used in earlier IOS upgrade labs.

Continue

Hands-On Lab: Configuring Cisco Catalyst StackWise Traditional Stacking

This hands-on lab configures traditional Catalyst stacking (StackWise) across three switches using stack cables, contrasting its single-tier, chassis-proximity requirement against the StackWise Virtual pair covered in the previous lab, which allows switches to be located much farther apart.

Continue