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


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 Case | Description |
SLA enforcement | Route low-latency traffic over a specific low-delay path |
Bandwidth control | Direct high-bandwidth flows over high-capacity links |
Path exclusion | Avoid unstable or congested nodes/links |
Disjoint paths | Create 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:
Feature | IGP (OSPF/IS-IS) | SR-TE |
Path control | Based on metric | Custom via policy |
SLA awareness | ❌ No | ✅ Yes (delay, bandwidth, exclusion) |
Use case | Best-effort routing | Voice, video, large flows, backups |
Behavior after convergence | Follows new SPT | Follows 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
and16004
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.
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.