Falscher VRF Route Target: „Tenant Isolated“-Incident erkennen

Ein falscher VRF Route Target ist eine der häufigsten Ursachen für einen „Tenant Isolated“-Incident in Multi-Tenant-Netzen: Ein Mandant (Tenant) wirkt plötzlich isoliert, obwohl Links, BGP-Sessions und Underlay gesund erscheinen. Der Fehler sitzt dabei nicht auf Layer 1–3 im klassischen Sinn, sondern in der VPN-/VRF-Signalierung: Route Targets (RTs) steuern, welche VPN-Routen in eine VRF importiert und aus ihr exportiert werden. Wenn ein RT falsch gesetzt, entfernt oder vertauscht wurde, kann die VRF entweder keine Routen mehr lernen (Import-Problem) oder ihre Routen nicht mehr verteilen (Export-Problem). Aus Sicht der betroffenen Workloads ist das Ergebnis identisch: Erreichbarkeit bricht ein, Services werden „einseitig“ oder komplett unerreichbar, und Troubleshooting endet schnell in Sackgassen, weil Ping zum Gateway vielleicht noch geht, aber Inter-VRF-, Inter-Site- oder East-West-Verkehr ausfällt. Dieser Artikel zeigt, wie Sie einen „Tenant Isolated“-Incident durch falsche VRF-Route-Targets früh erkennen, welche Signale im Control Plane typisch sind, wie Sie Import/Export-Probleme sauber unterscheiden und welche Mitigation-Schritte im NOC sofort Wirkung haben. Außerdem erhalten Sie einen Dokumentationsstandard fürs Ticket, damit Backbone-, DC- und Plattformteams ohne Rückfragen zielgerichtet arbeiten können.

Grundlagen: VRF, RD und Route Target in 90 Sekunden

In MPLS L3VPNs und vielen EVPN/VXLAN-Designs wird Mandantentrennung über VRFs realisiert. Jede VRF besitzt eine eigene Routing-Tabelle und wird über BGP VPN-Address-Families (z. B. VPNv4/VPNv6 oder EVPN) mit anderen PE/Leafs synchronisiert. Dabei haben drei Begriffe eine klare Aufgabe:

• VRF: isolierte Routing-Instanz für einen Tenant oder ein Segment.
• Route Distinguisher (RD): macht gleiche Präfixe verschiedener VRFs eindeutig (Namensraum-Erweiterung), steuert aber nicht die Importlogik.
• Route Target (RT): BGP-Extended-Community, die bestimmt, welche Routen eine VRF importiert und welche sie exportiert.

Operativ ist RT der Hebel: Wenn RT-Import/Export falsch ist, wird der Tenant logisch getrennt, auch wenn das physische Netz stabil ist. Für die Protokollgrundlagen sind RFC 4364 (BGP/MPLS IP VPNs) und für EVPN RFC 7432 hilfreich.

Was bedeutet „Tenant Isolated“ im Betrieb?

„Tenant Isolated“ ist kein standardisiertes Protokoll-Event, sondern ein Incident-Muster: Ein Tenant verliert (teilweise oder vollständig) die Konnektivität zu erwarteten Zielen. In der Praxis können das sein: Erreichbarkeit zwischen Subnetzen desselben Tenants über mehrere Standorte, Zugriff auf Shared Services (DNS, NTP, Auth), Ost-West-Verkehr zwischen Applikations-Tiers oder Nord-Süd-Verkehr über zentrale Firewalls. Häufig ist das Underlay grün, die Interfaces sind up, und BGP ist „Established“ – dennoch fehlen in der VRF entscheidende Routen.

• Typischer Eindruck: „Alles sieht gesund aus, aber der Tenant kommt nirgends hin.“
• Häufige Ursache: Import-RT fehlt oder ist falsch → VRF lernt keine externen Routen.
• Alternative Ursache: Export-RT fehlt oder ist falsch → VRF sendet ihre Routen nicht, andere Sites lernen den Tenant nicht.

Frühe Signale: Woran Sie einen falschen VRF Route Target schnell erkennen

Das wichtigste Frühsignal ist nicht Paketverlust im Underlay, sondern ein Control-Plane-Bruch: Routen, die normalerweise in der VRF vorhanden sind, verschwinden oder werden nicht mehr aktualisiert. Für ein NOC lohnt sich deshalb ein Set an „Leading Indicators“, das Sie innerhalb von Minuten prüfen können.

• Routen fehlen in der VRF: Default-Route, Shared-Services-Präfixe, Inter-Site-Aggregate oder wichtige Host/Service-Präfixe sind nicht mehr im VRF-RIB/FIB.
• VPN/EVPN-Routen existieren global, aber nicht in der VRF: Die Route ist im BGP (VPNv4/EVPN) sichtbar, wird aber nicht importiert.
• Plötzlicher Rückgang der Prefix-Anzahl in der VRF: statt z. B. 300 Routen nur noch 20.
• Einseitige Erreichbarkeit: Site A erreicht Site B nicht, aber Site B erreicht Site A (typisch bei Export-Problemen einer Seite).
• Change-Korrelation: kurz vor Beginn wurde ein VRF-Template, Tenant-Policy oder RT-Mapping geändert.

Import vs. Export: Die zwei häufigsten Fehlerbilder sauber trennen

Für eine schnelle Mitigation müssen Sie unterscheiden, ob die VRF keine Routen importiert oder ob sie ihre Routen nicht mehr exportiert. Beide Fälle sehen aus Tenant-Sicht wie Isolation aus, erfordern aber unterschiedliche Fixes. Eine einfache Denkregel: Import-Probleme betreffen die eigene Sicht (was ich lerne), Export-Probleme betreffen die Fremdsicht (was andere über mich lernen).

Import-Fehler: Tenant sieht die Welt nicht mehr

• Symptome: Default/Shared-Services fehlen, Inter-Site-Routen fehlen, VRF hat nur lokale Connected/Static.
• Typische Ursache: RT-Import wurde geändert (falscher Wert, Tippfehler, falsches Tenant-Mapping), Import-Policy filtert RT weg.
• Indikator: BGP zeigt VPN-Routen mit einem RT, der nicht mehr in der VRF-Importliste steht.

Export-Fehler: Die Welt sieht den Tenant nicht mehr

• Symptome: Lokale Site funktioniert intern, aber andere Sites können die Tenant-Präfixe nicht erreichen.
• Typische Ursache: RT-Export fehlt/ist falsch, Export-Policy blockt die Route oder setzt falsche Communities.
• Indikator: Auf Remote-Peer fehlen genau die Tenant-Präfixe, während andere Tenants weiter funktionieren.

Die wichtigste Kontrollfrage: Ist die Route vorhanden, aber nicht importiert?

Ein RT-Problem ist häufig eindeutig, wenn Sie eine Route „im BGP sehen“, aber nicht in der VRF. Viele Teams verlieren Zeit, weil sie sofort MTU, Firewall oder ECMP prüfen. Der effizientere Weg ist: Erst Control Plane verifizieren, dann Data Plane.

• Schritt 1: Prüfen, ob die erwartete Route im BGP-VPN/EVPN-Kontext existiert (Control Plane).
• Schritt 2: Prüfen, ob dieselbe Route in der betroffenen VRF installiert ist (Import).
• Schritt 3: Falls nicht: Route Targets und Import-Policy prüfen.

RT-Checks, die im NOC in Minuten funktionieren

Herstellerkommandos unterscheiden sich, die Logik ist aber überall gleich. Sie benötigen drei Datenpunkte: (1) RTs, die eine VRF importiert, (2) RTs, die sie exportiert, (3) RTs, die an den betroffenen Routen tatsächlich dranhängen.

• VRF-RT-Definition: Welche RT(s) stehen in Import und Export?
• Route-Attribute: Welche RT-Extended-Communities trägt die betroffene Route?
• Policy-Overlay: Gibt es Route-Maps/Policies, die RTs setzen oder filtern?

Warum ein einziger falscher Wert so viel Schaden macht (MathML)

$\mathrm{Importiert}=\mathrm{RT\_route}\in \mathrm{RT\_import\_VRF}$

Operativ ist die Import-Entscheidung oft eine Mengenprüfung: Eine Route wird nur dann in die VRF installiert, wenn mindestens ein RT der Route in der Import-Menge der VRF enthalten ist. Ist der RT vertauscht oder fehlt, ist das Ergebnis deterministisch: keine Installation, keine Erreichbarkeit – selbst bei perfekten Links.

Typische Root Causes: Wie falsche Route Targets entstehen

Ein RT-Fehler ist selten „zufällig“. In Produktion entstehen solche Incidents meist durch Standardisierung, Automation oder Migrationsschritte, bei denen RT-Mappings falsch übernommen werden. Die häufigsten Ursachen sollten Sie als Checkliste im NOC verankern.

• Template-/Automation-Drift: ein zentrales Tenant-Template setzt RTs neu, aber ein Tenant bekommt falsche Werte.
• Vertauschter Import/Export: RT wird exportiert, aber nicht importiert (oder umgekehrt), häufig nach Refactoring.
• RT-Kollision: zwei Tenants teilen sich ungewollt denselben RT → Datenleck-Risiko oder unerwartete Route-Übernahme.
• Falsches VRF-Binding: Interface/SVI/Bridge-Domain ist in der falschen VRF, sodass Routen im falschen Tenant landen.
• Policy filtert Communities: eine Route-Policy entfernt Extended-Communities oder setzt falsche Communities.
• Migration L3VPN ↔ EVPN: bei Umstellung auf EVPN werden RTs anders modelliert (z. B. pro VNI), Mappingfehler isolieren Tenants.

Tenant-Isolation durch RT vs. „richtige“ Isolation: Sicherheitsimplikation nicht vergessen

Ein RT-Fehler kann zwei entgegengesetzte Auswirkungen haben: Isolation (zu wenig Import/Export) oder Vermischung (zu viel Import/Export). Operativ wird oft nur die Isolation gesehen, aber die Sicherheitsseite ist genauso wichtig: Wenn ein Tenant plötzlich Routen eines anderen Tenants sieht, ist das ein potenzieller Security-Incident. Deshalb gehört zur Diagnose immer auch die Frage: Fehlen nur Routen, oder tauchen fremde Routen auf?

• Isolation: Präfix-Anzahl sinkt stark, erwartete Routen fehlen.
• Vermischung: Präfix-Anzahl steigt unplausibel, neue/fremde Präfixe erscheinen in der VRF.
• Priorität: Bei Vermischung sofort Security/Incident-Response einbinden und Export/Import hart begrenzen.

Schnelle Mitigation: Was Sie tun können, bevor die Root Cause vollständig klar ist

In einem akuten „Tenant Isolated“-Incident zählt Stabilisierung. Gute Mitigation ist reversibel, reduziert Blast Radius und stellt die erwartete Konnektivität wieder her, ohne neue Risiken zu öffnen. Je nach Befund sind das typische Sofortmaßnahmen.

• RT-Import korrigieren: Wenn klar ist, dass die VRF den falschen Import-RT hat, ist das der direkteste Fix.
• RT-Export korrigieren: Wenn Remote Sites den Tenant nicht mehr sehen, Export-RT prüfen und zurücksetzen.
• Policy temporär vereinfachen: Wenn eine Route-Policy RTs entfernt oder falsch setzt, kurzfristig auf eine bekannte „safe baseline“ zurück.
• Rollback des letzten Changes: Wenn Change-Korrelation stark ist und Fix unsicher, ist Rollback oft die schnellste Risikoreduktion.
• Scope reduzieren: Bei Verdacht auf Vermischung: Import/Export auf minimal notwendige RTs begrenzen, bis sauber validiert.

Diagnose-Datenpunkte für ein sauberes Ticket

RT-Incidents eskalieren häufig an Plattform-/Network-Engineering oder an ein Team, das zentrale Tenant-Policies verwaltet. Damit die Übergabe ohne Rückfragen gelingt, brauchen Sie standardisierte Evidence. Ein gutes Ticket beschreibt nicht nur „Tenant hat keine Connectivity“, sondern zeigt, welche Routen fehlen, welche RTs gesetzt sind und wo die Importlogik bricht.

• Tenant/VRF Identität: VRF-Name/ID, ggf. VNI/Segment-ID, Standort(e), betroffene Interfaces.
• Symptom-Scope: welche Subnetze/Services sind betroffen, nur inter-site oder auch lokal?
• Control-Plane Evidence: erwartete Route im BGP (VPN/EVPN) vorhanden ja/nein; Route in VRF-RIB/FIB vorhanden ja/nein.
• RT-Information: import RT(s), export RT(s), RT(s) der betroffenen Route.
• Policy-Overlay: relevante Route-Policies/Maps, die Communities setzen/filtern.
• Timeline: Startzeit, erste beobachtete Abweichung, relevante Changes/Deployments, Mitigation-Zeitpunkte.
• Risiko-Hinweis: nur Isolation oder auch Route-Leak/Vermischung beobachtet?

Prävention: Guardrails gegen falsche Route Targets

RT-Fehler lassen sich durch technische Guardrails und saubere Prozesse deutlich reduzieren. Besonders wirksam sind Maßnahmen, die Drift erkennen, bevor Nutzer betroffen sind, und die verhindern, dass ein einzelner Template-Fehler netzweit ausgerollt wird.

• RT-Inventory als Source of Truth: zentrale Liste, welcher Tenant welche RTs importiert/exportiert (inkl. Change-Historie).
• Pre-/Post-Change Validierung: nach Tenant-Changes automatisch prüfen: Prefix-Anzahl in VRF, Reachability zu Shared Services, Import/Export-RTs.
• Canary Rollouts: Templates zuerst auf wenige Geräte/Tenants, dann schrittweise ausrollen.
• Drift Detection: kontinuierlicher Abgleich der laufenden Konfiguration gegen Sollwerte (RTs, VRF-Bindings, Policies).
• Safety Limits: Alarme bei „Prefix-Anzahl fällt um X%“ oder „neue fremde Präfixe tauchen in VRF auf“.
• Least Privilege Import: VRFs importieren nur die RTs, die sie wirklich brauchen; keine breiten Wildcard-Imports.

Baseline-Alarm auf Routenanzahl als Frühsignal (MathML)

$\mathrm{DropRate}=\frac{\mathrm{BaselineRoutes}–\mathrm{CurrentRoutes}}{\mathrm{BaselineRoutes}}$

• Praxis: Ein Alarm bei z. B. > 30% DropRate innerhalb weniger Minuten ist oft ein besserer Indikator für RT-Probleme als reine Link-Metriken.
• Nutzen: Sie erkennen „Tenant Isolated“ schon im Control Plane, bevor Applikationen eskalieren.

Outbound-Links für Standards und vertiefende Referenz

• RFC 4364 (BGP/MPLS IP VPNs) für VRF, RD, Route Target und Import/Export-Mechanik.
• RFC 7432 (EVPN) für EVPN-Route-Typen und Multi-Tenant-Segmentierung im Datacenter.
• RFC 4760 (Multiprotocol Extensions for BGP-4) für die MP-BGP-Grundlage, auf der VPNv4/VPNv6 und EVPN aufsetzen.
• RFC 4271 (BGP-4) für grundlegende BGP-Mechanik und Session-Verhalten, das bei VRF-Distribution relevant ist.

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.