VRF-leak per MP-BGP: Controlled Inter-VRF Routing designen

Inter-VRF Routing („VRF Leak“) ist im Enterprise-WAN und in Multi-Tenant-Designs oft notwendig: Ein Shared-Services-VRF soll von mehreren Tenant-VRFs erreichbar sein, ein Internet-VRF soll selektiv als Exit dienen oder Management-Netze sollen kontrolliert erreichbar sein. Der gefährliche Teil ist das Wort „Leak“: Ohne strikte Kontrolle entstehen schnell ungewollte Seiteneffekte wie laterale Bewegungen, asymmetrische Pfade oder Route-Leaks in großem Umfang. MP-BGP ist dafür ein sehr sauberer Mechanismus, weil du Routen gezielt über Route-Targets (RTs) importierst/expandierst und damit eine klare Policy-Grenze hast. Dieses Tutorial zeigt, wie du Controlled Inter-VRF Routing per MP-BGP designst und betriebssicher umsetzt.

Warum MP-BGP für VRF-Leaks oft die beste Wahl ist

MP-BGP ist die „native“ Transportebene für VRF-Routen (VPNv4/VPNv6). Du nutzt RTs als Selektoren, um Routen nur dort sichtbar zu machen, wo sie hingehören. Das ist skalierbarer und auditierbarer als statische Route-Leaks oder PBR-Konstrukte.

• Skalierbar: Routen werden über RT-Import/Export gesteuert
• Auditierbar: klare Policy durch RTs und Route-Maps
• Stabil: weniger „Hidden Magic“ als PBR/Static Leaks

Die Bausteine: RD, RT, Import/Export

Für VRFs brauchst du zwei Konzepte, die häufig verwechselt werden: RD (Route Distinguisher) macht Prefixes eindeutig, RT (Route Target) steuert, wer welche Routen importiert/exports. Für Leaks ist RT das zentrale Werkzeug.

• RD: Eindeutigkeit von gleichen Prefixes in verschiedenen VRFs
• RT export: markiert Routen beim Verlassen der VRF
• RT import: bestimmt, welche markierten Routen in eine VRF hinein dürfen

Merker

$\text{RD}=\text{Unique}, \text{RT}=\text{Policy}$

Designpattern: Shared Services VRF (Hub) + Tenant VRFs (Spokes)

Das häufigste Enterprise-Pattern ist „Shared Services“: DNS, AD, PKI, Logging, Jump Hosts. Tenant-VRFs sollen nur zu diesen Services, nicht untereinander. Das erreichst du mit einem Hub-RT (Services export) und selektivem Import in die Tenant-VRFs.

• Services-VRF exportiert nur Service-Prefixes (Whitelist)
• Tenant-VRF importiert nur Services-RT, aber nicht andere Tenants
• Optional: Rückweg (Tenant → Services) ebenfalls kontrolliert

Planung: RT- und RD-Schema sauber festlegen

Bevor du konfigurierst, brauchst du ein RT-Schema. In der Praxis ist ein konsistentes Nummernmodell entscheidend, damit du nicht später „RT-Spaghetti“ bekommst.

• RD pro VRF eindeutig, z. B. 65000:<vrf-id>
• RT pro Policy-Domäne, z. B. 65000:1000 für Shared Services
• Tenant-RTs getrennt, z. B. 65000:2001, 65000:2002

Beispiel-Schema

VRF SERVICES: RD 65000:100,  RT export 65000:1000
VRF TENANT_A: RD 65000:201,  RT export 65000:2001, RT import 65000:1000
VRF TENANT_B: RD 65000:202,  RT export 65000:2002, RT import 65000:1000

Konfiguration: VRFs mit RD/RT definieren

Dieses Beispiel zeigt drei VRFs: SERVICES (Hub) und zwei Tenant-VRFs. Tenants importieren Services-RT, aber nicht untereinander. Das ist der grundlegende Leak-Mechanismus.

VRF SERVICES

vrf definition SERVICES
 rd 65000:100
 route-target export 65000:1000
 route-target import 65000:1000

VRF TENANT_A

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

VRF TENANT_B

vrf definition TENANT_B
 rd 65000:202
 route-target export 65000:2002
 route-target import 65000:2002
 route-target import 65000:1000

MP-BGP aktivieren: VPNv4/VPNv6 als Transport

Damit VRF-Routen zwischen PEs (oder innerhalb einer Plattform) transportiert werden, brauchst du MP-BGP für VPNv4/VPNv6. In vielen Enterprise-WANs ist das ohnehin vorhanden. Für kontrollierte Leaks ist wichtig, dass du RTs korrekt setzt und nicht „alles importierst“.

MP-BGP Grundpattern (VPNv4)

router bgp 65000
 address-family vpnv4
  neighbor 10.255.0.2 remote-as 65000
  neighbor 10.255.0.2 update-source loopback0
  neighbor 10.255.0.2 activate
  neighbor 10.255.0.2 send-community extended

Controlled Leakage: Nur definierte Prefixes exportieren (Whitelist)

RT-Import/Export ist die grobe Policy. In der Praxis willst du zusätzlich eine Whitelist, damit im Services-VRF nicht aus Versehen „alles“ exportiert wird (z. B. ein breites Connected-Netz). Dafür nutzt du Route-Maps und Prefix-Lists beim Export.

Services-Prefixes whitelisten

ip prefix-list PL_SERVICES seq 10 permit 10.10.10.0/24
ip prefix-list PL_SERVICES seq 20 permit 10.10.20.0/24
ip prefix-list PL_ANY      seq 5  permit 0.0.0.0/0 le 32

Export-Route-Map (Services)

route-map RM_EXPORT_SERVICES permit 10
 match ip address prefix-list PL_SERVICES
route-map RM_EXPORT_SERVICES deny 100

match ip address prefix-list PL_ANY

Route-Map an VRF-Export binden (Pattern)

vrf definition SERVICES
 route-target export 65000:1000
 route-target export 65000:1000 route-map RM_EXPORT_SERVICES

Rückweg kontrollieren: Tenant → Services nicht automatisch „alles“

Viele Designs scheitern am Rückweg: Tenants exportieren zu viel Richtung Services und plötzlich sind ganze Tenant-Netze im Hub sichtbar. Wenn du nur bestimmte Tenant-Prefixes brauchst (z. B. Client-Netze), whitelistest du auch hier.

Tenant Export Whitelist (Beispiel TENANT_A)

ip prefix-list PL_TA_TO_SERV seq 10 permit 10.20.10.0/24
route-map RM_EXPORT_TA permit 10

match ip address prefix-list PL_TA_TO_SERV

route-map RM_EXPORT_TA deny 100

match ip address prefix-list PL_ANY

Export Route-Map binden (Pattern)

vrf definition TENANT_A
 route-target export 65000:2001 route-map RM_EXPORT_TA

Policy & Security: Routing-Leak ist nicht automatisch Traffic-Leak

Routing-Sichtbarkeit bedeutet noch nicht, dass Traffic erlaubt sein sollte. Für echtes „Controlled Inter-VRF Routing“ brauchst du zusätzlich Security Controls: Zonen/ACLs/Firewall-Policies zwischen VRFs oder an den Service-Endpunkten.

• ACLs/ZBFW: nur benötigte Ports zu Shared Services
• Logging: Verbindungsversuche und Drops sichtbar machen
• Least Privilege: nur Services, nicht „Any-Any“ zwischen VRFs

Asymmetrie vermeiden: Return-Path bewusst designen

Inter-VRF Routing führt leicht zu asymmetrischen Pfaden: Tenant → Services läuft über Leak, Rückweg geht über einen anderen Exit oder fehlt. Das ist besonders kritisch bei stateful Firewalls und NAT. Stelle sicher, dass Return-Path-Prefixes sichtbar sind oder dass du zentrale Policy-Points verwendest.

• Return-Path-Prefixes im Services-VRF gezielt importieren
• Stateful Firewalls: Pfade symmetrisch halten
• NAT: nur in klaren VRFs, nicht „quer“

Verifikation: Beweise, dass nur das geleakt wird, was du willst

Nach dem Rollout prüfst du pro VRF: welche Routen sind sichtbar, woher kommen sie (RT), und ob Traffic wie erwartet funktioniert. Der wichtigste Betriebscheck ist „Route Count Drift“: wächst eine VRF plötzlich, ist oft ein Leak passiert.

VPNv4 Route und RT prüfen

show bgp vpnv4 unicast all
show bgp vpnv4 unicast all | include 65000:1000

VRF-Routingtabellen prüfen

show ip route vrf SERVICES
show ip route vrf TENANT_A
show ip route vrf TENANT_B

Gezielte Prefix-Prüfung

show ip route vrf TENANT_A 10.10.10.0 255.255.255.0
show ip route vrf SERVICES 10.20.10.0 255.255.255.0

Typische Pitfalls: Warum Inter-VRF Leaks aus dem Ruder laufen

Die häufigsten Fehler sind konzeptionell: zu breite RT-Imports, fehlende Export-Whitelist, oder „wir importieren mal schnell alles“ als Incident-Fix. Das führt zu dauerhaften Security- und Betriebsproblemen.

• Zu breites RT import → Tenant sieht plötzlich andere Tenants
• Kein Export-Filter → Services-VRF exportiert zu viele Prefixes
• Fehlende Security-Policy → Routing leak wird Traffic leak
• Return Path vergessen → Asymmetrie, Sessions brechen

Quick-Template: Controlled Services Leak (Hub-Spoke)

Dieses Template ist ein Startpunkt: Services exportiert whitelistet Prefixes, Tenants importieren nur Services-RT. Passe Prefixes, RD/RTs und VRF-Namen an.

ip prefix-list PL_ANY seq 5 permit 0.0.0.0/0 le 32
ip prefix-list PL_SERVICES seq 10 permit 10.10.10.0/24
route-map RM_EXPORT_SERVICES permit 10

match ip address prefix-list PL_SERVICES

route-map RM_EXPORT_SERVICES deny 100

match ip address prefix-list PL_ANY
vrf definition SERVICES

rd 65000:100

route-target export 65000:1000 route-map RM_EXPORT_SERVICES

route-target import 65000:1000
vrf definition TENANT_A

rd 65000:201

route-target export 65000:2001

route-target import 65000:2001

route-target import 65000:1000

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.