# [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: ```plaintext [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**: ```plaintext 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 ```plaintext bashCopyEditrouter isis CORE address-family ipv4 unicast segment-routing mpls ! ``` --- ### 🗺️ Step 2: Assign Segment IDs to Loopbacks ```plaintext 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 ```plaintext bashCopyEditmpls traffic-eng ! interface GigabitEthernet0/0/0/0 mpls traffic-eng tunnels ``` --- ### 🚧 Step 4: Create SR-TE Policy ```plaintext 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 ```plaintext 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 ```plaintext 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 ```plaintext 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) ```plaintext 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) ```plaintext 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) ```plaintext 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.