[SR-MPLS] IGP & SR-TE Segment Routing - Traffic Engineering

Nam NguyenNam Nguyen
6 min read

How IGP convergence ties into Fast Reroute (FRR) and Segment Routing - Traffic Engineering (SR-TE)

🔁 IGP + Fast Reroute (FRR)

  • IGP convergence usually takes tens to hundreds of milliseconds—even up to a few seconds depending on the topology and tuning.

  • During this time, traffic may drop. FRR solves this by precomputing a backup path.

  • In Cisco’s world, Loop-Free Alternates (LFA) or TI-LFA (Topology Independent LFA) are used.

  • If the primary next-hop fails, traffic is immediately redirected to the backup (pre-installed in forwarding plane), before IGP converges.

  • Once convergence finishes, the IGP installs the new best path as usual.

Key Point: FRR is a local repair mechanism to protect traffic during the IGP convergence window.

🚦 IGP + SR-TE (Segment Routing - Traffic Engineering)

  • SR-TE allows explicit path steering based on segments (SID list) rather than relying only on the IGP’s shortest path.

  • While IGP still computes SPT, SR-TE policies can override that with custom paths for SLA, bandwidth, or avoidance.

  • Even after IGP convergence, the SR-TE policy takes precedence for flows that match its criteria.

  • If a failure occurs on an SR path, FRR can be used within SR-MPLS to protect it during convergence (via TI-LFA).

Key Point: SR-TE allows more flexible post-convergence routing choices beyond IGP's best path.

While IGP still computes SPT, SR-TE policies can override that with custom paths

✅ IGP (e.g., OSPF/IS-IS):

  • Shortest Path Tree (SPT): IGP calculates the shortest path based on metrics (like cost).

  • Static and Dynamic: It works well, but has limited control over how traffic flows.

🚧 Limitation in IGP:

  • Cannot control:

    • Latency

    • Bandwidth requirements

    • Path avoidance (e.g., avoid congested or untrusted nodes)

    • Traffic differentiation (e.g., voice vs. bulk data)

🧭 Segment Routing - Traffic Engineering (SR-TE):

SR-TE builds on top of IGP, but introduces explicit path control via Segment Identifiers (SIDs). You can program traffic to follow a specific route even if it’s not the shortest path.

🎯 Use Cases:

Use CaseDescription
SLA enforcementRoute low-latency traffic over a specific low-delay path
Bandwidth controlDirect high-bandwidth flows over high-capacity links
Path exclusionAvoid unstable or congested nodes/links
Disjoint pathsCreate redundant non-overlapping backup paths

🛠️ How SR-TE Overrides IGP:

You define a policy with:

  • Source and destination

  • Constraints (e.g., "path must avoid R2" or "minimum available bandwidth: 100 Mbps")

  • A Segment List (i.e., list of router/node/adjacency SIDs to reach destination)

Then:

  • The router installs this policy into the RIB and FIB

  • Traffic matching that policy is forwarded according to the SID list, not the IGP’s SPT

🔄 If IGP recalculates (e.g., topology changes), the SR-TE path remains unchanged unless it becomes invalid, at which point a new SR-TE path can be computed or failover triggered.

📦 Use Case: Low-Latency Path for Voice Traffic

🌐 Network Topology:

        [R1]
        /   \
     10ms   50ms
     /         \
   [R2]——30ms——[R3]——10ms——[R4]
  • You need to send voice traffic from R1 to R4.

  • Voice requires <40ms latency.


🧮 What IGP Would Do (e.g., OSPF):

  • OSPF sees R1–R3–R4 (50ms + 10ms = 60ms) as the shortest path by cost/metric.

  • So it installs that path in the RIB.

  • Problem: That path exceeds your latency SLA.


🛠️ What SR-TE Allows:

  • You define a policy:

    • Source: R1

    • Destination: R4

    • Constraint: "Only allow paths with total latency < 40ms"

  • SR-TE evaluates paths:

    • R1–R2–R3–R4 → 10 + 30 + 10 = 50ms

    • R1–R2–R4 (via a new link) → 10 + 15 = 25ms

  • If this 25ms path exists (maybe R2–R4 has a direct link), SR-TE installs a segment list:

      R1 → R2 (Node SID) → R4 (Node SID)
    
  • Voice traffic follows this explicit path, even though it’s not the IGP's shortest.


🧠 Summary:

FeatureIGP (OSPF/IS-IS)SR-TE
Path controlBased on metricCustom via policy
SLA awareness❌ No✅ Yes (delay, bandwidth, exclusion)
Use caseBest-effort routingVoice, video, large flows, backups
Behavior after convergenceFollows new SPTFollows policy-defined path

Sample configuration of Segment Routing with Traffic Engineering (SR-TE) using Cisco IOS-XR.

This example assumes:

  • IS-IS is used as the IGP.

  • Segment Routing is enabled.

  • An SR-TE policy is created to prefer a custom path with specific SLAs (e.g., low latency).


🔧 Step 1: Enable Segment Routing

bashCopyEditrouter isis CORE
 address-family ipv4 unicast
  segment-routing mpls
 !

🗺️ Step 2: Assign Segment IDs to Loopbacks

bashCopyEditinterface Loopback0
 ipv4 address 1.1.1.1 255.255.255.255
!
router isis CORE
 net 49.0001.0000.0000.0001.00
 address-family ipv4 unicast
  mpls traffic-eng router-id Loopback0
  segment-routing mpls
   connected-prefix-sid-map
    address 1.1.1.1/32 sid 16001

Repeat for other routers, adjusting the IP and SID.


📡 Step 3: Enable MPLS Traffic Engineering

bashCopyEditmpls traffic-eng
!
interface GigabitEthernet0/0/0/0
 mpls traffic-eng tunnels

🚧 Step 4: Create SR-TE Policy

bashCopyEditsegment-routing
 traffic-eng
  policy VOICE-POLICY
   color 123
   end-point ipv4 4.4.4.4
   candidate-paths
    preference 100
     explicit segment-list VOICE-PATH
      name VOICE-PATH
       index 10
        segment 16002
       index 20
        segment 16004

🧭 Step 5: Forward Traffic Using the Policy

bashCopyEditrouter static
 address-family ipv4 unicast
  4.4.4.4/32  segment-routing policy VOICE-POLICY

🔍 Notes

  • segment 16002 and 16004 are SIDs representing routers R2 and R4.

  • This policy manually forces the traffic to take R1 → R2 → R4 instead of the IGP shortest path.

  • If you use a PCE, you can also compute the path dynamically based on constraints like latency or bandwidth.

Cisco IOS XE example for configuring Segment Routing with SR-TE and PCE-based dynamic policies.


🧱 Prerequisites

  • IOS XE with SR-MPLS and PCE support (e.g., on ASR 1000, Catalyst 8000).

  • You have a functioning IGP (like OSPF or IS-IS).

  • Devices support SR-PCE (Path Computation Element).


1️⃣ Enable Segment Routing and MPLS TE

bashCopyEditrouter ospf 1
 router-id 1.1.1.1
 segment-routing mpls
 mpls traffic-eng
!
interface Loopback0
 ip address 1.1.1.1 255.255.255.255
 ip ospf 1 area 0
!
interface GigabitEthernet0/0/0
 ip ospf 1 area 0
 mpls ip

2️⃣ Enable SRGB and SID on Loopback

bashCopyEditsegment-routing
 mpls
  global-block 16000 23999
  connected-prefix-sid-map
   address 1.1.1.1/32 absolute-sid 16001

Repeat on each router with a unique loopback and SID.


3️⃣ Configure PCE (on PCE node)

bashCopyEditpce
 segment-routing
  peer 2.2.2.2
   source-address 1.1.1.1
   lsr-id 1.1.1.1
   capability pce
   capability pcc

4️⃣ Enable PCC (on client router)

bashCopyEditpce
 segment-routing
  pcc
   peer 1.1.1.1
    source-address 2.2.2.2

5️⃣ Configure SR-TE Policy with Dynamic Path (computed by PCE)

bashCopyEditinterface Tunnel10
 ip unnumbered Loopback0
 tunnel mode mpls traffic-eng
 tunnel destination 4.4.4.4
 tunnel mpls traffic-eng path-option 10 dynamic
 tunnel mpls traffic-eng autoroute announce
 segment-routing mpls

🔁 Summary

  • PCE computes the best path dynamically (e.g., lowest latency).

  • SR-TE tunnel forwards traffic based on this path.

  • You don't need to define explicit segment lists—PCE handles it.

0
Subscribe to my newsletter

Read articles from Nam Nguyen directly inside your inbox. Subscribe to the newsletter, and don't miss out.

Written by

Nam Nguyen
Nam Nguyen

Visit to see more: https://linktr.ee/nddnam I am an enthusiastic Network Engineer with 7+ years of experience working on MPLS L3VPN Network projects, Cisco SDWAN Deployment, and Enterprise Networks. I love to automate every daily task and think Dev-Ops as always. Thus, I am entering the DevNet world.