VPNv4/v6 im Detail: MP-BGP Address Families richtig verstehen

VPNv4 und VPNv6 sind die zentralen MP-BGP Address Families für MPLS L3VPN: Sie transportieren VRF-Routen zwischen PEs, inklusive Route Distinguisher (RD), Route Targets (RT) und – im MPLS-Fall – VPN-Labels. Wer VPNv4/v6 wirklich versteht, kann L3VPN sauber designen, RT-Leaks kontrollieren und Troubleshooting stark beschleunigen. Der häufigste Denkfehler ist, VPNv4/v6 mit „IPv4/IPv6 Routing“ gleichzusetzen: VPNv4/v6 sind nicht einfach IP-Routen, sondern „VRF-Routen in einer transportierbaren Form“, die erst über RT-Import in einer konkreten VRF sichtbar werden. Dieser Artikel erklärt die Address Families im Detail und zeigt, wie du sie auf Cisco IOS XE korrekt einordnest.

MP-BGP Address Families: Was bedeutet AFI/SAFI praktisch?

BGP kann mehrere „Adressfamilien“ parallel transportieren. AFI (Address Family Identifier) beschreibt die Protokollfamilie (IPv4/IPv6). SAFI (Subsequent AFI) beschreibt die Semantik, z. B. Unicast, Multicast oder VPN. VPNv4 ist deshalb nicht „IPv4“, sondern „IPv4 VPN“ (IPv4 Routen + VPN-Attribute).

• IPv4 Unicast: klassisches globales IPv4 Routing
• IPv6 Unicast: klassisches globales IPv6 Routing
• VPNv4: VRF-IPv4 Routen als VPN-„Container“
• VPNv6: VRF-IPv6 Routen als VPN-„Container“

Merker

$\text{Address Family}=\text{„welche Art Route transportiere ich?“}$

VPNv4/v6: Welche „Daten“ werden transportiert?

VPNv4/v6 transportiert mehr als nur Prefix+Next-Hop. Du transportierst mindestens: RD zur Eindeutigkeit, RTs zur Policy und häufig ein MPLS-VPN-Label, damit der Egress-PE das Paket in die richtige VRF einsortieren kann.

• RD (Route Distinguisher): macht Prefixes VRF-weit eindeutig
• RT (Route Target): steuert Import/Export (Policy)
• Next-Hop: typischerweise PE-Loopback
• VPN Label: „inneres Label“ für VRF-Zuordnung am Egress

VPNv4 Route als Denkmodell

$\text{(RD:Prefix)}+\text{RTs}+\text{Next-Hop}+\text{VPN-Label}$

RD: Eindeutigkeit, nicht Policy

RD sorgt dafür, dass identische Prefixes in unterschiedlichen VRFs gleichzeitig existieren können. RD beeinflusst aber nicht, wer diese Routen sieht. Dafür sind RTs zuständig. Ein sauberer Betrieb trennt diese Konzepte strikt.

• RD muss eindeutig pro VRF sein
• RD kann beliebig gewählt werden (aber konsistent/registriert)
• RD ist kein Leak-Schutz

RT: Der Policy-Schlüssel für Imports/Exports

RTs sind Extended Communities. Sie entscheiden, ob eine VPNv4/v6 Route in eine VRF importiert wird. Das ist der Kern von L3VPN: Control Plane Sichtbarkeit über RTs.

• Export-RT: markiert Route beim Verlassen der VRF
• Import-RT: bestimmt, ob Route in VRF sichtbar wird
• Selective Leak: Route-Maps reduzieren Export/Import zusätzlich

Warum send-community extended Pflicht ist

Ohne Extended Communities kommen RTs nicht zuverlässig beim Gegenüber an. Dann „existieren“ VPNv4/v6 Routen zwar im BGP, landen aber nicht in den VRFs (weil RT-Policy fehlt). Das ist eine der häufigsten Ursachen für „VPNv4 Route da, aber VRF leer“.

VPNv4 Neighbor-Setup (Pattern)

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

VPNv4/v6 vs. VRF Address-Family: Zwei Ebenen in IOS XE

Auf Cisco gibt es eine wichtige Trennung: VPNv4/v6 ist die Transport-AF zwischen PEs/RRs. Zusätzlich gibt es VRF-spezifische Address Families (address-family ipv4 vrf X / ipv6 vrf X), in denen du CE-PE Routing und VRF-Policies definierst. Diese beiden Ebenen werden oft verwechselt.

• VPNv4/v6 AF: PE↔PE/RR Transport der VPN-Routen
• IPv4/IPv6 VRF AF: CE↔PE Routing und lokale VRF-Policy

VRF AF Beispiel (CE-PE BGP)

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

Label-Aspekt: Warum VPNv4/v6 „MPLS-fähig“ ist

In MPLS L3VPN wird zur VPNv4/v6 Route ein VPN-Label annonciert. Das ist das innere Label im Stack. Der Core transportiert das Paket zum Egress-PE über ein äußeres Transportlabel (LDP oder SR-MPLS). Am Egress sorgt das VPN-Label für die richtige VRF und den richtigen Next-Hop im VRF-CEF.

• Outer Label: Transport durch den Core
• Inner Label: VPN/VRF Zuordnung am Egress
• PHP: Outer Label wird oft am vorletzten Hop entfernt

Route Reflectors und VPNv4/v6: Skalierung richtig denken

In großen Netzen laufen VPNv4/v6 Sessions typischerweise über Route Reflectors. Wichtig ist: RRs müssen VPNv4/v6 aktivieren und Extended Communities reflektieren. Sonst „sehen“ PEs die VPN-Routen nicht oder verlieren RT-Informationen.

• RR muss VPNv4/v6 Address Family aktiv haben
• RR-Redundanz ist Pflicht (Transport-Control-Plane kritisch)
• Next-Hop Handling: Reachability der PE-Loopbacks im IGP

RR Verifikation (Pattern)

show ip bgp vpnv4 all summary
show ip bgp vpnv6 all summary

VPNv4/v6 Troubleshooting: Drei Ebenen prüfen

Wenn eine VPN-Route „fehlt“, prüfst du immer in dieser Reihenfolge: (1) VPNv4/v6 BGP hat die Route, (2) RT-Import bringt sie in die VRF, (3) MPLS-Transport kann sie forwarden. Viele Probleme sitzen in Ebene (2).

• Ebene 1: BGP VPNv4/v6 Route vorhanden?
• Ebene 2: RT-Import korrekt, Route in VRF-RIB?
• Ebene 3: MPLS Forwarding (LFIB) und VPN-Label ok?

Ebene 1: VPNv4/v6 prüfen

show ip bgp vpnv4 all
show ip bgp vpnv6 all

Ebene 2: VRF-Routing prüfen

show ip route vrf CUST_A
show ipv6 route vrf CUST_A

Ebene 3: Labels/Transport prüfen

show mpls forwarding-table
show mpls ldp neighbor
traceroute mpls ipv4 <remote-pe-loopback>

Typische Pitfalls bei VPNv4/v6 Address Families

Die häufigsten Fehler entstehen durch AF-Verwechslungen oder fehlende Communities. Diese Pitfalls solltest du im Runbook als feste Checks führen.

• VPNv4 AF nicht aktiviert am Neighbor/RR → keine VPN-Routen
• send-community extended fehlt → RTs fehlen, VRF bleibt leer
• RT import/export falsch → Routen landen in falscher VRF oder gar nicht
• PE-Loopback nicht erreichbar → Next-Hop unreach, Route unusable
• IPv6 VRF gebaut, aber nur VPNv4 peered → IPv6 bleibt „unsichtbar“

Verifikation: „Eine Route end-to-end“ beweisen

Für ein sauberes Troubleshooting wählst du ein konkretes Prefix und beweist es durch alle Ebenen: VPNv4 Route mit RD/RT, VRF-RIB-Entry, CEF/Next-Hop und MPLS-Forwarding.

Proof-of-Route (Pattern)

show ip bgp vpnv4 vrf CUST_A 10.20.10.0/24
show ip route vrf CUST_A 10.20.10.0 255.255.255.0
show ip cef vrf CUST_A 10.20.10.1 detail
show mpls forwarding-table

Quick-Runbook: VPNv4/v6 AF Health Check

Diese Kommandos liefern schnell: Sessions up, VPN-Routen vorhanden, RTs wirken, VRF-RIB gefüllt.

show ip bgp vpnv4 all summary
show ip bgp vpnv6 all summary
show ip bgp vpnv4 all | include RT:
show running-config | section vrf definition
show ip route vrf <VRF> summary
show mpls forwarding-table

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.