VXLAN/EVPN Debugging ist im modernen Data-Center- und Campus-Design eine der wichtigsten Troubleshooting-Disziplinen, weil VXLAN (Virtual Extensible LAN) und EVPN (Ethernet VPN) häufig das zentrale Overlay für Layer-2- und Layer-3-Segmentierung bilden. Wenn hier etwas hakt, wirken die Symptome oft wie „klassische“ Probleme – ARP spinnt, VLANs sind „kaputt“, Routing ist instabil oder einzelne Workloads sind nicht erreichbar – obwohl Underlay-Routing, Interfaces und sogar BGP-Sessions scheinbar grün sind. Der Grund: In VXLAN/EVPN sind mehrere Ebenen strikt voneinander abhängig. Erstens das Underlay (IP-Reachability zwischen VTEPs, MTU, ECMP), zweitens der Overlay-Control-Plane (BGP EVPN Routes, Route Targets, ESI bei Multihoming), drittens das lokale Mapping (VNI ↔ VLAN/VRF, SVI/Anycast Gateway, ARP/ND-Suppression) und viertens der eigentliche Data-Plane-Tunnel (UDP/4789, VTEP-IP, Encapsulation-Overhead). Professionelles VXLAN/EVPN Debugging bedeutet daher: Sie arbeiten nicht nach Bauchgefühl, sondern bauen eine Beweiskette auf, die in Minuten zeigt, ob das Problem im VNI Mapping, in den BGP EVPN Routes oder am Anycast Gateway entsteht – und Sie vermeiden dabei typische Nebenwirkungen wie MAC-Flapping, Duplicate IPs oder asymmetrische Pfade durch falsch platzierte Gateways.
Mentales Modell: Underlay, Overlay und lokale Mapping-Logik trennen
Der schnellste Weg zu stabilen Ergebnissen ist eine klare Trennung der Fehlerdomänen. In VXLAN/EVPN können alle drei Ebenen gleichzeitig „halb funktionieren“, was selektive Ausfälle erzeugt.
- Underlay: IP-Connectivity zwischen VTEPs (Leafs/Edges), Routing (OSPF/IS-IS/BGP), MTU, ECMP, Drops/Errors, UDP-Transport
- Overlay Control Plane: MP-BGP EVPN (AFI/SAFI), Route Types, Route Targets, Next-Hop, Route Reflection
- Lokales Mapping: VLAN ↔ VNI (L2VNI), VRF ↔ VNI (L3VNI), SVI/Anycast Gateway, ARP/ND-Suppression, Flood-and-Learn vs. Control-Plane-Learning
Für VXLAN ist RFC 7348 eine grundlegende Referenz. Für EVPN ist RFC 7432 zentral; für NVO3/EVPN-Designkontext ist auch RFC 8365 hilfreich.
Symptomklassifikation: Welche Fehlerbilder typisch für VXLAN/EVPN sind
Bevor Sie in Details gehen, klassifizieren Sie das Symptom. Das spart Zeit, weil es die wahrscheinlichste Ebene identifiziert.
- Nur ein Segment/VLAN betroffen: häufig L2VNI/VLAN Mapping, RT-Import, oder fehlende EVPN Route Type 2/3
- Nur Inter-VLAN/Inter-Subnet Kommunikation betroffen: häufig L3VNI/VRF Mapping, Anycast GW/SVI, oder Route Type 5 (IP Prefix) fehlt
- Nur einzelne Hosts betroffen: MAC/IP Route Type 2 fehlt, Duplicate IP, ARP/ND-Suppression inkonsistent, Host-Move ohne sauberes Withdraw
- „Ping geht, TCP nicht“: MTU/Fragmentation, ECMP „schlechter Pfad“, asymmetrische Pfade über Border/Firewall, oder Drops in Hardware-Encap
- MAC-Flapping / Duplicate MAC: Multihoming/ESI inkonsistent, falsche LACP-Bundle-Zuordnung, oder L2 Loop außerhalb des EVPN-Fabrics
VNI Mapping Debugging: L2VNI, L3VNI und die häufigsten Drift-Fehler
VNI Mapping ist die lokale Übersetzung zwischen klassischen Ethernet-/IP-Konzepten und VXLAN-Overlay-Identitäten. In der Praxis sind das zwei Hauptarten:
- L2VNI: mappt ein VLAN (Broadcast-Domain) in einen VXLAN Network Identifier
- L3VNI: mappt eine VRF (Routing-Domain) in einen VNI für integriertes Routing im Overlay
Typische L2VNI Mapping-Probleme
- VLAN existiert lokal, aber falsche VNI: Hosts im selben VLAN sehen sich standortübergreifend nicht
- VNI existiert, aber VLAN fehlt: EVPN Routes werden gelernt, aber nicht in ein lokales Segment „eingehängt“
- Flood-List/Replication falsch: BUM (Broadcast/Unknown Unicast/Multicast) kommt nicht an oder flutet zu breit
Typische L3VNI/VRF Mapping-Probleme
- Inter-VLAN Routing geht lokal, aber nicht remote: VRF ist lokal ok, aber L3VNI fehlt oder ist falsch verknüpft
- Route Type 5 wird gelernt, aber nicht installiert: Import RT fehlt oder Next-Hop/Resolution scheitert
- Anycast GW inkonsistent: gleiche Gateway-IP/MAC wird nicht auf allen Leafs korrekt genutzt
BGP EVPN Routes verstehen: Route Types als Diagnose-Anker
EVPN ist nicht „ein Routing-Update“, sondern eine Sammlung klarer Route Types. Im Debugging ist das ein Vorteil: Sie können sehr gezielt prüfen, welcher Route Type fehlt oder falsch ist.
- Route Type 2 (MAC/IP Advertisement): verteilt MACs und optional zugehörige IPs (ARP/ND-Suppression, Host Reachability)
- Route Type 3 (IMET): Inclusive Multicast Ethernet Tag – steuert BUM-Flooding/Replication pro VNI
- Route Type 5 (IP Prefix): verteilt IP-Präfixe für L3VPN-/VRF-Routing im EVPN-Kontext
Eine saubere Referenz für EVPN-Grundmechaniken ist RFC 7432. Wenn Sie BGP-Basics (Session, Update, Next-Hop) auffrischen wollen, ist RFC 4271 die stabile Basis.
Wie Route Types in der Praxis „kaputt“ wirken
- Type 2 fehlt: Host A kann Host B nicht erreichen, ARP bleibt „incomplete“, oder es gibt Unknown-Unicast-Flooding
- Type 3 fehlt: BUM bleibt lokal, DHCP/ARP Broadcasts erreichen remote Leafs nicht (je nach Design), oder Flooding ist unvollständig
- Type 5 fehlt: Inter-VRF/Inter-Subnet Reachability fehlt, obwohl Gateways lokal funktionieren
Anycast Gateway Debugging: Wenn L3 „komisch“ wird
Anycast Gateway (häufig: gleiche SVI-IP und gleiche virtuelle Gateway-MAC auf mehreren Leafs) ist ein Schlüsselbaustein für verteiltes Routing. Es reduziert Hairpinning und macht „First Hop“ lokal. Gleichzeitig entstehen typische Fehlerbilder, wenn Anycast nicht konsistent ist.
Typische Anycast-Gateway-Probleme
- Uneinheitliche Gateway-MAC: Hosts lernen unterschiedliche MACs für die gleiche Gateway-IP → ARP churn, sporadische Connectivity
- SVI nicht überall aktiv: Gateway-IP existiert nur auf einigen Leafs → Traffic wird zu falschen Leafs gezogen
- ARP/ND-Suppression inkonsistent: Type-2 Routes fehlen oder IP/MAC Bindings sind nicht verteilt → ARP Flooding oder ARP Blackholes
- Default Route/VRF Route Leak: falsche Route Type 5 Imports/Exports → Traffic geht in falsche VRF oder falschen Border
Beweisfragen für Anycast-GW
- Ist die Gateway-IP in der richtigen VRF auf allen relevanten Leafs aktiv?
- Ist die Gateway-MAC identisch (Designvorgabe) und wird korrekt als Default-GW genutzt?
- Existieren für betroffene Hosts Type-2 MAC/IP Routen, sodass ARP/ND-Suppression funktionieren kann?
Underlay-Checks: VTEP Reachability, UDP/4789 und MTU
VXLAN kapselt Ethernet/IP in UDP (typischerweise Port 4789). Viele Overlay-Probleme sind in Wahrheit Underlay-Probleme: Drops auf einem ECMP-Pfad, MTU zu klein, Filter blockt UDP/4789, oder PMTUD ist gestört. Genau deshalb gehört Underlay in jedes VXLAN/EVPN Debugging, auch wenn BGP EVPN „up“ ist.
- VTEP-IP Reachability: VTEP zu VTEP pingbar? Routing stabil? Keine asymmetrischen Blackholes?
- UDP/4789 erlaubt: Firewalls/ACLs/CoPP blocken nicht, insbesondere nicht nur in eine Richtung
- MTU/Overhead: VXLAN-Encap erhöht Framegröße; zu kleine MTU erzeugt selektive Drops (klein ok, groß kaputt)
- ECMP „schlechter Pfad“: ein Underlay-Link hat Errors/Drops → nur Flows auf diesem Pfad leiden
Wenn Sie MTU/PMTUD als Ursache vermuten, sind RFC 1191 (IPv4 PMTUD) und RFC 8201 (IPv6 PMTUD) hilfreiche Referenzen.
Evidence Pack: Welche Daten Sie im Incident immer sammeln sollten
VXLAN/EVPN lässt sich schnell debuggen, wenn Sie konsequent dieselben Daten sichern. Das verhindert „Tool-Hopping“ und macht Postmortems belastbar.
- Lokales Mapping: VLAN↔VNI, VRF↔L3VNI, SVI/Anycast-Konfiguration, aktive VTEP-IP
- EVPN Route Sicht: Type 2/3/5 für betroffene VNIs/VRFs, Route Targets, Next-Hop, bestpath/advertised
- Underlay Health: VTEP Reachability, MTU, Interface Errors/Drops, ECMP Member Health
- Host-Beispiele: 3–5 betroffene Hosts: IP, MAC, VLAN/VNI, Leaf/VTEP, Zeitpunkt, Symptom
- State/Anomalien: MAC-Flap Logs, Duplicate IP Events, ARP/ND Cache Verhalten, BUM Flooding Indikatoren
Typische Root-Cause-Muster und schnelle Fix-Richtungen
Hosts im gleichen Segment sehen sich nicht standortübergreifend
- Wahrscheinliche Ursachen: L2VNI/VLAN Mapping falsch, Type-2 MAC Route fehlt, Type-3 IMET fehlt, VTEP Reachability gestört
- Nachweise: Existiert Type-2 für den Host? Existiert Type-3 für die VNI? Ist UDP/4789 end-to-end erreichbar?
- Fix-Richtung: Mapping konsistent machen, EVPN RTs prüfen, Underlay MTU/UDP freigeben
Inter-VLAN Routing bricht nur zwischen Leafs/Standorten
- Wahrscheinliche Ursachen: L3VNI/VRF Mapping fehlt, Type-5 Prefix Route fehlt/kein Import, Anycast GW inkonsistent
- Nachweise: Type-5 Route vorhanden und importiert? Next-Hop resolvable? SVI/Gateway identisch auf allen Leafs?
- Fix-Richtung: VRF RT Imports/Exports korrigieren, L3VNI aktivieren, Next-Hop/Underlay Reachability sicherstellen
MAC-Flapping und „Duplicate“ Events im EVPN
- Wahrscheinliche Ursachen: Multihoming/ESI inkonsistent, falsche LACP/Bundle-Zuordnung, Loop außerhalb der Fabric, Host bewegt sich ohne sauberes Withdraw
- Nachweise: Kommen Type-2 Updates abwechselnd von unterschiedlichen VTEPs? Gibt es ESI- oder LAG-Inkonsistenzen?
- Fix-Richtung: Multihoming-Design konsistent (ESI, LACP), Loops am Rand beseitigen, Edge-Guards aktivieren
„Ping geht, TCP ist langsam“ oder sporadische Timeouts
- Wahrscheinliche Ursachen: MTU/PMTUD Blackholes, ECMP schlechter Pfad, Queueing/Microbursts im Underlay, asymmetrische Pfade über Border/Firewall
- Nachweise: Retransmissions steigen? Große Pakete droppen? Nur bestimmte Flows betroffen (Flow Pinning)?
- Fix-Richtung: MTU konsistent, ECMP Member Health, QoS/Buffering prüfen, stateful Symmetrie sicherstellen
PCAP gezielt nutzen: VXLAN/EVPN sichtbar machen
Wenn Logs und Tabellen nicht reichen, ist ein gezielter Capture extrem wirksam. Wichtig ist, nicht „alles“ zu capturen, sondern die relevanten Punkte: am Host-Port (inner traffic), am Underlay (VXLAN UDP/4789), und optional am Border/Firewall. Für Analyse-Workflows sind Wireshark und die tcpdump Manpage praktische Referenzen.
- VXLAN Encap: UDP/4789, VNI, Outer Src/Dst (VTEP IPs), Inner Src/Dst (MAC/IP)
- MTU-Indizien: Fragmentation, ICMP „Packet Too Big“, TCP Retransmissions/Timeouts
- ARP/ND: ARP Requests ohne Reply (Suppression kaputt) oder zu viel Flooding (Type-2/3 fehlen)
Runbook-Baustein: VXLAN/EVPN Debugging in 15 Minuten
- Minute 0–3: Scope definieren: L2 (gleicher VNI) oder L3 (Inter-VRF)? Betroffene Hosts (IP/MAC/VLAN), betroffene Leafs/VTEPs, Zeitpunkt und Symptom sichern.
- Minute 3–6: Underlay beweisen: VTEP↔VTEP Reachability, UDP/4789 nicht gefiltert, MTU/Errors/Drops/ECMP Member Health prüfen.
- Minute 6–9: Mapping prüfen: VLAN↔L2VNI korrekt? VRF↔L3VNI korrekt? SVI/Anycast GW konsistent?
- Minute 9–12: EVPN Routes prüfen: Type-2 für betroffene Hosts vorhanden? Type-3 IMET für VNI vorhanden? Type-5 Prefix Routes für VRF-Routing vorhanden und importiert (RT)?
- Minute 12–15: Side Effects prüfen: MAC-Flaps/Duplicate IP, Multihoming/ESI Inkonsistenz, Asymmetrie über Borders/Firewalls. Minimalen Fix anwenden und mit denselben Host-Flows verifizieren.
Hygiene Checks: Damit VXLAN/EVPN im Betrieb stabil bleibt
- Source-of-Truth für Mapping: VLAN/VNI/VRF/L3VNI zentral definieren, automatisiert validieren, Drift-Checks
- EVPN Route Telemetrie: Counts pro Type (2/3/5), RT-Imports, „missing IMET“ Alarme, ungewöhnliche Withdraw-Spikes
- Anycast Governance: Gateway-IP/MAC konsistent, SVI überall aktiv wo nötig, ARP/ND-Suppression getestet
- Underlay Baselines: MTU konsistent, UDP/4789 Policy klar, ECMP Member Health Monitoring, Drops/Errors früh alarmieren
- Change-Disziplin: VNI/RT-Änderungen als Events markieren, Canary-Tests, Rollback bereit
Weiterführende Quellen für Standards und Praxis
- RFC 7348 für VXLAN (Encapsulation, VNI, UDP Transport)
- RFC 7432 für EVPN (Route Types, Control Plane Mechanik)
- RFC 8365 für NVO3/EVPN Designkontext (Overlay-Modelle, Terminologie)
- RFC 4271 für BGP-4 Grundlagen (Sessions, Updates, Next-Hop)
- Wireshark Dokumentation für VXLAN/EVPN-Analyse (VNI, Encapsulation, Timing, Retransmissions)
- tcpdump Manpage für effiziente Captures und Filterpraxis im Incident
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.
