EVPN-VXLAN Troubleshooting: Warum es anders ist als klassisches VLAN

EVPN-VXLAN Troubleshooting ist anders als klassisches VLAN-Troubleshooting, weil sich die Fehlerdomäne von „ein gemeinsames Layer-2-Segment“ zu einem Overlay-Transport über ein IP-Underlay verschiebt. In klassischen VLAN-Designs entstehen die meisten Probleme durch lokale Bridging-Mechanik: falsche VLAN-Zuordnung am Port, STP/Loop-Themen, MAC-Learning, Flooding, falsch gesetzte MTU oder ein defekter Trunk. In EVPN-VXLAN kommt eine zweite Welt hinzu: Das Underlay muss die VTEPs zuverlässig verbinden, und das Overlay muss die korrekten EVPN-Routen (MAC/IP/Prefix) signalisieren, damit Traffic nicht mehr „erraten“ (Flooding), sondern kontrolliert zugestellt wird. Dadurch ändern sich die Symptome, die Messpunkte und die Reihenfolge der Checks. Ein Ticket wie „Host im VLAN 120 erreicht Host B nicht“ ist in EVPN-VXLAN nicht nur „VLAN falsch“, sondern kann bedeuten: VTEP-IP nicht erreichbar, MTU im Underlay zu klein, EVPN Route Target wird nicht importiert, VNI-Mapping stimmt nicht, Type-2 MAC/IP-Routen fehlen, ARP/ND-Suppression liefert stale Bindings oder Multihoming/DF-Wahl erzeugt asymmetrisches Forwarding. Wer das Troubleshooting weiterhin wie im klassischen VLAN angeht, verbringt Zeit mit den falschen Tools und zieht falsche Schlüsse. Dieser praxisnahe Leitfaden erklärt, warum EVPN-VXLAN Troubleshooting anders ist, welche Failure Modes typisch sind, welche Telemetrie Pflicht ist und liefert ein Step-by-Step-Runbook, mit dem Ops in wenigen Minuten Underlay vs. Overlay sauber trennt und zielgerichtet zur Root Cause kommt.

Warum EVPN-VXLAN konzeptionell anders ist als klassisches VLAN

Der Kernunterschied ist die Aufteilung in zwei Schichten:

• Underlay: IP-Transport zwischen VTEPs (Routing, ECMP, MTU, Fast Convergence).
• Overlay: logische Segmente (VLAN/Bridge-Domain/VRF) über VXLAN-Tunnels, gesteuert durch EVPN (BGP).

Im klassischen VLAN teilen sich alle Teilnehmer dasselbe Broadcast-Domain-Verhalten. In EVPN-VXLAN ist das Segment zwar logisch ähnlich, aber die Zustellung läuft über Tunnels und Control Plane. Dadurch entstehen neue „stille“ Fehler: Das Underlay kann grün sein, aber ein Segment bleibt unsichtbar, weil Route Targets nicht passen. Oder das Overlay ist korrekt, aber große Frames droppen im Underlay wegen MTU. Für die normativen Grundlagen sind RFC 7432 (EVPN), RFC 7348 (VXLAN) und als Architekturhinweis RFC 8365 (EVPN/VXLAN über IP-Underlay) hilfreich.

Was im klassischen VLAN-Troubleshooting meist reicht – und warum es bei EVPN nicht genügt

In klassischen VLAN-Netzen ist Troubleshooting oft „port-zentriert“: stimmt VLAN am Port, stimmt Trunk, stimmt STP, stimmt MAC-Learning. Diese Checks bleiben in EVPN-VXLAN relevant an den Edge-Ports, aber sie erklären nicht mehr den gesamten Pfad. Denn zwischen zwei Edge-Ports liegt kein einfacher Trunk, sondern ein Tunnel über ein geroutetes Underlay.

• Klassisch: VLAN-Tagging/Trunk/STP/MAC Table → meist ausreichende Fehlerlokalisierung.
• EVPN-VXLAN: zusätzlich VTEP-Reachability, EVPN Routen, RT/RD, VNI/VRF Mapping, BUM-Handling, Multihoming.

Die neuen Fault Domains in EVPN-VXLAN

Für Ops ist entscheidend, Tickets schnell der richtigen Fault Domain zuzuordnen. In EVPN-VXLAN sind die Domains typischerweise:

• Edge (klassisch): Access-Port, VLAN↔VNI Mapping, LACP, Port-Security, lokale MTU.
• Underlay: Routing zwischen VTEPs, ECMP, MTU/Fragmentation, BFD/Convergence.
• EVPN Control Plane: BGP EVPN Sessions, Route Targets/Policies, Route Types (2/3/5).
• Overlay Data Plane: VXLAN Encapsulation/Decapsulation, VNI, BUM-Replikation, ARP/ND-Suppression.
• Multihoming (wenn vorhanden): ESI/DF, Split-Horizon, Aliasing, Failover.

Warum Symptome anders aussehen: typische EVPN-VXLAN-„Signaturen“

Einige Fehlerbilder wirken in EVPN-VXLAN ähnlich wie in VLANs, haben aber andere Ursachen. Diese Muster sind im Betrieb besonders häufig.

Signatur 1: „Underlay grün, Segment unsichtbar“

• Symptom: VTEP-IPs erreichbar, aber Hosts in einem Segment sehen sich nicht.
• Häufige Ursache: RT Import/Export falsch, VNI/EVI Mapping inkonsistent, EVPN Route fehlt.
• Unterschied zu VLAN: im VLAN wäre das meist ein Trunk/VLAN-Tagging-Fehler; in EVPN ist es oft Policy/Intent.

Signatur 2: „Nur große Pakete gehen nicht“

• Symptom: kleine Pings ok, Applikationen brechen ab, Retransmissions steigen.
• Häufige Ursache: Underlay MTU zu klein für VXLAN-Overhead, Drops/Fragmentation.
• Unterschied zu VLAN: im VLAN ist MTU oft lokal; in EVPN muss MTU end-to-end im Underlay stimmen.

MTU-Bilanz als Faustregel (MathML)

UnderlayMTU ≥ OverlayMTU + EncapOverhead

Signatur 3: „Unknown Unicast/BUM zu hoch“

• Symptom: Flooding steigt, Broadcast/Unknown-Unicast-Spikes, ggf. Storm-Control greift.
• Häufige Ursache: fehlende Type-2 MAC/IP-Routen, falsche Type-3/BUM-Replikation, ARP/ND-Suppression off oder inkonsistent.
• Unterschied zu VLAN: im VLAN ist Flooding „normaler“; in EVPN sollte es oft deutlich geringer sein – hoher BUM ist ein Hinweis auf Control-Plane-/Overlay-Probleme.

Signatur 4: „MAC flapped ohne sichtbaren Loop“

• Symptom: MAC move/flap Events, intermittierende Erreichbarkeit.
• Häufige Ursache: Multihoming ESI/DF/Split-Horizon/Aliasing, LACP-Inkonsistenz, Host Mobility Events.
• Unterschied zu VLAN: klassisch wäre Loop/STP die Top-Hypothese; in EVPN ist Multihoming häufig wahrscheinlicher.

EVPN Route Types für Ops: Was Sie beim Troubleshooting wirklich prüfen müssen

Sie müssen nicht jedes Detail kennen, aber Sie sollten wissen, welche Route Type für welches Symptom relevant ist:

• Type-2 (MAC/IP Advertisement): entscheidend für Host-Reachability in L2-VNIs; wenn Type-2 fehlt, sehen sich Hosts nicht oder Flooding steigt.
• Type-3 (Inclusive Multicast Ethernet Tag): steuert, wie BUM-Traffic repliziert wird (Ingress Replication/Multicast); falsch → BUM-Probleme.
• Type-5 (IP Prefix): relevant für L3-VRF-Routing; fehlt → Inter-VRF/Prefix-Reachability kaputt, obwohl L2 ok sein kann.

Step-by-Step Runbook: EVPN-VXLAN Troubleshooting in der richtigen Reihenfolge

Die Reihenfolge ist der Unterschied: In EVPN-VXLAN ist „Underlay zuerst“ meist die schnellste Strategie. Erst wenn Underlay plausibel ist, lohnt sich tieferes Overlay-Debugging.

Schritt: Problem sauber scopen

• Betroffener Scope: ein Host, eine VLAN/VNI, eine VRF, ein Standort, oder mehrere?
• Traffic-Typ: nur ARP/ND, nur Unicast, nur große Frames, nur Multicast?
• Multihoming vorhanden: dual-homed CE/Access ist ein eigener Fehlerbereich.
• Zeitkorrelation: Change/Failover/Repair? häufige Trigger in EVPN.

Schritt: Underlay-Health verifizieren

• VTEP-Reachability: VTEP/Loopback-IPs müssen routbar und stabil sein (keine Flaps).
• MTU prüfen: Drops/Fragmentation-Indizien, „nur große Pakete“ testen.
• ECMP/LAG Health: Member-Status, Queue Drops, Hash-Imbalance-Indizien.
• Fast Convergence: BFD/IGP-Timer plausibel, sonst wirkt Overlay „instabil“.

Schritt: EVPN Control Plane prüfen

• BGP EVPN Sessions: sind Nachbarn up, werden Updates ausgetauscht?
• RT Import/Export: sieht der empfangende VTEP die Routen für dieses Segment/VRF?
• Route Types: Type-2 vorhanden für betroffene MACs/IPs, Type-5 für Präfixe, Type-3 für BUM.
• Route Counts/Trends: plötzliche Drops oder Spikes können auf Policy oder Control-Plane-Flaps hinweisen.

Schritt: Overlay Data Plane verifizieren

• VLAN↔VNI Mapping: stimmt die Zuordnung an allen relevanten VTEPs?
• Remote MAC Presence: ist die Ziel-MAC remote bekannt oder wird unknown-unicast geflutet?
• ARP/ND-Suppression: sind Bindings korrekt und frisch oder stale?
• BUM-Replikation: ist das Flooding-Verhalten passend (IR/Multicast)?

Schritt: Multihoming (falls vorhanden) separat prüfen

• ESI konsistent: alle PEs desselben Segments müssen identische ESI-Werte haben.
• DF-State stabil: keine DF-Change-Spikes, Failover-Events nachvollziehbar.
• LACP konsistent: CE-LAG und PE-Konfiguration harmonieren; Member-Ports haben identische Policies.
• Split-Horizon korrekt: keine Duplikate/Loops, BUM nicht doppelt.

Mitigation: Was im Incident hilft – und was schadet

Viele klassische VLAN-Reflexe können in EVPN-VXLAN kontraproduktiv sein. Zwei Beispiele: (1) Storm-Control „hart runterdrehen“ kann legitimen ARP/ND unterdrücken und die Situation verschlechtern, wenn die Ursache fehlende Type-2/Type-3 Routen ist. (2) „MAC Table flush“ kann kurzfristig helfen, aber erhöht Flooding und erzeugt Churn, wenn die Control Plane instabil ist. Besser ist zielgerichtete Mitigation:

• Bei MTU-Indizien: Underlay MTU korrigieren oder temporär Overlay MTU reduzieren, falls möglich.
• Bei RT/Policy-Fehlern: Import/Export korrigieren, staged deployen, sofortige Post-Checks.
• Bei Multihoming-Instabilität: DF/ESI stabilisieren; im Zweifel temporär Single-Active-Verhalten erzwingen (konzeptionell) bis Root Cause behoben ist.
• Bei BUM-Problemen: Type-3/IR/Multicast-Setup prüfen statt blind Flooding zu drosseln.

Validierung nach Fix: Damit EVPN-VXLAN nicht „wieder kippt“

Nach einem Fix ist die wichtigste Frage: Ist die Ursache wirklich weg oder nur das Symptom? Eine robuste Validierung prüft sowohl Underlay als auch Overlay.

• Underlay stabil: VTEP-Reachability ohne Flaps, keine Drops/Fragmentation-Indizien.
• EVPN stabil: Sessions stabil, Route Counts plausibel, keine Withdraw-Spikes.
• Segment ok: Type-2 Routen für relevante Hosts vorhanden, Unicast stabil, BUM im Normalband.
• MTU-Test: große Frames funktionieren end-to-end.
• Stabilitätsfenster: 10–30 Minuten Monitoring ohne MAC move/churn Spikes (bei kritischen Services länger).

Stabilitätskriterium als Gate (MathML)

Stable ⇐ vtep_reachability_ok ∧ evpn_sessions_ok ∧ mac_move_events≈0

Monitoring: Pflicht-Telemetrie, die klassisches VLAN nicht braucht

Damit EVPN-VXLAN im Betrieb nicht zur Black Box wird, brauchen Sie zusätzliche Telemetrie – strukturiert nach Underlay und Overlay.

Underlay-Pflichttelemetrie

• VTEP/Loopback Reachability: aktive Probes oder Routing-Health.
• BFD/Convergence: Detection/Repair-Zeiten, Flap-Events.
• MTU-/Drop-Indikatoren: Drops, Fragmentation/PMTU-Anzeichen.
• ECMP/LAG: Member Health, Queue Drops, Hash-Imbalance-Indizien.

Overlay-Pflichttelemetrie

• EVPN Route Counts: Type-2/3/5 pro EVI/VRF als Trend.
• MAC Mobility/Churn: MAC move events, besonders bei Multihoming.
• BUM-Raten: Broadcast/Unknown-Unicast/Multicast als Indikatoren für fehlende Control-Plane.
• DF/ESI Events: DF-Changes, ESI Consistency Checks (wenn Multihoming).

Evidence Pack: Was Sie bei EVPN-VXLAN-Tickets immer sammeln sollten

• Zeitfenster (UTC): Start, Peak, Fix, Stabilitätsfenster.
• Scope: betroffene VLAN/VNI/EVI/VRF, betroffene VTEPs, betroffene Endpunkte.
• Underlay: VTEP-Reachability, MTU/Drops, ECMP/LAG, BFD/Convergence.
• Overlay: EVPN Sessions, RT Import/Export Hinweise, relevante Route Types (2/3/5).
• Data Plane: MAC move/churn, BUM-Raten, ARP/ND-Verhalten.
• Mitigation: welche Maßnahmen, welcher Effekt (Before/After).

Outbound-Ressourcen

• RFC 7432 (EVPN – Control Plane Grundlagen)
• RFC 7348 (VXLAN – Encapsulation)
• RFC 8365 (EVPN/VXLAN über IP-Underlay – Architektur)
• RFC 9136 (EVPN Erweiterungen – fortgeschrittene Ops-Kontexte)
• IEEE 802.1Q (Bridging/VLAN Kontext für Edge-Segmente)

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.