Cisco 300-410: MPLS, VRFs und Layer-3-VPN-Dienste — Lernleitfaden

By Laurynas Brazys · 16 August 2026 · #cisco #300-410 #certification #exam-prep #study-guide

Teil des Cisco CCNP Enterprise 300-410 ENARSI — Lernleitfaden. Üben Sie mit verifizierten Antworten im Cisco-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Überblick

Multiprotocol Label Switching (MPLS) Layer-3-VPNs trennen das Kunden-Routing in virtuelle Routing- und Forwarding-Instanzen (VRFs) und nutzen dabei einen gemeinsamen Provider-Core für den Transport. Provider-Edge-Router (PE) fügen Label-Stacks hinzu und entfernen sie, sodass Provider-Router (P) Pakete rein auf Basis von Labels weiterleiten, was Skalierbarkeit und Isolation gewährleistet. MP-BGP verteilt VPN-Routen (VPNv4/VPNv6) mit Route Distinguishers (RDs), um deren Eindeutigkeit sicherzustellen, und Route Targets (RTs), um die Import-/Export-Richtlinien zu steuern. Ein korrektes Design erfordert eine klare Trennung der Kunden- und Provider-Rollen, eine sorgfältige Verteilung der Labels und explizite Richtlinien für Route-Leaking und gemeinsam genutzte Dienste. Der Betrieb erfordert vorhersagbare Zustände der Control-Plane (IGP, LDP/RSVP, MP-BGP) und ein deterministisches Verhalten der Data-Plane (Label-Stacking, PHP), mit rigoroser Verifizierung und Fehlerisolierung über die Grenzen von CE, PE und Core hinweg.

MPLS Forwarding und Label Distribution

• Label-Format und -Stack

  • Ein MPLS-Shim-Header enthält ein 20-Bit-Label, eine 3-Bit-Traffic-Class (TC/EXP), ein 1-Bit-Bottom-of-Stack-Flag (S) und eine 8-Bit-TTL.
  • Pakete tragen einen Stack: ein äußeres „Transport“-Label für den PE-zu-PE-LSP und ein inneres „VPN“-Label, das die Egress-PE-VRF (oder den Dienst) identifiziert.
  • Penultimate Hop Popping (PHP) entfernt das oberste Label am vorletzten P-Router, um die Last des Egress-PE zu reduzieren; Explicit-Null kann verwendet werden, um das oberste Label beizubehalten und so die QoS/TTL-Semantik bis zum Egress zu erhalten.

• LDP-Grundlagen

  • P- und PE-Router führen typischerweise ein Interior Gateway Protocol (IGP) aus, um die Erreichbarkeit herzustellen, und das Label Distribution Protocol (LDP), um Forwarding Equivalence Classes (FECs) auf Labels abzubilden.
  • LDP entdeckt Nachbarn über UDP/646-Hellos und baut Label-Sitzungen über TCP/646 auf, was eine zuverlässige Label-Signalisierung ermöglicht. Targeted LDP (tLDP) kann Offlink-Sitzungen für bestimmte FECs aufbauen.
  • Stile der Label-Zuweisung/-Verbreitung:
    • Independent vs. Ordered Control: Ein Router kann Labels für eine FEC zuweisen, sobald er eine Route kennt (Independent), oder erst, wenn er ein Label von seinem Next-Hop erhalten hat (Ordered).
    • Liberal vs. Conservative Label Retention: Alle empfangenen Labels behalten oder nur die vom besten Next-Hop, was einen Kompromiss zwischen Speicherverbrauch und Konvergenzgeschwindigkeit darstellt.
  • Die LDP-Router-ID ist standardmäßig die höchste Loopback-Adresse, falls vorhanden (andernfalls die höchste aktive Schnittstelle). Stabilisieren Sie diese (und den Transport), um Session-Churn zu vermeiden; erwägen Sie eine LDP-IGP-Synchronisation, um Blackholing während der Konvergenz zu verhindern.

• Umfang der Control-Plane des P-Routers

  • Core-P-Router führen keine VPN-Routen; sie betreiben nur den Underlay (IGP) und die Label-Signalisierung (LDP oder RSVP-TE). RSVP-TE kann anstelle von oder zusammen mit LDP für Traffic-Engineering verwendet werden.

• Data-Plane-Pfad

  • Der Ingress-PE fügt VPN- und Transport-Labels hinzu; P-Router tauschen nur das äußere Label aus; der vorletzte P-Router entfernt das Transport-Label (es sei denn, Explicit-Null wird verwendet); der Egress-PE entfernt das VPN-Label, wählt die VRF aus und leitet das Paket mittels eines normalen IP-Lookups weiter.

• Praktische Konfigurationsbefehle (IOS/IOS XE)

  • Auf Core-gerichteten Schnittstellen:

undefined

• Global:

undefined

• Überprüfung:

undefined

,

undefined

,

undefined

L3VPN-Architektur: Rollen, VRFs, RDs, RTs und MP-BGP

• Rollen und Abgrenzungen

  • CE (Customer Edge): Führt ein zum PE gerichtetes Protokoll aus (statisch, eBGP, OSPF, EIGRP) und hält Kundenrouten; hat keine Kenntnis von MPLS.
  • PE (Provider Edge): Hält mandantenbezogene VRFs, nimmt an MP-BGP (VPNv4/VPNv6) teil und fügt Labels hinzu bzw. entfernt sie.
  • P (Provider Core): Nur Label-Switching; kein VRF-Status.
  • Kunde: Administrativer Eigentümer des CE und der mandantenbezogenen Routing-Richtlinien.

• VRFs und Adressüberlappung

  • Jeder Mandant erhält eine VRF (separate RIB/FIB). Überlappende IPv4/IPv6-Adressräume zwischen Mandanten sind zulässig.
  • Route Distinguishers (RDs) machen VRF-spezifische Routen global eindeutig, indem sie dem Präfix ein „RD:“ voranstellen, um VPNv4/VPNv6-NLRIs zu bilden; RDs sind kein Sicherheitsmechanismus und steuern keine Richtlinien.
  • Route Targets (RTs) sind BGP Extended Communities, die verwendet werden, um Routen beim Export zu markieren und auszuwählen, welche Routen eine VRF importiert. Die RT-Richtlinie ist die maßgebliche Steuerung für den Import/Export.

• MP-BGP-Adressfamilien

  • VPNv4: AFI 1, SAFI 128. MP_REACH_NLRI überträgt den Next-Hop und ein routenspezifisches VPN-Label. VPNv4-Routen werden nur zwischen PE-Knoten (und Route-Reflectors) verteilt.
  • VPNv6 (6VPE): AFI 2, SAFI 128. Ermöglicht IPv6-VPNs über einen IPv4-MPLS-Core. Der BGP-Next-Hop kann IPv4 bleiben; der PE weist VPN-Labels pro IPv6-Route zu.
  • Aktivieren Sie Extended Communities auf PE-PE-BGP-Sitzungen, damit RTs übertragen werden.

• Vereinfachtes Konfigurationsmuster (PE)

  • VRF und CE-Anbindung definieren:

undefined

undefined

undefined

undefined

-

undefined

undefined

undefined

• MP-BGP für VPNv4:

undefined

undefined

undefined

undefined

undefined

undefined

undefined

• VRF-spezifische Adressfamilien:

undefined

undefined

-

undefined

undefined

• Für 6VPE:

undefined

undefined

undefined

• Überprüfung

undefined

undefined

undefined

undefined

Richtlinien, Route Leaking, Shared Services und Segmentierung

• RT-Import/Export-Richtlinie

  • Export: Routen aus einer VRF werden mit einem oder mehreren RTs markiert. Import: Eine VRF importiert jede Route, deren RT mit ihrer Importliste übereinstimmt.
  • Eine feingranulare Steuerung wird durch VRF-spezifische Route-Maps (Export/Import-Maps) erreicht, die auf Präfixe matchen und RTs setzen/manipulieren. Dies begrenzt die unbeabsichtigte Verbreitung von Routen.

• Methoden für Route Leaking

  • RT-basiertes Leaking (empfohlen): Definieren Sie eine Shared-Services-VRF, exportieren Sie Service-Präfixe mit dem RT SVC und importieren Sie den RT SVC in ausgewählte Mandanten-VRFs. Verwenden Sie Export-Maps bei den Mandanten, um einzuschränken, welche Mandanten-Routen zurück zu den Services exportiert werden.
  • Lokales VRF-zu-VRF-Leaking: Auf einigen Plattformen können statische Routen auf Schnittstellen in anderen VRFs verweisen, oder BGP kann ein Peering zwischen VRFs auf demselben PE durchführen. Mit Vorsicht verwenden; dies umgeht die RT-Richtlinie und kann schwerer zu auditieren sein.
  • Sicherheitsabwägungen:
    • Zu freizügige Importe führen zu Any-to-Any-Erreichbarkeit und potenzieller lateraler Bewegung (Lateral Movement).
    • Symmetrisches Leaking ohne Filter kann Rückkopplungsschleifen (Feedback Loops) erzeugen oder Management-/Infrastruktur-Präfixe offenlegen.
    • Bevorzugen Sie ein Hub-and-Spoke-Modell für Shared Services mit expliziten Allow-Listen (Route-Maps) und Firewall-Verriegelungen (Interlocks).

• Konzepte der Segmentierung und Migration

  • Die Unternehmenssegmentierung beginnt mit VRF-Lite innerhalb von Campus-Netzwerken und Rechenzentren. MPLS L3VPN erweitert diese Segmente über das WAN ohne NAT und erhält überlappende IP-Adressen.
  • Migrationsansatz:
    • Jedes On-Premises VRF-Lite-Segment einem Provider-RT-Paar zuordnen.
    • CE-PE-Routing (eBGP wird bevorzugt) verwenden, um Routen pro Segment deterministisch auszutauschen.
    • Eine Shared-Services-VRF für DNS/AD/Internet-Egress einführen und diese selektiv importieren.
  • Zukunftsfähige Underlays:
    • LDP- oder RSVP-TE-basierte LSPs sind weit verbreitet. Segment Routing MPLS (SR-MPLS) kann LDP/RSVP im Underlay ersetzen, während das L3VPN-Servicemodell identisch bleibt; nur das Transport-Label stammt von SR anstatt von LDP/RSVP.

Betrieb: Control Plane, Data Plane, Verifizierung und Fehlerisolierung

• End-to-End-Paketfluss

  1. CE kündigt ein Präfix an den Ingress-PE in VRF X an.
  2. Der Ingress-PE installiert es in der RIB/CEF von VRF X, versieht es mit Export-RTs, erstellt eine VPNv4/v6-NLRI (RD:Präfix) und weist ein VPN-Label zu.
  3. MP-BGP kündigt die Route an entfernte PEs an (oder über Route Reflectors) und übermittelt dabei den Next Hop (Ingress-PE-Loopback) und das VPN-Label.
  4. Das IGP und LDP/RSVP bauen einen Transport-LSP zum Next Hop des Egress-PE auf.
  5. Data Plane: Der Ingress-PE pusht das VPN-Label (inneres) und das Transport-Label (äußeres); P-Router tauschen die äußeren Labels aus; der vorletzte P entfernt das äußere Label (PHP); der Egress-PE verwendet das innere Label, um die VRF auszuwählen und an den Egress-CE weiterzuleiten.

• Häufige Fehlermodi und Kompromisse

  • Underlay-Erreichbarkeit oder LDP ausgefallen: MP-BGP kann aktiv bleiben, aber ohne einen Transport-LSP kann der Ingress-PE kein gültiges äußeres Label pushen; Pakete werden verworfen. Verwenden Sie LDP-IGP-Sync, um Blackholing zu verhindern.
  • Fehlendes VPN-Label: Die VPNv4-Route ist vorhanden, aber kein Label (oder Label 3 mit unerwarteter Semantik) unterbricht die Weiterleitung. Bestätigen Sie, dass der Egress-PE Labels pro VRF zuweist; überprüfen Sie Richtlinien, die die Label-Ankündigung unterdrücken könnten.
  • RT-Mismatch: Routen sind in der sendenden VRF vorhanden, werden aber vom Empfänger nicht importiert. Überprüfen Sie die RTs und stellen Sie sicher, dass Extended Communities ausgetauscht werden (send-community extended).
  • MTU/Fragmentierung: Label-Stacks verursachen zusätzlichen Overhead. Stellen Sie sicher, dass Core- und PE-Schnittstellen eine ausreichende MPLS-MTU unterstützen, um Paketverluste zu vermeiden; passen Sie bei Bedarf die MSS an.
  • QoS und PHP: Das EXP-zu-QoS-Mapping kann am Egress verloren gehen, wenn das oberste Label entfernt wird. Verwenden Sie Explicit-Null für QoS-Transparenz auf dem Egress-Hop.
  • iBGP-Pfadauswahl in VPNv4: Ohne maximum-paths ibgp N wird möglicherweise nur ein Pfad verwendet, selbst bei ECMP im Core; aktivieren Sie Multipath für Load-Sharing.

• Verifizierungsworkflow

  • CE-PE-Edge:

undefined

,

undefined

oder

undefined

• MP-BGP:

undefined

;

undefined

• Labels:

undefined

;

undefined

;

undefined

• Data Plane:

undefined

;

undefined

oder zum Egress-PE-Loopback; validieren Sie das EXP/TC-Marking, falls QoS relevant ist

• Zustand (Health): Erwägen Sie BFD auf CE-PE- und PE-PE-Adjacencies, um Routing-Sitzungen zu schützen.

• Fehlerisolierung über CE, PE und Provider-Core hinweg

  1. Validieren Sie die CE-PE-Adjacency und stellen Sie sicher, dass VRF-Routen auf dem Ingress-PE vorhanden sind.
  2. Bestätigen Sie, dass die Route nach VPNv4 mit einem erwarteten RT exportiert wird und ein VPN-Label auf dem Egress-PE vorhanden ist.
  3. Stellen Sie sicher, dass ein Transport-LSP vom Ingress- zum Egress-PE existiert (LDP/RSVP-Nachbarn und Label in Richtung des Egress-PE-Loopbacks).
  4. Testen Sie die PE-PE-Erreichbarkeit mit Ping/Traceroute, ausgehend vom PE-Loopback; überprüfen Sie die ECMP-Konsistenz.
  5. Überprüfen Sie auf dem Egress-PE, ob das VPN-Label zur richtigen VRF und CE-Schnittstelle aufgelöst wird.
  6. Wenn alle Prüfungen der Control Plane erfolgreich sind, erfassen Sie die Zähler der Data Plane und überprüfen Sie das MTU- und QoS-Verhalten.

Praktisches Problemszenario

Contoso Manufacturing plant die Migration von einem VRF-Lite-WAN zu einem Provider-MPLS-L3VPN und führt dabei eine zentrale Shared-Services-VRF für Internet und DNS ein. Die Mandanten (Tenants) A und B verwenden beide intern 10.10.0.0/16 und müssen isoliert bleiben, mit Ausnahme des selektiven Zugriffs auf die Shared-Services.

Vorgehensweise

1. Definieren von VRFs und RT-Richtlinien auf PEs

   • Konfiguration:

undefined

undefined

undefined

undefined

 -

undefined

undefined

undefined

undefined

 -

undefined

undefined

undefined

undefined

• Begründung: RDs gewährleisten die Eindeutigkeit bei überlappenden 10.10.0.0/16-Routen. RTs definieren die Segmentierungsgrenzen. Ein separates RT für Shared-Services bietet einen steuerbaren zentralen Punkt (Hub).

2. Zuweisen von CE-Schnittstellen zu den korrekten VRFs und Aufbau des CE-PE-Routings

   • Konfigurationsbeispiel:

undefined

undefined

undefined

 -

undefined

undefined

undefined

undefined

• Begründung: CE-PE eBGP bietet klare Richtliniengrenzen und mandantenspezifische Kontrolle, ohne dass Attribute zwischen den Mandanten durchsickern.

3. Aktivieren von MP-BGP zwischen PEs und Verbreiten von RTs und VPN-Labels

   • Konfiguration:

undefined

undefined

undefined

undefined

undefined

undefined

undefined

• Begründung: Die VPNv4-Ankündigung transportiert sowohl RTs als auch routenspezifische VPN-Labels; die Aktivierung von iBGP-Multipath bereitet ECMP über mehrere RR/PE-Pfade vor.

4. Aufbauen und Verifizieren von Transport-LSPs im Core

   • Konfiguration:

undefined

 -

undefined

undefined

undefined

• Begründung: LDP erstellt PE-zu-PE-LSPs für das äußere Label. ECMP im IGP plus LDP unterstützt Skalierbarkeit und Konvergenz. Überprüfen Sie dies mit show mpls ldp neighbor und show mpls forwarding-table.

5. Implementieren des selektiven Routen-Leakings für Shared-Services

   • Konfiguration (auf Mandanten-VRFs):

undefined

undefined

 -

undefined

undefined

 -

undefined

undefined

undefined

undefined

 -

undefined

undefined

 -

undefined

• Begründung: Mandanten importieren nur Routen der Shared-Services; die Shared-Services-VRF importiert Mandantenrouten, exportiert aber nur genehmigte Präfixe zurück, um zu verhindern, dass Mandanten die Routen der anderen über den Hub lernen.

6. Validieren der Control/Data Planes und MTU/QoS

   • Befehle:

undefined

 -

undefined

 -

undefined

 -

undefined

 -

undefined

• Begründung: Bestätigt das VRF-Routing, die Label-Bindings und die End-to-End-Erreichbarkeit. Überprüfen Sie die MTUs der Schnittstellen, um den Label-Stack zu berücksichtigen und QoS-Markierungen beizubehalten; aktivieren Sie Explicit-Null, wenn der Egress EXP-Sichtbarkeit benötigt.

7. Einführen von IPv6-VPNs mittels 6VPE

   • Konfiguration:

undefined

undefined

undefined

 -

undefined

undefined

• Begründung: Bietet IPv6-Segmentierung über denselben IPv4-MPLS-Core mit routenspezifischen VPN-Labels und demselben RT-basierten Richtlinienmodell.

Dieser stufenweise Plan erhält die Segmentierung, ermöglicht kontrollierten gemeinsamen Zugriff, skaliert durch Label-Switching im Core und bietet klare Verifizierungspunkte für eine schnelle Fehlerisolierung.

← Routenumverteilung und richtlinienbasiertes Routing · Alle Domänen · Multicast-Routing und -Verteilung →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →