Traffic Engineering im Provider-Netz: MPLS-TE vs. Segment Routing TE

Traffic Engineering im Provider-Netz ist ein zentrales Werkzeug, um Kapazität effizient zu nutzen, Hotspots zu entlasten und Servicequalität auch bei Wachstum und Ausfällen stabil zu halten. In modernen Carrier-Netzen reicht „Best Path Routing“ allein häufig nicht aus: Traffic folgt sonst dem kürzesten (oder policy-besten) Pfad, selbst wenn dieser bereits stark ausgelastet ist, während alternative Korridore ungenutzt bleiben. Genau hier setzt Traffic Engineering (TE) an: Es ermöglicht eine bewusste Pfadsteuerung nach messbaren Kriterien wie Auslastung, Latenz, Link-Gruppen (Diversität) oder definierten Schutzanforderungen. In der Praxis stehen Provider dabei oft vor einer grundlegenden Architekturentscheidung: Soll Traffic Engineering über klassisches MPLS-TE (meist mit RSVP-TE) umgesetzt werden, oder ist Segment Routing TE (SR-TE) der modernere und betrieblich sinnvollere Ansatz? Beide Methoden können leistungsfähig sein, unterscheiden sich aber stark in Zustandsmodell, Skalierung, Automatisierbarkeit und Betriebsaufwand. Dieser Artikel erklärt die Grundlagen, vergleicht MPLS-TE vs. Segment Routing TE praxisnah und zeigt Best Practices, wie Sie TE so designen, dass es im Alltag stabil, nachvollziehbar und SLA-fähig bleibt.

Warum Traffic Engineering im Provider-Netz überhaupt nötig ist

Provider-Netze wachsen kontinuierlich, und Traffic ist selten gleichmäßig verteilt. Häufig dominieren wenige Korridore (zwischen Metropolen, zu Rechenzentren, zu Interconnect-PoPs) einen Großteil der Last. Gleichzeitig ändern sich Muster durch neue Peerings, CDN-Platzierungen, Cloud-Migrationen oder neue Mobilfunk-Lastprofile. Ohne TE entstehen typische Probleme: einzelne Links laufen in Congestion, Latenz und Jitter steigen, während parallel verfügbare Kapazität ungenutzt bleibt. TE hilft, die vorhandene Infrastruktur besser auszunutzen und Failover-Verhalten planbarer zu machen.

• Hotspot-Entlastung: Traffic gezielt um überlastete Korridore herumführen.
• SLA-Schutz: Kritische Dienste auf Pfade mit stabiler Latenz und ausreichender Reserve legen.
• Effiziente Kapazitätsnutzung: Bessere Lastverteilung statt „eine Achse ist voll, die andere leer“.
• Planbares Failover: Ausfälle abfangen, ohne dass das Netz unkontrolliert in Engpässe kippt.

Grundbegriffe: TE, CSPF, Constraints und Pfadsteuerung

Traffic Engineering bedeutet nicht „beliebige Pfade erzwingen“, sondern Pfade anhand von Anforderungen auszuwählen. Typisch sind sogenannte Constraints: Bandbreitenanforderungen, Link-Gruppen (z. B. Shared Risk Link Groups für Trassenvielfalt), maximale Latenz, Ausschluss bestimmter Knoten oder Korridore sowie Prioritäten für Preemption. Viele TE-Modelle nutzen dafür eine constraint-basierte Pfadsuche (CSPF) auf Grundlage der Topologie und zusätzlicher TE-Attribute.

• Constraint: Bedingung, die ein Pfad erfüllen muss (Bandbreite, Diversität, Policy).
• CSPF: Pfadberechnung unter Constraints, statt nur kürzester Pfad nach Metrik.
• TE-Attribute: Zusätzliche Informationen im Underlay, um Pfade sinnvoll zu bewerten.
• Policy: Regelwerk, wann welcher Traffic welchen Pfad nutzen soll.

MPLS-TE: Klassisches Traffic Engineering mit RSVP-TE

MPLS-TE wird in vielen Provider-Netzen seit Jahren eingesetzt, um explizite Label Switched Paths (LSPs) aufzubauen, Bandbreite zu reservieren und Traffic über definierte Pfade zu führen. Typischerweise basiert MPLS-TE auf RSVP-TE als Signalisierungsprotokoll. Der Kern ist zustandsbehaftet: Jeder TE-Tunnel ist ein Objekt im Netz, das aufgebaut, gepflegt und bei Änderungen aktualisiert wird. Das ermöglicht präzise Steuerung, erhöht aber den operativen Aufwand, insbesondere bei vielen Tunneln und großen Topologien.

Stärken von MPLS-TE

• Explizite Pfade: Sehr gezielte Pfadvorgabe möglich, inklusive strenger Constraints.
• Bandbreitenreservierung: Reservierung kann Überbuchung reduzieren und Planbarkeit erhöhen.
• Bewährte Praxis: In vielen Netzen etabliert, mit ausgereiften Betriebsprozessen.
• Fast Reroute: Lokale Schutzmechanismen können sehr schnelle Umschaltungen ermöglichen.

Herausforderungen von MPLS-TE

• State im Netz: Viele LSPs erhöhen Zustandslast, CPU-Last und Komplexität.
• Signalisierung: RSVP-TE benötigt kontinuierliche Pflege; bei Instabilität kann das zu zusätzlicher Last führen.
• Skalierung: In sehr großen Netzen wird Tunnelmanagement schnell anspruchsvoll.
• Operations: Fehlersuche und Change-Management erfordern disziplinierte Standards und Tooling.

Segment Routing TE: SR-TE als policy-getriebener Ansatz

Segment Routing TE verfolgt ein anderes Prinzip: Pfadsteuerung erfolgt über Segmente, die vom Ingress-Knoten gewählt werden. Statt für jeden TE-Pfad signalisierte Zustände entlang des gesamten Pfades zu pflegen, wird die Steuerung stärker am Rand (Ingress) konzentriert. SR-TE kann in SR-MPLS-Umgebungen über Segmentlisten im MPLS-Label-Stack umgesetzt werden, oder in SRv6-Umgebungen über IPv6-basierte SIDs. In der Praxis wird SR-TE oft als moderner, besser automatisierbarer Ansatz betrachtet, weil er weniger per-Tunnel State im Core erfordert und gut zu Policy- und Controller-Modellen passt.

Stärken von Segment Routing TE

• Weniger Signalisierungszustand: Pfadsteuerung über Segmente reduziert die Notwendigkeit umfangreicher RSVP-TE-Signalisierung.
• Policy-orientiert: SR-Policies lassen sich standardisiert definieren und automatisiert ausrollen.
• Skalierbarkeit: Geeignet für große Topologien mit vielen Pfadanforderungen, wenn gut geplant.
• Integration in Modernisierung: Passt gut zu SR-MPLS/SRv6-Roadmaps und modernen Transportarchitekturen.

Herausforderungen von Segment Routing TE

• Planung der Segmente: SID-Design und Metrik-Disziplin sind entscheidend, sonst wird TE unvorhersehbar.
• Tooling und Observability: Pfadtransparenz muss sauber umgesetzt werden, damit Betrieb und Troubleshooting funktionieren.
• Komplexität kann wandern: Weniger State im Core bedeutet oft mehr Logik am Ingress bzw. im Controller.
• Plattformunterstützung: Feature- und Skalierungsgrenzen müssen vor der Einführung realistisch bewertet werden.

Direkter Vergleich: MPLS-TE vs. SR-TE nach Provider-Kriterien

Für eine saubere Entscheidung sollten Sie MPLS-TE und Segment Routing TE entlang der Kriterien vergleichen, die im Provider-Alltag wirklich zählen: Skalierung, Betriebsaufwand, Pfadkontrolle, Schutzmechanismen, Integrationsfähigkeit und Automatisierung.

• State und Skalierung: MPLS-TE ist stärker zustandsbehaftet im Netz; SR-TE verlagert Steuerung an den Ingress und reduziert Signalisierungsstate im Core.
• Pfadkontrolle: MPLS-TE bietet sehr explizite LSP-Modelle; SR-TE ermöglicht explizite Pfade über Segmentlisten und Policies, abhängig vom Design.
• Automatisierung: SR-TE ist häufig leichter als policybasierter Baukasten zu automatisieren; MPLS-TE kann ebenfalls automatisiert werden, erfordert aber sauberes Lifecycle-Management der LSPs.
• Operations: MPLS-TE erfordert konsistente RSVP-TE-Operationalisierung; SR-TE erfordert sehr gute SID-/Policy-Disziplin und Pfad-Observability.
• Migration: SR-TE kann evolutionär aus MPLS-Netzen heraus eingeführt werden, wenn Underlay und Design vorbereitet sind.

Topologie- und Underlay-Voraussetzungen: TE scheitert meist nicht am Feature

Unabhängig von MPLS-TE oder SR-TE gilt: TE funktioniert nur so gut wie Underlay und Topologie. Wenn es keine echten alternativen Pfade gibt, kann TE nur umverteilen, nicht „retten“. Wenn Trassen nicht divers sind, bleiben korrelierte Ausfälle bestehen. Wenn Metriken chaotisch sind, wird Pfadsteuerung unvorhersehbar. Ein robustes TE-Design beginnt deshalb bei Core/Metro-Architektur, Failure Domains, ECMP-Planung und Kapazitätsreserven.

• Diversität: Mehrere Korridore und echte Trassenvielfalt sind wichtiger als komplexe TE-Policies.
• ECMP-Fähigkeit: Parallele Pfade müssen sinnvoll gestaltet werden, damit Lastverteilung stabil ist.
• Metrik-Disziplin: Kostenmodelle konsistent halten, sonst widersprechen sich TE-Ziele und Routing-Pfade.
• N-1-Headroom: Failover darf nicht automatisch Congestion erzeugen, sonst wird TE qualitativ wertlos.

Schutz und Fast Reroute: TE muss auch im Fehlerfall funktionieren

TE ist nicht nur ein „Normalbetrieb“-Werkzeug. In Provider-Netzen muss die Pfadsteuerung auch bei Ausfällen stabil reagieren. Das umfasst lokale Umschaltungen (Fast Reroute), planbare Umleitung in andere Korridore und kontrollierte Wiederherstellung. Wichtig ist dabei, Failure Models explizit zu planen: Link-Ausfall, Node-Ausfall, PoP-Ausfall. Ein Schutzpfad, der nur Link-Ausfälle abfängt, kann bei Node-Ausfall wirkungslos sein.

• Link-Schutz: Schnelle Umleitung bei Link-Ausfällen, möglichst ohne spürbare Serviceunterbrechung.
• Node-Schutz: Schutzpfade müssen den defekten Knoten wirklich vermeiden, nicht nur den defekten Link.
• Kapazitätswirkung: Schutzfälle verändern Last; TE-Policies müssen diese Lastverschiebung berücksichtigen.
• Testbarkeit: Failover-Szenarien regelmäßig unter Last testen und messen (Loss/Jitter/Latenz).

TE und Peering: Pfadsteuerung endet nicht am eigenen AS

Ein großer Teil der „gefühlten“ Performance hängt nicht nur vom internen Backbone ab, sondern auch davon, wo Traffic das Netz verlässt. TE kann interne Korridore entlasten oder Latenzpfade verbessern, aber externe Pfade werden durch BGP-Policies und Interconnect-Platzierung bestimmt. Ein professionelles TE-Konzept ist daher gekoppelt an Interconnect-Design: Super-PoPs, regionale Breakouts, private Peerings und redundante Cloud-Onramps. Dadurch werden Umwege reduziert und TE muss weniger „gegen die Geografie“ arbeiten.

• Regionale Breakouts: Traffic lokal ausleiten, um Backbone-Umwege zu vermeiden.
• Hot Potato vs. Cold Potato: Exit-Strategie bewusst wählen, statt zufällig über BGP zu entstehen.
• Interconnect-Headroom: Überlastete Peerings erzeugen Queueing-Latenz, unabhängig von interner TE.
• Policy-Konsistenz: BGP-Communities und TE-Policies müssen zusammenpassen, sonst entstehen widersprüchliche Pfadentscheidungen.

Operationalisierung: TE als Produktbaukasten statt Sonderfall-Sammlung

Traffic Engineering wird oft dann gefährlich, wenn es als Sammlung individueller Sonderpfade betrieben wird. In Telco-Umgebungen mit hoher Change-Frequenz führt das zu Drift, schwer nachvollziehbaren Pfaden und langen Entstörzeiten. Best Practice ist ein Baukasten: wenige standardisierte TE-Profile, klare Serviceklassen, definierte Constraints und automatisierte Validierung. Besonders bei SR-TE ist die Qualität des Policy-Frameworks entscheidend, weil die Logik stärker am Ingress/Controller liegt.

• Standardprofile: Wenige TE-Profile (z. B. low-latency, high-throughput, diverse-only) statt Einzelkonstrukte.
• Namens- und Tagging-Standards: Policies und Pfade müssen im Betrieb eindeutig zuordenbar sein.
• Pre-/Post-Checks: Automatisiert prüfen, ob Pfade erreichbar sind, Constraints erfüllt werden und keine Hotspots entstehen.
• Rollback-Fähigkeit: TE-Änderungen müssen schnell zurücknehmbar sein, weil sie Traffic großflächig umlenken können.

Observability: Pfade, Policies und Wirkung messbar machen

TE ohne Observability ist riskant. Sie müssen nachvollziehen können, welcher Traffic welchem Pfad folgt, warum er dort ist, und welche Auswirkungen das auf Auslastung, Latenz und Loss hat. In der Praxis bedeutet das: Telemetrie pro Link/Korridor, Flow-Daten für Heavy Flows, Ereigniskorrelation mit Changes und Failover-Tests sowie Service-KPIs (RTT/Jitter/Loss) für kritische Zielsysteme.

• Pfadtransparenz: Erkennen, welche Policy aktiv ist und welche Pfade tatsächlich genutzt werden.
• Link- und Queue-Metriken: Auslastung, Drops, Queue-Drops, optische Werte, Fehlerindikatoren.
• Flow-Daten: Hotspots und Heavy Flows identifizieren, die TE-Entscheidungen dominieren.
• Event-Korrelation: TE-Änderungen, Link-Flaps und Traffic-Anomalien zeitlich zusammenführen.

Entscheidungshilfe: Wann MPLS-TE sinnvoll bleibt und wann SR-TE klar im Vorteil ist

In vielen Netzen ist MPLS-TE weiterhin sinnvoll, wenn es bereits etabliert ist, wenn Bandbreitenreservierung und bestehende Betriebsprozesse gut funktionieren und wenn die Skalierung der LSP-Anzahl beherrschbar bleibt. SR-TE ist häufig im Vorteil, wenn ein Netz modernisiert wird, wenn Automatisierung und Policy-Frameworks zentral sind, wenn man Signalisierungsstate im Core reduzieren möchte und wenn SR ohnehin als strategische Transportbasis geplant ist. Oft ist die beste Lösung ein evolutionärer Übergang: Underlay konsolidieren, SR-Fähigkeit aufbauen, SR-TE kontrolliert einführen und MPLS-TE schrittweise zurückfahren, wo es betrieblich sinnvoll ist.

• MPLS-TE passt oft besser, wenn: bestehende RSVP-TE-Prozesse stabil sind und explizite LSP-Reservierungen zentraler Bestandteil des Betriebsmodells sind.
• SR-TE passt oft besser, wenn: Skalierung, Automatisierung und policybasierte Steuerung priorisiert werden und SR-MPLS/SRv6 strategisch geplant ist.
• Hybrid sinnvoll, wenn: bestimmte Dienste noch MPLS-TE benötigen, während neue TE-Use-Cases bereits über SR-TE umgesetzt werden.

Typische Stolperfallen bei Traffic Engineering

Die häufigsten TE-Probleme entstehen nicht durch fehlende Features, sondern durch fehlende Leitplanken: zu viele Sonderpfade, fehlende Headroom-Planung, unklare Failure Domains, inkonsistente Metriken und mangelnde Messbarkeit. Besonders gefährlich ist, TE als „Feuerwehr“ zu nutzen, um strukturelle Kapazitätsprobleme zu kaschieren. TE kann Zeit gewinnen, ersetzt aber keine nachhaltige Kapazitätserweiterung.

• TE als Ersatz für Kapazität: Ohne Headroom verschiebt TE Engpässe nur, statt sie zu lösen.
• Policy-Wildwuchs: Viele individuelle Ausnahmen machen Betrieb und Troubleshooting langsam.
• Unsaubere Metriken: Underlay und TE-Logik widersprechen sich, Pfade werden unvorhersehbar.
• Fehlende Failover-Tests: TE wirkt im Normalbetrieb gut, bricht aber im Schutzfall qualitativ ein.
• Observability-Lücken: Ohne Pfadtransparenz ist nicht erklärbar, warum Traffic „plötzlich anders“ läuft.

Operative Checkliste: MPLS-TE vs. Segment Routing TE sauber vergleichen und umsetzen

Diese Checkliste unterstützt eine fundierte Entscheidung und hilft, TE im Provider-Netz stabil zu operationalisieren.

• Sind die TE-Ziele klar (Hotspot-Entlastung, SLA-Pfade, Diversität, Latenz, Schutzfall-Verhalten) und priorisiert?
• Ist das Underlay sauber (stabile Topologie, konsistente Metriken, echte Diversität, ECMP-Design) und gibt es N-1-Headroom?
• Wird MPLS-TE als stateful System betrieben (LSP-Lifecycle, RSVP-TE-Operations, FRR-Tests), oder ist SR-TE als policybasierter Ansatz besser passend?
• Existiert ein standardisiertes Policy-/Constraint-Modell (wenige Profile, klare Tags/Communities), statt individueller Sonderfälle?
• Sind Failure Models abgedeckt (Link/Node/PoP) und wurden Schutzpfade unter Last getestet (Loss/Jitter/Latenz/Queue-Drops)?
• Ist die Interconnect-Strategie peeringseitig aligned (Breakouts, Super-PoPs, Hot/Cold Potato), damit TE nicht gegen BGP-Realität arbeitet?
• Ist Observability vollständig (Pfadtransparenz, Link-/Queue-Metriken, Flow-Daten, Event-Korrelation) und sind Runbooks vorhanden?
• Gibt es einen sicheren Rolloutplan (Pilot, gestaffelte Einführung, automatische Checks, Rollback), insbesondere bei großflächigen Policy-Änderungen?

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.