SR Traffic Engineering: Candidate Paths und Constraint-basierte Steuerung

Segment Routing Traffic Engineering (SR-TE) erweitert SR-MPLS um ein kontrollierbares Policy-Modell: Du definierst Policies zu einem Endpoint und gibst mehrere Candidate Paths an, aus denen der Router (oder ein Controller/PCE) abhängig von Präferenzen und Constraints den aktiven Pfad auswählt. Dadurch bekommst du deterministische Pfade, sauberen Failover und die Möglichkeit, Traffic „intelligent“ zu steuern – ohne RSVP-TE pro Tunnel State. In der Praxis ist SR-TE vor allem ein Design-Thema: Du brauchst klare Candidate-Path-Strategien (Fallback-Logik) und gut definierte Constraints (welche Links/Nodes sind erlaubt, welche sind tabu). Dieses Tutorial erklärt Candidate Paths, constraint-basierte Steuerung und einen betriebsnahen Konfigurations-Workflow.

Grundbegriffe: Policy, Candidate Path, Segment List

Eine SR Policy ist das Steuerobjekt. Ein Candidate Path ist ein möglicher Pfad zur selben Destination. Eine Segment List ist die konkrete SID-Sequenz (Label-Stack), die den Pfad beschreibt. Der aktive Pfad ist genau ein Candidate Path (pro Preference).

• SR Policy: Endpoint + Auswahlregeln
• Candidate Path: mögliche Pfadoption mit Preference
• Segment List: konkrete Labels/SIDs für einen Pfad
• Steering: wie Traffic der Policy zugeordnet wird

Merker

$\text{ActivePath}=\text{max(Preference) unter gültigen Constraints}$

Candidate Paths: Warum mehrere Pfade Pflicht sind

Ein einzelner Pfad ist kein TE, sondern nur „Pinned Routing“. In echten Backbones brauchst du mindestens einen Primary und einen Secondary Candidate Path. Optional gibt es einen Tertiary Pfad, der bewusst suboptimal ist, aber Konnektivität garantiert.

• Primary: gewünschter Normalpfad (Latenz, Kosten, Policy)
• Secondary: definierter Failover-Pfad (anderer PoP/Link)
• Tertiary: „last resort“ (IGP-shortest oder minimaler Constraint)

Best Practice

• Candidate Paths klar benennen und dokumentieren
• Preference-Abstände groß genug wählen (lesbar, auditierbar)
• Failover-Pfade regelmäßig testen (nicht nur „vorhanden“)

Constraint-basierte Steuerung: Was sind Constraints?

Constraints sind Regeln, die definieren, welche Ressourcen ein Pfad nutzen darf. Klassische Kategorien sind: Include/Exclude von Nodes/Links (Affinity/Colors), administrative Gruppen, SRLG-Vermeidung, Bandbreiten-/Metric-Grenzen oder „avoid“ Listen. Je nach Implementierung kommen die Constraints aus IGP-TE-Daten (IS-IS/OSPF TE) und werden vom Router oder einem PCE ausgewertet.

• Include: Pfad muss bestimmte Links/Nodes nutzen
• Exclude: Pfad darf bestimmte Links/Nodes nicht nutzen
• Affinity/Colors: Links werden markiert (z. B. „satellite“, „cheap“, „metro“)
• Disjointness: Pfade müssen link-/node-disjoint sein (Risikoreduktion)

Affinity/Link Colors: Der praktische Constraint-Hebel

In vielen SR-TE Designs ist „Link Coloring“ der zentrale Mechanismus: Du markierst Links mit administrativen Gruppen (Affinity) und definierst in Policies, welche Farben erlaubt oder verboten sind. So kannst du z. B. „keine Satellitenlinks“, „nur Metro“, „avoid IX“ ausdrücken, ohne jeden Pfad statisch zu konfigurieren.

Konzept

• Links tragen Affinity-Bits (Farbcode)
• Policy fordert: include/exclude bestimmter Bits
• PCE/Router berechnet Pfad, der Constraints erfüllt

Candidate Path Typen: explicit vs. dynamic

Du kannst Candidate Paths auf zwei Arten bauen. Explicit: du gibst eine feste Segment List vor (maximal deterministisch). Dynamic: der Pfad wird berechnet (CSPF/Constraint-based) und kann sich ändern, wenn Topologie oder Constraints sich ändern. In der Praxis nutzt man oft beides: explicit als „sicherer“ Primary, dynamic als flexibler Secondary.

• Explicit: feste Segment List (Node-/Adj-SIDs), sehr deterministisch
• Dynamic: berechneter Pfad, constraints-basiert, anpassungsfähig
• Hybrid: Primary explicit, Secondary dynamic (oder umgekehrt)

Konfigurations-Pattern: Policy mit mehreren Candidate Paths

Das folgende Pattern zeigt eine SR Policy mit Primary (explicit) und Secondary (explicit). Das ist ideal, um Candidate Paths zu verstehen und im Betrieb zu kontrollieren.

Segment Lists definieren (Beispiel)

segment-routing
 traffic-eng
  segment-list SL_PRIMARY
   index 10 mpls label 16011
   index 20 mpls label 16022
segment-list SL_SECONDARY

index 10 mpls label 16033

index 20 mpls label 16022

Policy mit Candidate Paths

segment-routing
 traffic-eng
  policy POL_TO_PE2
   color 100 end-point ipv4 10.255.0.2
   candidate-paths
    preference 200
     explicit segment-list SL_PRIMARY
    preference 100
     explicit segment-list SL_SECONDARY

Constraint-basiertes SR-TE: Dynamic Candidate Paths (Konzept)

Für echte constraint-basierte Steuerung brauchst du dynamische Pfade: Der Router oder ein PCE berechnet anhand von TE-Topology und Constraints eine Segment List. Die konkrete CLI ist je IOS XE Release und TE-Mode unterschiedlich, das Muster ist jedoch: Candidate Path „dynamic“ plus Constraint-Parameter.

Dynamic Candidate Path (Pattern)

segment-routing
 traffic-eng
  policy POL_TO_PE2
   color 100 end-point ipv4 10.255.0.2
   candidate-paths
    preference 200
     dynamic
    preference 150
     dynamic

Steering: Wie Traffic die SR Policy nutzt

Policies wirken nur, wenn Traffic in sie gesteuert wird. In skalierbaren Designs erfolgt Steering häufig über BGP (Color/Communities) oder über eine lokale Klassifikation (PBR). Für Backbone-TE ist BGP-Steering meist die langfristig wartbarere Option.

• BGP Steering: Zuordnung über Color/Routes (skalierbar)
• PBR: lokal, präzise, aber operational aufwändiger
• Best Practice: wenige Policies, klare Traffic-Klassen

Monitoring und Betrieb: SR-TE ist ein Telemetrie-Thema

SR-TE muss sichtbar sein: welcher Candidate Path ist active, warum wurde gewechselt, und ob Constraints erfüllt sind. Ohne diese Sicht wirkt SR-TE „random“, obwohl es deterministisch entscheidet.

• Active Candidate Path pro Policy
• Last switch reason (Link down, constraint violated, admin change)
• Traffic pro Policy (Interface Counters/NetFlow/Telemetry)

Verifikation

show segment-routing traffic-eng policy
show segment-routing traffic-eng policy name POL_TO_PE2 detail
show mpls forwarding-table | include 160

Typische Pitfalls: Warum SR-TE Policies nicht tun, was du erwartest

Die häufigsten Probleme sind nicht „SR kaputt“, sondern Design-/Constraint-Fehler: falsche SIDs, zu harte Constraints (kein Pfad möglich), oder fehlende TE-Information im IGP. Kandidaten werden dann als „invalid“ markiert und du fällst auf einen ungewollten Pfad zurück.

• SRGB inkonsistent → Segment Lists funktionieren nicht domänenweit
• Constraints zu strikt → kein gültiger Pfad verfügbar
• TE-Topology fehlt → dynamic path kann nicht berechnet werden
• Adjacency-SIDs übernutzt → Policies werden fragil

Quick-Runbook: Candidate Path Switch unter Zeitdruck

Diese Checkliste hilft, wenn eine Policy unerwartet switched oder „down“ ist: erst Status, dann Gründe, dann Forwarding.

show segment-routing traffic-eng policy
show segment-routing traffic-eng policy name POL_TO_PE2 detail
show ip route 10.255.0.2
show mpls forwarding-table | include 160
show interfaces | include drops|error
show logging | include SR|TE|ISIS|OSPF

Konfiguration speichern

Router# copy running-config startup-config

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab (CCNA)

Hallo! Ich bin ein CCNA-Network Engineer und unterstütze Sie bei Cisco Router- und Switch-Konfigurationen – inklusive eines vollständigen Cisco Packet-Tracer-Labs (.pkt). Ideal für Lern-/Übungsszenarien, Validierung oder eine saubere Demo-Topologie.

Was ich (je nach Paket) umsetze

• Switching: VLANs, Trunking (802.1Q), Port-Zuweisung, STP-Basics (PortFast/BPDU Guard wo sinnvoll)

• Routing: Default/Static Routing oder OSPF, Inter-VLAN Routing (Router-on-a-Stick)

• Services: DHCP (Pools/Scopes), NAT/PAT für Internet-Simulation

• Optional Security: Basic ACLs und SSH-Hardening

• Test & Verifikation: Ping/Traceroute + wichtige Show-Commands (mit erwarteten Ergebnissen)

Sie erhalten

• ✅ Packet Tracer .pkt Datei

• ✅ Saubere Konfigurations-Notizen pro Gerät

• ✅ Verifikations-Checkliste + erwartete Outputs

• ✅ Kurze Dokumentation (wie die Topologie funktioniert)

Bitte schreiben Sie mir vor der Bestellung, damit wir Scope, Packet-Tracer-Version, Geräteanzahl und Deadline klären.

Konfiguriere Cisco Router & Switches | Cisco Packet-Tracer-Labs. Finden Sie mich auf Fiverr.