Site icon bintorosoft.com

Route Targets Strategie: Skalierbare RT-Designs für viele VRFs

Red Snapper

computer network concept. 3d illustration

Route Targets (RTs) sind der Policy-Schlüssel in MPLS L3VPN und MP-BGP: Sie bestimmen, welche VRF welche VPN-Routen importiert und exportiert. In kleinen Umgebungen kann man RTs „per Gefühl“ vergeben. In großen Flotten mit hunderten oder tausenden VRFs führt das jedoch schnell zu Chaos: ungewollte Leaks, schwer auditierbare Abhängigkeiten und Change-Risiken bei jeder neuen VRF. Eine skalierbare RT-Strategie behandelt RTs wie einen IP-Adressplan: mit Namenskonzept, reservierten Bereichen, klaren Patterns (Hub-and-Spoke, Shared Services) und automatisierbaren Governance-Regeln. Dieser Artikel zeigt praxistaugliche RT-Designs, die langfristig wartbar bleiben.

RT Basics: Policy, nicht Eindeutigkeit

RD (Route Distinguisher) sorgt für eindeutige Prefixes, RT (Route Target) steuert die Policy. Für Skalierung ist das entscheidend: Du kannst RD beliebig wählen, aber RT muss semantisch konsistent sein, sonst leakst du Routen.

Merker

RD = Unique ,   RT = Policy

Skalierungsproblem: RT-Matrix explodiert ohne Pattern

Wenn jede VRF individuell mit jeder anderen sprechen soll, entsteht eine Import/Export-Matrix, die operativ nicht mehr beherrschbar ist. Skalierbare Designs reduzieren die Anzahl Beziehungen durch wiederverwendbare RT-Patterns.

Denkmodell

Policy-Komplexität ↗ mit Anzahl VRFs und individuellen Beziehungen

Governance: RTs wie einen Adressplan behandeln

Eine skalierbare RT-Strategie besteht aus klaren Regeln, die du dokumentieren und automatisieren kannst. Ziel: Neue VRFs lassen sich hinzufügen, ohne bestehende VRFs anzufassen.

Pattern 1: „One VRF – One RT“ (Baseline für Mandanten)

Für echte Mandantentrennung ist „one VRF – one RT“ der Standard: Jede VRF exportiert und importiert nur ihre eigene RT. Das minimiert Leaks und macht VRFs unabhängig.

Beispiel

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

Pattern 2: Shared Services (Hub-RT) – viele VRFs, eine definierte Abhängigkeit

Shared Services ist das wichtigste Skalierungspattern: Eine Services-VRF stellt DNS/AD/PKI/Logging bereit. Viele Tenant-VRFs importieren genau diesen Services-RT. Tenants importieren sich nicht gegenseitig.

Konzept

VRF SERVICES: RT export 65000:1000
VRF TENANT_X: RT import 65000:1000

Cisco Beispiel

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

vrf definition TENANT_201

rd 65000:201

route-target export 65000:2001

route-target import 65000:2001

route-target import 65000:1000

Pattern 3: Hub-and-Spoke (Spokes sprechen nur mit Hub)

Für SD-WAN-ähnliche Topologien, Branch-to-DC oder zentrale Internet-Exits ist Hub-and-Spoke ideal: Spokes importieren nur den Hub-RT, der Hub importiert alle Spoke-RTs. Dadurch sprechen Spokes nicht untereinander.

Konzept

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

Pattern 4: „Service-Chaining“ über mehrere Shared VRFs

Große Unternehmen haben nicht nur „Services“, sondern mehrere Service-Domänen (z. B. Security, Monitoring, Internet, Management). Ein skalierbares RT-Design nutzt dann mehrere „Hub-RTs“ mit klarer Bedeutung und möglichst wenigen Imports pro Tenant.

RT-Schema: Nummernbereiche für Skalierung (Praxisvorschlag)

Ein bewährtes Schema reserviert Bereiche, die du auch in Automatisierung abbilden kannst. Wichtig ist nicht die konkrete Zahl, sondern die konsistente Logik.

Merker

Wenige, klar benannte Hubs  +  viele isolierte Tenants  →  skalierbar

Controlled Leaks: RTs allein sind nicht genug

RTs steuern Sichtbarkeit, aber nicht automatisch Sicherheit. Zusätzlich brauchst du Export-Whitelists (Route-Maps) und Traffic-Controls (ACL/ZBFW), damit „Route sichtbar“ nicht automatisch „Traffic erlaubt“ bedeutet.

Export-Whitelist Pattern

ip prefix-list PL_SERVICES seq 10 permit 10.10.10.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


vrf definition SERVICES

route-target export 65000:1000 route-map RM_EXPORT_SERVICES

Skalierbarkeit im Betrieb: RT-Drift vermeiden

In großen Umgebungen ist nicht die Ersteinrichtung das Problem, sondern Drift: jemand fügt „temporär“ einen RT import hinzu und vergisst ihn. Deshalb brauchst du Compliance: „Golden RT Sets“ pro VRF-Klasse und regelmäßige Audits.

Audit-Commands (On-Box)

show running-config | section vrf definition
show bgp vpnv4 unicast all | include RT:

Verifikation: Beweisen, dass RTs korrekt wirken

Du verifizierst in drei Schritten: (1) VPNv4/VPNv6 Routes existieren, (2) RTs sind an den Routen, (3) VRF-RIB enthält nur erwartete Prefixes.

VPNv4 Route + RT prüfen

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

VRF-Routing prüfen

show ip route vrf SERVICES
show ip route vrf TENANT_201

Counts als Drift-Indiz

show ip route vrf TENANT_201 summary

Typische Pitfalls bei vielen VRFs

Die häufigsten Probleme entstehen durch zu breite Imports oder unkontrollierte Hubs. Besonders gefährlich sind „Super-Hubs“, die plötzlich alles sehen und damit lateral movement erleichtern.

Quick-Template: Skalierbares RT-Design (Tenant + Shared Services)

Dieses Template ist ein stabiler Startpunkt: jeder Tenant ist isoliert, alle Tenants importieren nur Shared Services. Passe RD/RTs und Prefixes 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_201

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

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