MPLS TE vs. Segment Routing: Entscheidungsleitfaden für Router-Backbones

MPLS Traffic Engineering (TE) und Segment Routing (SR) lösen dieselbe Kernaufgabe: du willst deterministische Pfade, schnelle Failover-Mechanismen und steuerbaren Traffic durch den Backbone – unabhängig davon, was das IGP „von allein“ wählt. In der Praxis ist die Entscheidung selten ideologisch, sondern operativ: Welche Control-Plane-Komplexität akzeptierst du, welche Features brauchst du (Fastreroute, Bandbreitenreservierung, Steering), und wie gut passt das zu deiner Plattformlandschaft (IOS XE, Linecards, Telemetry, Automatisierung)? Dieser Leitfaden vergleicht MPLS TE und SR (vor allem SR-MPLS) aus Backbone-Sicht und zeigt, welche Wahl in typischen Router-Backbones sinnvoll ist.

Grundprinzip: Wie der Pfad überhaupt „festgelegt“ wird

Der wichtigste Unterschied ist das Signaling-Modell. MPLS TE basiert klassisch auf RSVP-TE: Pfade werden aufgebaut, Ressourcen reserviert und State liegt im Netz. Segment Routing kodiert den Pfad als Segment-Liste (Label Stack) und reduziert per Design das per-flow Signaling im Netz.

• MPLS TE (RSVP-TE): stateful Signaling, Reservation, per-Tunnel State
• SR-MPLS: source-routed Segmentliste, weniger State im Core
• Beide: können FRR/Protection-Mechanismen nutzen

Merker

$\text{RSVP-TE}=\text{Netz hält Tunnel-State}, \text{SR}=\text{Ingress kodiert Pfad}$

Feature-Vergleich: Was du wirklich bekommst

Viele Backbones brauchen nicht „alles“. Entscheidend ist, welche Features in deinem Betrieb tatsächlich genutzt werden und ob du diese in SR einfacher oder komplexer erreichst.

• Deterministische Pfade: TE und SR können das
• Fast Reroute: TE-FRR vs. SR TI-LFA (je nach Design)
• Bandbreitenreservierung: TE klassisch stark, SR je nach Controller/Policy
• Traffic Steering: TE über Tunnels, SR über Policies/Segments

MPLS TE (RSVP-TE): Stärken und typische Pitfalls

MPLS TE ist reif und in vielen Netzen bewährt. Seine Stärke ist die explizite Ressourcenreservierung und das klassische TE-Tunnel-Modell. Die Kehrseite ist Control-Plane-State: viele Tunnels bedeuten viele RSVP-States und mehr Betriebsaufwand.

• Stark: Bandbreitenreservierung, explicit paths, etablierte Modelle
• Stark: TE-FRR in klassischen Designs
• Pitfall: Skalierung mit vielen Tunnels/States
• Pitfall: Betriebskomplexität (RSVP, IGP-TE Extensions, Tuning)

Typische TE-Bausteine (nur zur Einordnung)

mpls traffic-eng tunnels
router ospf 10
 mpls traffic-eng area 0
interface gigabitEthernet0/0
 mpls traffic-eng tunnels

Segment Routing (SR-MPLS): Stärken und typische Pitfalls

SR-MPLS reduziert Signaling-State im Kern. Pfade werden über Segment-Listen und Policies realisiert. Dadurch wird Skalierung oft einfacher, und moderne FRR-Mechanismen wie TI-LFA sind attraktiv. Die Kehrseite ist: manche TE-Use-Cases (klassische Reservierung, per-Tunnel Bandbreite) erfordern zusätzliche Komponenten oder ein anderes Betriebsmodell.

• Stark: weniger Protokoll-State (kein RSVP pro Tunnel)
• Stark: IGP-integriert (SIDs in OSPF/IS-IS), gute Automatisierbarkeit
• Stark: moderne FRR-Optionen (TI-LFA) in passenden Topologien
• Pitfall: Pfadsteuerung kann Controller/Policy-Design erfordern

SR-MPLS Bausteine (nur zur Einordnung)

segment-routing mpls
router isis CORE
 segment-routing mpls
interface loopback0
 ip address 10.255.0.1 255.255.255.255

Entscheidungskriterium 1: Skalierung und State im Core

Wenn dein Backbone viele Tunnels oder viele TE-Policies braucht, ist RSVP-State ein echter Faktor. SR ist hier oft im Vorteil, weil der Core weniger per-Tunnel State halten muss.

• Viele Tunnels/Services → TE-State kann skalieren schlecht
• SR reduziert Core-State und vereinfacht Teile des Betriebs
• Wenn du nur wenige TE-Tunnels hast: TE kann völlig ok sein

Entscheidungskriterium 2: Bandbreitenreservierung und harte Guarantees

Wenn du echte, harte Bandbreitenreservierung im Netz brauchst (klassisch RSVP-TE), ist MPLS TE oft die naheliegende Wahl. SR kann ähnliche Ziele erreichen, aber häufig über andere Mechanismen (Policy/Controller, Admission Control außerhalb der klassischen RSVP-Logik).

• Need: harte Reservation pro Tunnel → TE ist naheliegend
• Need: „Steer & protect“ ohne harte Reservation → SR oft besser
• Praxis: viele Enterprise-Backbones brauchen keine echte Reservation

Entscheidungskriterium 3: Fast Reroute und Topologie-Fitness

Fast Reroute hängt stark von Topologie ab. TE-FRR ist ein bekanntes Modell. SR TI-LFA kann sehr elegant sein, wenn deine IGP-Topologie die notwendigen Alternativen bietet. Wenn du viele „Single-Homed“ Segmente hast, helfen beide weniger.

• Genug Alternativpfade im IGP → SR TI-LFA sehr attraktiv
• Engstellen/Single Points → FRR begrenzt, egal ob TE oder SR
• Design zuerst, Feature danach

Entscheidungskriterium 4: Operations, Troubleshooting und Tooling

In der Praxis zählt „wie gut kann ich es betreiben“. TE bringt RSVP-States, TE-Datenbanken und mehr Protokollflächen. SR bringt SID-Logik und Policies. Beide brauchen saubere Telemetrie; SR passt oft besser zu moderner Automatisierung, TE ist dafür in vielen Teams historisch besser bekannt.

• TE: mehr Protokolle (RSVP), mehr State, klassische Runbooks
• SR: weniger Protokollflächen, dafür Policy-/SID-Denke
• Team-Skillset und Monitoring entscheiden mit

Migration: „TE aus“ vs. „SR an“ ist selten ein Big Bang

Backbones migrieren typischerweise schrittweise: erst Underlay stabilisieren, dann SR als Transport einführen (oder parallel testen), dann einzelne Services umlegen. Das Ziel ist, das Risiko zu minimieren und Betriebswissen aufzubauen.

• Pilot: ein Domain-Segment/PoP
• Parallelbetrieb: einzelne Tunnels/Policies umstellen
• Rollback: klare Rückfallebene (TE-Tunnel oder IGP Default)

Entscheidungsleitfaden: Welche Wahl passt wann?

Diese Heuristik ist praxistauglich für Router-Backbones. Sie ersetzt keine detaillierte Anforderungsanalyse, verhindert aber typische Fehlentscheidungen.

• Du brauchst harte Reservation pro Tunnel → MPLS TE (RSVP-TE) naheliegend
• Du willst Skalierung, weniger State, moderne Automatisierung → SR-MPLS oft besser
• Du hast bereits TE im Betrieb und wenige Tunnels → TE weiterbetreiben kann sinnvoll sein
• Du planst langfristig SR/Controller-basierte Policies → SR früh designen

Verifikation und Betrieb: Was du bei beiden brauchst

Egal ob TE oder SR: Ohne saubere Verifikation läufst du blind. Du willst Pfade sichtbar machen, Drops erkennen und Failover testen. Der Unterschied ist nur, welche Tabellen/Kommandos du priorisierst.

Common Checks

show ip route <dst>
show mpls forwarding-table
show interfaces | include drops|error
show processes cpu sorted

TE-spezifisch (Beispiele)

show mpls traffic-eng tunnels
show mpls traffic-eng topology

SR-spezifisch (Beispiele)

show segment-routing mpls forwarding
show segment-routing mpls sid-database

Typische Pitfalls in echten Backbones

Die häufigsten Probleme sind nicht „TE vs SR“, sondern fehlende Governance und unklare Betriebsmodelle: zu viele Policies, fehlende Dokumentation, ungetestete Failover-Paths und fehlende MTU-Planung.

• MTU/Label-Stack nicht eingeplant → Drops und Fragmentierung
• Fehlende Telemetrie → Failover wirkt „random“
• Policy-Spaghetti → schwer auditierbar, schwer zu betreiben
• FRR ohne Topologie-Fitness → erwarteter Schutz greift nicht

Quick-Runbook: Entscheidung in 10 Minuten vorbereiten

Diese Checkliste hilft dir, die richtigen Fragen zu beantworten, bevor du dich festlegst.

• Wie viele Tunnels/Policies brauchst du realistisch?
• Brauchst du harte Bandbreitenreservierung oder nur Steering?
• Hat deine Topologie genügend Alternativpfade für FRR/TI-LFA?
• Welche Plattformen/Linecards unterstützen SR/TE konsistent?
• Welche Telemetrie hast du heute (Drops, Path Visibility)?

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.