VRF Route Leaking Patterns: Export/Import, Route-Maps, Selective Leak

VRF Route Leaking ist in Multi-Tenant-WANs und Enterprise-MPLS-Designs unvermeidlich: Shared Services, zentrales Internet, Management und Security-Stacks müssen oft aus mehreren VRFs erreichbar sein. Das Risiko steckt im Wort „Leak“: Wenn Export/Import zu breit ist, wird aus einem kontrollierten Service-Zugriff schnell ein ungewolltes Transit-Netz oder ein Security-Problem. Skalierbare Patterns kombinieren deshalb immer drei Dinge: (1) klare Export/Import-RTs, (2) Route-Maps als Whitelist (Selective Leak) und (3) Betriebsguardrails (Drift Detection, Counts, Verifikation). Dieser Artikel zeigt die wichtigsten Leak-Patterns auf Cisco und wie du sie sauber baust.

Grundprinzip: Sichtbarkeit ist Policy

Ein Leak passiert nicht „auf dem Interface“, sondern auf Routing-Ebene. Du steuerst Sichtbarkeit über Route Targets (RT) und beschränkst sie zusätzlich über Route-Maps. RD sorgt nur für Eindeutigkeit, nicht für Sicherheit.

Merker

$\text{RT import/export} + \text{Whitelist} \to \text{Selective Leak}$

• RT = grobe Policy (wer darf grundsätzlich sehen?)
• Route-Map = feine Policy (welche Prefixes genau?)
• Security = zusätzlich (ACL/ZBFW), nicht automatisch durch Routing

Bausteine: RD, RT, Extended Communities

Für VRFs brauchst du RD und RT. In MP-BGP werden RTs als Extended Communities transportiert. Wenn send-community extended fehlt, funktionieren Imports/Exports nicht zuverlässig.

• RD: eindeutige Identität eines Prefixes pro VRF
• RT: Import/Export-Selektor (Policy-Schlüssel)
• Extended Communities: Transportformat für RTs

MP-BGP Erinnerung (VPNv4)

router bgp 65000
 address-family vpnv4
  neighbor 10.255.0.10 activate
  neighbor 10.255.0.10 send-community extended

Pattern 1: Shared Services (Hub) – Tenants importieren genau einen RT

Das häufigste Pattern: Eine SERVICES-VRF exportiert ausgewählte Service-Prefixes. Viele Tenant-VRFs importieren diesen Services-RT. Tenants importieren sich nicht gegenseitig. Das skaliert, weil du neue Tenants hinzufügen kannst, ohne bestehende Tenants zu ändern.

• SERVICES exportiert RT_SVC
• TENANT_X importiert RT_SVC
• Optional: Rückweg (Tenant → Services) separat und selektiv

VRFs (Beispiel)

vrf definition SERVICES
 rd 65000:100
 route-target export 65000:1000
 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

Pattern 2: Central Internet VRF – selektiver Default Leak

Ein zentrales Internet-VRF ist attraktiv, aber riskant. Das saubere Pattern ist: Tenants importieren (falls gewünscht) nur eine Default Route oder wenige Internet-Exit-Prefixes. Internet-VRF importiert Tenant-Prefixes nicht „blind“, sondern nur das, was für Return Path oder NAT erforderlich ist.

• Tenant importiert Default (0.0.0.0/0) aus INET-VRF
• INET-VRF importiert Tenant-Netze selektiv für Return Path
• Security: ZBFW/ACL zwingend (sonst wird INET zum Transit)

Default-Export nur per Whitelist

ip prefix-list PL_DEFAULT seq 10 permit 0.0.0.0/0
ip prefix-list PL_ANY     seq 5  permit 0.0.0.0/0 le 32
route-map RM_EXPORT_DEFAULT permit 10

match ip address prefix-list PL_DEFAULT

route-map RM_EXPORT_DEFAULT deny 100

match ip address prefix-list PL_ANY
vrf definition INET

rd 65000:110

route-target export 65000:1100 route-map RM_EXPORT_DEFAULT

route-target import 65000:1100

Pattern 3: Hub-and-Spoke – Spokes dürfen nicht untereinander

Hub-and-Spoke ist ideal für Branch-to-DC: Spokes importieren nur den Hub, der Hub importiert Spokes. So verhinderst du East-West zwischen Standorten, ohne pro Spoke ACLs zu bauen.

• Hub exportiert RT_HUB
• Spoke importiert RT_HUB
• Hub importiert RT_SPOKE_* (oder einen kontrollierten Satz)

Konzeptbeispiel

VRF HUB:   export 65000:3000, import 65000:3xxx
VRF SPOKE: export 65000:3xxx, import 65000:3000

Pattern 4: Management/OOB Leak – nur Jump Hosts und Monitoring

Management-VRFs sollten nicht „alles sehen“. Das gute Pattern ist: Management importiert nur Device/Loopback-Prefixes (oder eine definierte Management-Subnet-Klasse) und exportiert nur Jump/Monitoring-Prefixes.

• MGMT sieht nur Infrastruktur-Prefixes (Whitelist)
• Tenants sehen MGMT nicht, außer explizit notwendig
• Auditing: MGMT-Leaks sind sicherheitskritisch

Selective Leak mit Route-Maps: Der wichtigste Safety Layer

RTs definieren, „welche VRF darf grundsätzlich“. Selective Leak definiert, „welche Prefixes wirklich“. Dafür setzt du Route-Maps am RT export (und ggf. import). Das reduziert Blast Radius bei Fehlkonfigurationen erheblich.

Whitelist für Services (Beispiel)

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
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 am RT Export binden (Pattern)

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

Import-Filtering: Wenn „Import RT“ zu breit wäre

In manchen Designs willst du zwar einen RT importieren, aber nur einen Teil der Prefixes daraus. Dann ist Import-Filtering sinnvoll. Das ist besonders hilfreich bei großen Shared-Services oder Internet-VRFs, um Tenants klein zu halten.

Import-Filter Pattern (konzeptionell)

ip prefix-list PL_SVC_IMPORT_TENANT seq 10 permit 10.10.10.0/24
route-map RM_IMPORT_SVC_TENANT permit 10

match ip address prefix-list PL_SVC_IMPORT_TENANT

Route Distinguishers: Wie du RD-Design skalierbar hältst

RD ist nicht die Policy, aber RD muss eindeutig und konsistent sein. Ein einfaches Schema ist: RD = <AS>:<VRF-ID>. Damit vermeidest du Kollisionen und erleichterst Troubleshooting.

• RD pro VRF eindeutig
• RD „sprechbar“ (Mapping zur VRF-ID)
• Keine RD-Wiederverwendung in großen Umgebungen

Operational Guardrails: Drift Detection und Route-Count Monitoring

Die größten Leaks passieren schleichend: jemand fügt einen RT import hinzu und vergisst ihn. Deshalb brauchst du Betriebsguardrails: Golden RT Sets pro VRF-Klasse und Monitoring der Route Counts pro VRF.

• Golden Config: erwartete RTs pro VRF-Kategorie
• Route Count Drift: VRF wächst plötzlich → Leak-Verdacht
• Change-Prozess: RT-Änderungen sind sicherheitsrelevant

On-Box Drift Checks

show running-config | section vrf definition
show ip route vrf TENANT_A summary
show ip route vrf SERVICES summary

Verifikation: Leak-Verhalten beweisen

Du verifizierst immer in zwei Ebenen: VPNv4/VPNv6 (RTs an den Routen) und VRF-RIB (was ist wirklich sichtbar). Bei Problemen prüfst du zuerst RTs, dann Route-Maps, dann MP-BGP Transport.

VPNv4 Routen und RTs prüfen

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

VRF-Routingtabellen prüfen

show ip route vrf TENANT_A
show ip route vrf SERVICES

Gezielte Prefix-Checks

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

Typische Pitfalls: Warum Leaks „zu groß“ werden

Die häufigsten Fehler sind: RT import zu breit, fehlende Export-Whitelist, und unkontrollierte „temporäre“ Leaks. Diese führen zu Security- und Betriebsproblemen.

• Tenant importiert mehrere Tenant-RTs → laterale Sichtbarkeit
• Services exportiert zu viele Prefixes → unnötige Angriffsfläche
• INET-VRF exportiert mehr als Default → Tenants werden „semi-transit“
• Fehlende Security Policy → Routing leak wird Traffic leak

Quick-Template: Selective Shared Services Leak

Dieses Template zeigt ein skalierbares Standardpattern: Services exportiert nur whitelisted Prefixes, Tenants importieren nur Services-RT.

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.