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 دقیقه مطالعه · آخرین به‌روزرسانی ۴ مهر ۱۴۰۵

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.

نوشته و پژوهش‌شده توسط دکتر شاهین صیامی

مقالات مرتبط

Hands-On Lab: Final Comprehensive CCNP Troubleshooting Challenge (BGP, DMVPN, and QoS Integration)

This hands-on lab presents a complex multi-layer failure across an integrated BGP-over-DMVPN topology combined with QoS marking, requiring systematic diagnosis of a route reflector misconfiguration, an NHRP registration failure, and an incorrectly applied QoS policy simultaneously affecting the same network.

ادامه

Hands-On Lab: Configuring BGP over DMVPN

This hands-on lab runs iBGP as the routing protocol across the same DMVPN hub-and-spoke topology used in the two previous labs, configuring the hub as a route reflector so spokes learn each other's routes without a full iBGP mesh, combining two previously separate concepts into one integrated design.

ادامه

Hands-On Lab: Configuring OSPF over DMVPN

This hands-on lab runs OSPF as the dynamic routing protocol across the same DMVPN hub-and-spoke topology, configuring the tunnel interface as an OSPF point-to-multipoint network type to correctly handle the hub-and-spoke adjacency pattern without requiring the broadcast network type's DR/BDR election.

ادامه

Hands-On Lab: Configuring EIGRP over DMVPN

This hands-on lab runs EIGRP as the dynamic routing protocol across the DMVPN hub-and-spoke topology built in earlier labs, verifying neighbor relationships form correctly across the multipoint tunnel and routes propagate without requiring per-spoke static configuration on the hub.

ادامه

Hands-On Lab: Configuring HSRP MD5 Authentication

This hands-on lab configures MD5 authentication on an HSRP group, verifying two routers with matching authentication strings form a normal active/standby relationship while a router with a mismatched string is excluded from the group entirely.

ادامه

Hands-On Lab: Configuring Cisco Umbrella-Style DNS Security via DNS Forwarding Redirection

This hands-on lab configures a router to redirect all client DNS queries toward a security-focused DNS resolver using DNS forwarding interception, approximating cloud-delivered DNS security enforcement without requiring per-client configuration changes.

ادامه