MPLS L3VPN auf Cisco: VRF, RD/RT, MP-BGP Schritt für Schritt (Advanced)

MPLS L3VPN (RFC-style VPNv4/VPNv6) ist das klassische Bauprinzip für skalierbare, mandantenfähige WANs: Kundennetze laufen logisch getrennt in VRFs, während der MPLS-Core nur Transport liefert. Auf Cisco Routern setzt du das im Kern aus drei Bausteinen zusammen: (1) VRF mit RD/RT, (2) MP-BGP als VPN-Routing-Control-Plane, (3) ein MPLS-Transport (LDP oder BGP-LU) für das Outer Label. „Advanced“ bedeutet dabei vor allem: saubere RD/RT-Governance, kontrollierte Imports/Exports, robuste MP-BGP-Nachbarschaften (RR-Design) und verifizierbare Forwarding-Pfade (LFIB, VPN-Labels, PHP). Diese Anleitung führt Schritt für Schritt durch ein praxisnahes Setup.

Architekturüberblick: PE, P, CE und zwei Labels

Im L3VPN trennt man Provider Edge (PE), Provider (P) und Customer Edge (CE). Für Forwarding sind meist zwei Labels relevant: ein Outer Transport Label (durch den Core) und ein Inner VPN Label (identifiziert die VRF am Egress-PE).

• CE: Kunde/Standortrouter, spricht typischerweise eBGP/OSPF/EIGRP/static zum PE
• PE: hält VRFs, terminiert VPN-Labels, spricht MP-BGP (VPNv4/VPNv6)
• P: reiner MPLS-Transit, kennt keine Kundennetze
• Label Stack: Outer = Transport, Inner = VPN

Merker

$\text{Outer Label}=\text{Transport}, \text{Inner Label}=\text{VRF/VPN}$

Voraussetzungen: Underlay und MPLS-Transport zuerst stabil machen

Bevor du VRFs und MP-BGP baust, muss der Core funktionieren: IGP Reachability zwischen PE-Loopbacks und MPLS-Label-Forwarding im Core. Ohne das wirst du später „VPN kaputt“ debuggen, obwohl das Problem im Underlay liegt.

• IGP (OSPF/IS-IS) zwischen Core-Interfaces und PE-Loopbacks
• MPLS Transport aktiv (LDP oder BGP-LU) auf Core-Links
• MTU: MPLS-Overhead einkalkulieren

Pre-Checks

show ip route <remote-pe-loopback>
show mpls interfaces
show mpls ldp neighbor
show mpls forwarding-table

Schritt 1: VRF erstellen (RD/RT sauber definieren)

RD macht Prefixes eindeutig, RT steuert Import/Export. In L3VPN ist RT die Policy: Welche VRFs dürfen miteinander sprechen? Für ein einzelnes Customer-VRF ist das meist „export = import“ derselben RT. Für Shared Services oder Hub-and-Spoke wird RT-Design wichtiger.

Beispiel: VRF CUST_A mit RD/RT

vrf definition CUST_A
 rd 65000:201
 route-target export 65000:2001
 route-target import 65000:2001

Best Practice: RT-Governance

• Ein RT pro Kundendomäne (oder pro Policy-Domäne)
• Keine „RT-Wildwuchs“ ohne Dokumentation
• Imports selektiv halten (Controlled Leakage)

Schritt 2: Interface in VRF binden und IP setzen

Customer-facing Interfaces gehören in die VRF. Wichtig: Sobald du ein Interface in eine VRF legst, gilt dort eine eigene Routing-Tabelle. Das ist gewollt.

CE-Interface in VRF

interface gigabitEthernet0/1
 vrf forwarding CUST_A
 ip address 10.20.0.1 255.255.255.252
 no shutdown

VRF-Routing prüfen

show ip route vrf CUST_A

Schritt 3: CE-PE Routing wählen (BGP/OSPF/static) – Advanced Empfehlung

Für L3VPN ist eBGP zum CE häufig die robusteste Wahl: klare Policy, kein IGP-Leak, saubere Skalierung. Alternativ funktionieren OSPF oder statische Routen. Advanced-Design bedeutet: Whitelists, Summaries und Loop-Prevention (Tags/SoO) berücksichtigen.

• Empfehlung: eBGP CE-PE mit klaren Prefix-Filtern
• OSPF möglich: dann Domain-ID/Sham Links/Type-5 Design beachten
• Static möglich: für kleine Sites, aber weniger dynamisch

Schritt 4: MP-BGP im Provider-AS aktivieren (VPNv4/VPNv6)

MP-BGP transportiert VPN-Routen zwischen PEs. Dafür aktivierst du VPNv4 (IPv4-VRFs) und sendest Extended Communities (RTs). In größeren Netzen peeren PEs meist nicht full-mesh, sondern über Route Reflectors.

MP-BGP VPNv4 (PE zu RR oder PE zu PE)

router bgp 65000
 bgp log-neighbor-changes
 neighbor 10.255.0.10 remote-as 65000
 neighbor 10.255.0.10 update-source loopback0
address-family vpnv4

neighbor 10.255.0.10 activate

neighbor 10.255.0.10 send-community extended

RR-Design Hinweis

• RR-Paar für Redundanz
• RR muss VPNv4 reflektieren, nicht nur IPv4 unicast

Schritt 5: VRF Address-Family im BGP (Customer Routes in MP-BGP einspeisen)

Damit die PE die VRF-Routen in MP-BGP exportiert, nutzt du die VRF-spezifische Address Family. Dort definierst du, wie die CE-Routen in BGP kommen (neighbor/redistribute/network) und welche Policies gelten.

CE-PE eBGP im VRF AF (Beispiel)

router bgp 65000
 address-family ipv4 vrf CUST_A
  neighbor 10.20.0.2 remote-as 65100
  neighbor 10.20.0.2 activate
  neighbor 10.20.0.2 as-override
  neighbor 10.20.0.2 send-community

Prefix-Filtering (Best Practice)

ip prefix-list PL_CUST_A_IN seq 10 permit 10.20.10.0/24
ip prefix-list PL_CUST_A_OUT seq 10 permit 0.0.0.0/0
route-map RM_CUST_A_IN permit 10

match ip address prefix-list PL_CUST_A_IN
route-map RM_CUST_A_OUT permit 10

match ip address prefix-list PL_CUST_A_OUT

Route-Maps am CE-Neighbor (VRF AF)

router bgp 65000
 address-family ipv4 vrf CUST_A
  neighbor 10.20.0.2 route-map RM_CUST_A_IN in
  neighbor 10.20.0.2 route-map RM_CUST_A_OUT out

Advanced: Hub-and-Spoke mit RTs (ohne „Full Mesh“ der VRFs)

Für Hub-and-Spoke nutzt du unterschiedliche RTs: Spokes exportieren zu einem Hub-RT, Hub importiert Spoke-RTs. Spokes importieren nur den Hub-RT. Damit sprechen Spokes nicht direkt miteinander.

Konzept

• SPOKE export RT_SPOKE, import RT_HUB
• HUB export RT_HUB, import RT_SPOKE (oder mehrere Spoke-RTs)

Forwarding verstehen: Woher kommen Outer und Inner Label?

Das Inner VPN Label kommt aus MP-BGP: Der Egress-PE annonciert zu jedem VRF-Prefix ein VPN-Label. Das Outer Transport Label kommt aus dem MPLS-Transport (LDP oder BGP-LU) und bringt das Paket zum Egress-PE. Bei PHP wird das Outer Label am vorletzten Hop gepoppt.

Data-Plane Beweis

show ip bgp vpnv4 vrf CUST_A 10.20.10.0/24
show mpls forwarding-table | include 10.255.
show mpls forwarding-table vrf CUST_A

Verifikation: Schrittweise beweisen statt „alles auf einmal“

Bei L3VPN ist ein schrittweiser Beweis entscheidend: erst Underlay, dann MP-BGP, dann VRF-Routes, dann Labels, dann End-to-End Traffic.

1) Underlay

ping <remote-pe-loopback> source loopback0
traceroute <remote-pe-loopback> source loopback0

2) MP-BGP VPNv4

show ip bgp vpnv4 all summary
show ip bgp vpnv4 all

3) VRF-Routing

show ip route vrf CUST_A
show ip cef vrf CUST_A <remote-prefix> detail

4) MPLS Labels

show mpls forwarding-table
traceroute mpls ipv4 <remote-ce-ip>

Typische Fehlerbilder (Advanced Troubleshooting)

Viele Probleme sind systematisch: RT falsch, Extended Communities fehlen, CE-Routen kommen nicht ins BGP, oder der Transportpfad hat kein Label. Diese Fehlerbilder solltest du schnell unterscheiden.

• Keine VPN-Routen: MP-BGP VPNv4 Session/RR/AF nicht aktiv
• VPN-Routen da, aber nicht in VRF: RT import/export falsch
• VRF-Route da, aber kein Forwarding: Transportlabel fehlt (LDP/BGP-LU)
• Asymmetrie: CE-PE Routing/Policy unterschiedlich auf beiden PEs
• MTU: MPLS Overhead führt zu Drops (besonders bei VPN über WAN)

Commands für Fehleranalyse

show ip bgp vpnv4 all | include 65000:
show ip bgp vpnv4 vrf CUST_A <prefix>
show ip route vrf CUST_A
show mpls ldp neighbor
show mpls forwarding-table
show interfaces | include MTU|drops|error

Hardening und Betrieb: Guardrails für L3VPN

Advanced Betrieb heißt: Leaks verhindern, Counts überwachen und Changes kontrolliert ausrollen. Besonders wichtig sind RT-Governance, Prefix-Filtering am CE und Monitoring der VPNv4 Route-Counts.

• RT- und RD-Registry (wer darf was importieren?)
• CE-Filter: nur erlaubte Prefixes, keine „permit any“
• RR-Redundanz und MP-BGP Fast Convergence (BFD/PIC je nach Größe)
• Monitoring: VPNv4 Prefix Counts, LDP/BGP-LU Health

Quick-Template: Minimal L3VPN (eine VRF) – Copy & Paste

Dieses Template ist ein Startpunkt für eine einzelne VRF. Passe IPs, ASNs, RD/RTs und Prefixes an.

vrf definition CUST_A
 rd 65000:201
 route-target export 65000:2001
 route-target import 65000:2001
interface gigabitEthernet0/1

vrf forwarding CUST_A

ip address 10.20.0.1 255.255.255.252
router bgp 65000

neighbor 10.255.0.10 remote-as 65000

neighbor 10.255.0.10 update-source loopback0
address-family vpnv4

neighbor 10.255.0.10 activate

neighbor 10.255.0.10 send-community extended
address-family ipv4 vrf CUST_A

neighbor 10.20.0.2 remote-as 65100

neighbor 10.20.0.2 activate

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.