Site icon bintorosoft.com

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

Red Snapper

Organized network. 3d render white isolated graphic background

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.

Merker

RSVP-TE = Netz hält Tunnel-State ,   SR = 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.

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.

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.

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.

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).

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.

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.

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.

Entscheidungsleitfaden: Welche Wahl passt wann?

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

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.

Quick-Runbook: Entscheidung in 10 Minuten vorbereiten

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

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

Sie erhalten

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.

Exit mobile version