Site icon bintorosoft.com

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

Red Snapper

Cloud computing devices

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).

Merker

Address Family = „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.

VPNv4 Route als Denkmodell

(RD:Prefix) + RTs + Next-Hop + 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.

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.

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.

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.

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 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: 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.

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

Sie erhalten

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.

Exit mobile version