MPLS auf Cisco: LDP, RSVP-TE und Best Practices

MPLS auf Cisco ist in vielen Enterprise- und Provider-nahen Netzen das Rückgrat für skalierbares Routing, VPNs und Traffic Engineering. Wer MPLS nur als „Label statt IP“ versteht, unterschätzt schnell die eigentlichen Erfolgsfaktoren: ein sauberes Underlay (IGP), konsistente Label-Verteilung (typisch LDP), klare Rollen im Netz (P/PE/CE), sowie ein kontrollierter Betrieb mit Monitoring, Fast Reroute und nachvollziehbaren Standards. In der Praxis entstehen MPLS-Probleme selten durch das Label-Forwarding selbst, sondern durch Design- oder Betriebsdetails: falsche LDP-Neighbor-Discovery auf dem falschen Interface, fehlende Router-ID-Konsistenz, unklare MTU/Label-Stack-Planung, IGP-Instabilität, fehlende Schutzmechanismen bei Link-Flaps oder ein RSVP-TE-Setup, das zwar „grün“ ist, aber bei Wartungen plötzlich umschwenkt und unerwartete Lastspitzen erzeugt. Dieser Artikel zeigt MPLS auf Cisco aus Expertensicht: wie LDP als Standard-Label-Protokoll sauber eingesetzt wird, wann RSVP-TE sinnvoll ist (und wann nicht), welche Best Practices sich für Konfiguration, Skalierung und Betrieb bewährt haben und welche Fallstricke Sie vermeiden sollten, um ein robustes, auditierbares MPLS-Backbone zu betreiben.

MPLS in der Architektur: Underlay, Control Plane und Forwarding-Pfade

MPLS (Multiprotocol Label Switching) trennt die Pfadentscheidung (Control Plane) von der Paketweiterleitung (Data Plane). Im MPLS-Core wird ein IP-Paket an der Ingress-Seite mit einem Label-Stack versehen, im Core anhand von Labels geswitcht und am Egress wieder entlabelt. Entscheidend ist: MPLS ersetzt nicht das IP-Routing im Underlay, sondern baut darauf auf. Das Underlay (OSPF/IS-IS) liefert Topologie und Next-Hop-Informationen; MPLS-Label-Verteilung und/oder Traffic Engineering ergänzen dies.

• Underlay IGP: OSPF oder IS-IS sorgt für stabile, loopfreie IP-Erreichbarkeit und liefert die Pfade, auf denen LSPs (Label Switched Paths) basieren.
• Label-Verteilung: LDP verteilt Labels entlang der IGP-Pfade; RSVP-TE kann explizite Pfade mit Reservierungen aufbauen.
• Forwarding: Datenpakete werden per Label-Switching weitergeleitet; Penultimate Hop Popping (PHP) reduziert die Last am Egress.

Als Protokoll- und Architekturgrundlage ist die MPLS-Architektur in RFC 3031 beschrieben.

Rollen im MPLS-Netz: P, PE und CE sauber trennen

Für stabile Skalierung sollten Sie Rollen konsequent trennen. Im klassischen MPLS-VPN-Design unterscheiden Sie Provider (P) Router, Provider Edge (PE) Router und Customer Edge (CE) Router. In Enterprise-Backbones kann die Nomenklatur abweichen, das Prinzip bleibt: Der Core soll simpel bleiben, Edge-Router tragen Komplexität.

• P-Router: Reiner MPLS-Transit, meist ohne Kundenvrfs. Ziel: möglichst „langweilig“, stabil, gut skalierbar.
• PE-Router: Terminiert VRFs, setzt/entfernt VPN-Labels, spricht oft MP-BGP für VPN-Routen.
• CE-Router: Kundenseite, typischerweise ohne MPLS; spricht BGP/OSPF/static mit dem PE.

Diese Rollen sind nicht nur konzeptionell, sondern beeinflussen Betrieb und Fehlersuche: Wenn ein P-Router plötzlich VRFs, NAT oder komplexe Policies trägt, steigt das Risiko, dass MPLS-Probleme zu „Allzweckrouter“-Problemen werden.

LDP als Standard-Label-Protokoll: Wann es passt und warum es beliebt ist

LDP (Label Distribution Protocol) ist der Standardansatz, um Labels entlang der IGP-basierten Pfade zu verteilen. Es ist relativ einfach, folgt dem Underlay und skaliert in klassischen MPLS-Backbones sehr gut. LDP baut typischerweise auf der IGP-Topologie auf: Sobald IGP-Pfade existieren, kann LDP Labels austauschen und LSPs bilden.

• Stärken: Einfacher Betrieb, folgt IGP, gut für „klassisches MPLS-VPN“ und stabile Backbones.
• Grenzen: Kein explizites Traffic Engineering, keine Bandbreitenreservierung, Pfadsteuerung primär via IGP-Kosten.
• Praxis: In vielen Netzen ist LDP „default“, RSVP-TE kommt nur bei klaren TE-Anforderungen hinzu.

Die LDP-Spezifikation ist in RFC 5036 beschrieben.

LDP Best Practices auf Cisco: Stabilität durch Konsistenz

LDP wirkt oft „plug and play“, aber in großen Netzen entscheidet die Disziplin bei wenigen Schlüsselparametern. Die folgenden Best Practices sind in Cisco-Umgebungen besonders wichtig, um LDP stabil und auditierbar zu betreiben.

LDP Router-ID und Transportadresse sauber festlegen

Ein häufiger Profi-Pattern ist, die LDP-Identität an eine Loopback zu binden. Damit bleiben LDP-Sessions stabil, auch wenn einzelne physische Links wechseln, solange IP-Erreichbarkeit zur Loopback im Underlay existiert. Das reduziert Session-Flapping und vereinfacht Troubleshooting.

• Loopback als stabile Identität: LDP/IGP nutzen konsistente Router-IDs und Transportadressen.
• IGP muss Loopbacks tragen: Ohne Underlay-Reachability zur Loopback ist dieses Muster nicht stabil.
• Dokumentation: Router-ID-Konventionen sind Teil eines Backbone-Blueprints.

LDP nur auf Transit-Interfaces aktivieren

Ein klassischer Fehler ist, MPLS/LDP zu breit zu aktivieren, z. B. auf Access-SVIs oder Interfaces, auf denen keine MPLS-Transitfunktion benötigt wird. Das vergrößert die Angriffsfläche, erhöht Neighbor-Anzahl und erschwert die Fehlersuche.

• Scope minimieren: MPLS im Core und auf definierten Transitlinks.
• Edge-Ports sauber trennen: Kundenseite/CE-Links meist ohne MPLS.
• Standard-Templates: Interface-Templates verhindern Drift (ein Link ist „aus Versehen“ MPLS-enabled).

Label- und MTU-Planung: Nicht erst bei Drops daran denken

MPLS fügt Labels hinzu. Je nach Szenario (z. B. MPLS VPN mit zwei Labels, RSVP-TE mit zusätzlichen Labels, ggf. weitere Encapsulations) kann der Overhead relevant sein. Ohne konsequente MTU-Planung entstehen Drops oder Fragmentierungsprobleme, die schwer zuzuordnen sind.

• MPLS MTU prüfen: Nicht nur IP-MTU betrachten, sondern die effektive MTU inkl. Label-Stack.
• End-to-End-Konsistenz: MPLS-Core sollte konsistente MTU haben, besonders bei Port-Channels und LAGs.
• Jumbo-Frames bewusst: Wenn Jumbo genutzt wird, dann überall im Core konsistent, sonst entstehen „nur manche Flows“ Probleme.

IGP als Underlay: Ohne stabiles Routing ist MPLS nie stabil

Viele MPLS-Incidents sind IGP-Incidents. Wenn OSPF/IS-IS flapt, flapt LDP mit. Wenn das Underlay instabil ist, sind LSPs instabil. Deshalb sind Underlay-Best-Practices integraler Bestandteil eines MPLS-Blueprints.

• Punkt-zu-Punkt Links bevorzugen: Weniger Broadcast-Komplexität, weniger DR/DIS-Effekte.
• BFD gezielt einsetzen: Schnelle, robuste Failure Detection ohne aggressive IGP-Timer.
• Summarization und Hierarchien: IGP skalieren, um Flooding und SPF-Spikes zu reduzieren.
• Change-Disziplin: Core-IGP-Changes sind High-Risk und benötigen klare Pre-/Post-Checks.

RSVP-TE: Wann Traffic Engineering wirklich sinnvoll ist

RSVP-TE (Resource Reservation Protocol – Traffic Engineering) erweitert MPLS um die Fähigkeit, explizite LSPs aufzubauen, Bandbreiten zu reservieren und Pfade gezielt zu steuern. Das ist besonders interessant, wenn „IGP folgt kürzestem Pfad“ nicht ausreicht, etwa bei kapazitätskritischen Backbones, klaren SLA-Anforderungen oder wenn Sie bestimmte Pfade bewusst nutzen oder meiden möchten.

• Kapazitätssteuerung: Bestimmte LSPs sollen über definierte Links laufen, um Auslastung zu verteilen.
• Reservierung: Bandbreite kann pro TE-Tunnel reserviert werden, um Überbuchung kontrollierter zu gestalten.
• Constraint-based Routing: Pfade nach Constraints wählen (z. B. „vermeide Linkgruppe X“, „nutze nur bestimmte Farben“).
• Failover-Designs: Mit Fast Reroute (FRR) kann sehr schnelles lokales Umschalten erreicht werden.

Die RSVP-TE-Spezifikation für MPLS ist in RFC 3209 beschrieben.

RSVP-TE Best Practices: TE nur dort, wo es einen klaren Nutzen hat

RSVP-TE bringt zusätzliche Komplexität: State im Netz, Signalisierung, Reservierungslogik, zusätzliche Monitoring- und Betriebsanforderungen. Ein Profi-Ansatz nutzt RSVP-TE nicht als „Standard überall“, sondern gezielt und mit klarer Governance.

TE-Underlay sauber vorbereiten: TE-Extensions im IGP

RSVP-TE benötigt Traffic-Engineering-Informationen aus dem IGP (z. B. Link-Bandbreite, TE-Metriken, administrative Gruppen). In OSPF/IS-IS werden dafür TE-Extensions genutzt. Entscheidend ist, dass diese Informationen konsistent gepflegt sind, sonst sind CSPF-Pfade (constraint-based SPF) unzuverlässig.

• Link-Bandbreite korrekt: Reservierbare Bandbreite muss zur realen Kapazität passen.
• TE-Metriken definieren: Nicht alles über IGP-Kosten „missbrauchen“; TE-Metrik ist ein eigener Steuerhebel.
• Administrative Groups: Linkfarben/Constraints nur nutzen, wenn sie dokumentiert und operationalisiert sind.

Fast Reroute: Schneller Failover ohne globale Rekonvergenz

RSVP-TE Fast Reroute (FRR) kann lokale Reparaturpfade bereitstellen, sodass bei Link- oder Node-Failure sehr schnell umgeschaltet wird, bevor IGP global konvergiert. Das ist ein typischer Vorteil von TE in anspruchsvollen Backbones.

• Link Protection: Umgeht ausgefallene Links lokal.
• Node Protection: Umgeht ausgefallene Knoten, wenn entsprechend designt.
• Trade-off: FRR erhöht State und Komplexität; dafür sinkt Failover-Zeit drastisch.

FRR für RSVP-TE ist u. a. in RFC 4090 beschrieben.

RSVP Scaling: State, Refresh und Betriebskosten realistisch betrachten

RSVP ist zustandsbehaftet. Viele TE-Tunnels erzeugen viele Signalisierungszustände. In großen Netzen sollten Sie deshalb vorab klären, ob RSVP-TE in Ihrer Größenordnung sinnvoll ist, oder ob moderne Alternativen (z. B. Segment Routing) besser passen. Wenn RSVP-TE genutzt wird, müssen Kapazität und Monitoring konsequent geplant werden.

• Anzahl Tunnels begrenzen: Nicht „pro Prefix ein Tunnel“, sondern pro Policy/Zielklasse.
• State-Überwachung: RSVP-Neighbor, Path/Resv-State, Refresh-Anomalien überwachen.
• Failure-Domain: TE nur auf Links/Knoten, die wirklich TE-Mehrwert liefern.

LDP vs. RSVP-TE: Entscheidungslogik für die Praxis

In vielen Netzen ist die richtige Antwort nicht „entweder oder“, sondern ein bewusstes Nebeneinander. LDP liefert einfache, robuste Label-Verteilung entlang IGP-Pfaden. RSVP-TE kommt gezielt dort hinzu, wo Engineering oder FRR benötigt wird.

• Wenn LDP reicht: Stabiler Core, Pfadsteuerung über IGP-Kosten ausreichend, keine Bandbreitenreservierung nötig.
• Wenn RSVP-TE Sinn macht: Engpasslinks, klare SLA-Anforderungen, deterministische Pfadsteuerung, Bedarf an FRR.
• Hybride Designs: Standardverkehr über LDP, kritische Services über TE-Tunnels (mit klarer Governance).

Typische MPLS-Fallstricke auf Cisco: Was in der Praxis am häufigsten schiefgeht

• IGP instabil: LDP/TE sind Folgeeffekte; zuerst Underlay stabilisieren, dann MPLS optimieren.
• Zu breite MPLS-Aktivierung: LDP auf falschen Interfaces erzeugt unnötige Neighbors und Sicherheitsrisiko.
• Router-ID Drift: Wechselnde Router-IDs oder inkonsistente Transportadressen führen zu Sessionproblemen und schwerem Debugging.
• MTU/Label-Stack ignoriert: Unerklärliche Drops, besonders bei VPN-Labels, TE und zusätzlichen Encapsulations.
• RSVP ohne Kapazitätsmodell: Reservierungen passen nicht zur Realität; Tunnel werden preempted oder flappen.
• FRR ohne Tests: Failover verhält sich anders als erwartet; Wartungsfenster werden riskant.

Operational Best Practices: Monitoring, Verifikation und Change-Playbooks

MPLS ist betrieblich gut beherrschbar, wenn Sie es als Produkt mit Standards und Telemetrie betreiben. Ein professionelles Betriebsmodell umfasst:

• Underlay Health: IGP-Neighbors, SPF-Events, BFD-Status, Link-Errors und Flaps.
• LDP Health: LDP-Neighbors, Session-Flaps, Label-Bindings, LSP-Continuity (End-to-End).
• RSVP-TE Health: TE-Tunnels up/down, Path/Resv-State, FRR-Aktivierungen, Preemption-Events.
• Forwarding Verification: Traceroute/MPLS-OAM-Methoden (plattformabhängig) und kontrollierte Pfadtests.
• Change-Disziplin: Core-Changes nur mit Pre-/Post-Checks, klaren Rollback-Kriterien und möglichst kleinen Change-Blöcken.

Ein wichtiger Praxispunkt: Viele MPLS-Probleme lassen sich nur zuverlässig verstehen, wenn Sie „End-to-End“ denken. Ein lokaler Neighbor kann up sein, aber ein LSP kann trotzdem nicht bis zum Egress durchgehen (z. B. wegen fehlender Labels, MTU, oder TE-Constraint-Fehlern).

Sicherheits- und Governance-Aspekte: MPLS-Backbone nicht „offen“ betreiben

Auch wenn MPLS oft als „interne Providertechnik“ betrachtet wird, bleibt die Control Plane schützenswert. Best Practices umfassen eine klare Segmentierung von Management, definierte Transit-ACLs/CoPP-Profile und die Minimierung exponierter Protokolle auf nicht benötigten Interfaces.

• Scope minimieren: LDP/RSVP nur dort aktiv, wo es gebraucht wird.
• Management trennen: OOB/Management-VRF nutzen, klare Source-Interfaces für Telemetrie.
• Control Plane schützen: CoPP so konfigurieren, dass IGP/LDP/RSVP nicht gedroppt werden, aber Missbrauch begrenzt wird.
• Auditierbarkeit: Standardisierte Templates für P/PE Rollen, Interface-Klassen und MPLS-Feature-Sets.

Outbound-Referenzen

• RFC 3031 (MPLS Architecture) als Grundlage für MPLS-Architektur, Label-Forwarding und Kernbegriffe.
• RFC 5036 (LDP) für Label Distribution Protocol und dessen Mechanik.
• RFC 3209 (RSVP-TE) für MPLS Traffic Engineering Signalisierung via RSVP.
• RFC 4090 (Fast Reroute) für RSVP-TE FRR-Konzepte und Schutzmechanismen.
• Cisco IOS XE Configuration Guides für Cisco-spezifische MPLS/LDP/RSVP-TE Konfiguration und Plattformhinweise.
• Cisco Nexus 9000 (NX-OS) Configuration Guides für datacenternahe MPLS-/MPLS-TE- und Control-Plane-Implementierungsdetails (plattformabhängig).

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.