EVPN Fundamentals für Ops: Underlay vs. Overlay (praxisnah erklärt)

EVPN Fundamentals für Ops sind heute Pflichtwissen, weil immer mehr Metro-, Datacenter- und Provider-Netze Ethernet-Services nicht mehr als „große Bridge-Domänen“ betreiben, sondern als Overlay über ein IP-Underlay. Genau hier entsteht im Betrieb häufig Verwirrung: Ein Ticket klingt nach Layer 2 („MAC flapped“, „VLAN geht nicht“), aber die Ursache liegt im Underlay (BGP/IGP, MTU, ECMP, BFD, Transport), oder umgekehrt: Das Underlay ist stabil, doch im Overlay fehlen EVPN-Routen, VTEP-Adjacencies oder ARP/ND-Suppression funktioniert nicht. Underlay vs. Overlay (praxisnah erklärt) bedeutet deshalb nicht, zwei Schichten abstrakt zu beschreiben, sondern ein NOC-taugliches Denkmodell zu liefern: Welche Symptome gehören in welche Schicht, welche Telemetrie ist pro Schicht Pflicht, und welche „Minimalchecks“ bringen Sie in Minuten zur richtigen Fault Domain? EVPN (Ethernet VPN) ist dabei die Control-Plane (meist BGP) für Ethernet-Segmente: MACs, IPs, Multihoming und Segmentzugehörigkeit werden nicht mehr rein durch Flooding und MAC Learning im Data Plane „erraten“, sondern kontrolliert über Signalisierung verteilt. Das reduziert Flooding, begrenzt Blast Radius und macht Troubleshooting oft schneller – solange Ops weiß, wo man hinschaut. Dieser Leitfaden erklärt EVPN Fundamentals für Ops: die Rollen von Underlay und Overlay, die wichtigsten EVPN-Konzepte (VTEP, EVI, RT/RD, Type-2/Type-5 Routes, Multihoming/ESI), typische Fehlerbilder und einen Step-by-Step-Workflow zur Störungsanalyse, der ohne Vendor-spezifische CLI auskommt.

Warum Ops EVPN verstehen muss

In klassischen Layer-2-Designs werden MACs gelernt, Unbekannter Unicast geflutet, und Loops/Storms sind ein ständiges Risiko. EVPN verschiebt diese Mechanik: Das Underlay liefert IP-Konnektivität zwischen VTEPs, das Overlay transportiert Kundennetze (L2 oder L3) über Tunnels (häufig VXLAN). Damit entstehen neue Failure Modes, aber auch bessere Diagnosehebel: Statt „MAC ist weg“ fragen Sie „wurde Type-2 Route verteilt?“, statt „Broadcast-Storm“ fragen Sie „ist ARP/ND-Suppression aktiv und korrekt?“. Der größte operative Gewinn ist die klare Segmentierung in Fault Domains, wenn Sie Underlay und Overlay getrennt betrachten.

• Weniger Flooding: MAC/IP werden über Control Plane verteilt, nicht über Unknown-Unicast-Flood.
• Bessere Multihoming-Modelle: Dual-Homing ohne klassische STP-Abhängigkeit (je nach Design).
• Skalierung: viele Segmente/EVIs ohne riesige Bridge-Domänen.
• Neue Abhängigkeiten: Underlay-MTU, ECMP-Hashing, BGP-Sessions, VTEP-Reachability.

Underlay vs. Overlay: das wichtigste mentale Modell

Für Ops ist EVPN am besten als „zwei Netze übereinander“ zu verstehen. Das Underlay ist das IP-Transportnetz, das die VTEPs miteinander verbindet. Das Overlay ist das logische Kundennetz (L2 oder L3), das über Tunnels zwischen diesen VTEPs läuft. Wenn etwas „im Kunden-VLAN“ nicht funktioniert, prüfen Sie zuerst: Ist es ein Underlay-Problem (Tunnel nicht transportierbar) oder ein Overlay-Problem (Control Plane fehlt, Segment falsch zugeordnet)?

Underlay: was es ist und was es liefern muss

Das Underlay besteht aus IP-Routing (IGP oder BGP, je nach Architektur), stabiler MTU, konsistentem ECMP, und meist einem schnellen Failure-Detection-Mechanismus (z. B. BFD). Unterlay-Pflichten für Ops:

• IP-Reachability zwischen VTEPs: Loopback-/VTEP-IPs müssen routbar sein.
• MTU-Ende-zu-Ende: VXLAN/Encapsulation erzeugt Overhead; Fragmentierung oder Drops sind häufige Ursachen für „random“ Probleme.
• ECMP stabil: Underlay nutzt oft ECMP; Hashing und Symmetrie beeinflussen Performance und Pfadstabilität.
• Fast Convergence: Link/Node-Failures müssen schnell erkannt werden (BFD/IGP-Timer), sonst wirkt das Overlay „flaky“.

Overlay: was es ist und was es liefern muss

Das Overlay ist die EVPN-Control-Plane (typischerweise BGP EVPN) plus Data Plane (z. B. VXLAN). Overlay-Pflichten für Ops:

• EVPN-Routen werden korrekt verteilt: MAC/IP/Prefix-Informationen müssen ankommen.
• Segmentzuordnung stimmt: EVI/VRF/VNI/RTs müssen korrekt sein, sonst sieht ein VTEP den Service nicht.
• Multihoming-Logik stabil: ESI/DF-Wahl und Failover müssen konsistent sein.
• Flooding-Policies korrekt: ARP/ND-Suppression, BUM-Handling (Broadcast/Unknown-Unicast/Multicast) sind sauber definiert.

EVPN-Bausteine, die Ops wirklich kennen sollte

EVPN besteht aus einigen wenigen Kernbegriffen. Wenn diese sitzen, wird Troubleshooting deutlich leichter.

VTEP: der Tunnelendpunkt

Ein VTEP (VXLAN Tunnel Endpoint) kapselt und entkapselt Overlay-Traffic. Operativ ist der VTEP die Brücke zwischen Underlay und Overlay. Wenn VTEPs sich nicht erreichen, ist das Underlay betroffen. Wenn VTEPs erreichbar sind, aber keine EVPN-Routen ankommen, ist das Overlay betroffen.

EVI, VNI, VRF: Segment- und Kontextzuordnung

• EVI (EVPN Instance): logische EVPN-Instanz, oft pro Bridge-Domain oder Service.
• VNI: VXLAN Network Identifier (bei VXLAN Data Plane). Häufig trennen Designs L2-VNI und L3-VNI.
• VRF: Routing-Kontext für L3-Services (L3-VPN-ähnlich), besonders bei Type-5 Prefix-Routen.

RD/RT: Identität und Import/Export

EVPN nutzt BGP-Mechanismen: Route Distinguisher (RD) macht Routen eindeutig, Route Targets (RT) steuern Import/Export. Für Ops ist RT der häufigste „stille Fehler“: Underlay ok, BGP ok, aber Service bleibt unsichtbar, weil RT nicht importiert wird.

Route Types: welche Information wie verteilt wird

Im Betrieb reicht es, drei Route Types zu verstehen:

• Type-2 (MAC/IP Advertisement): verteilt MAC-Adressen (und optional IP-Bindings) für L2-Segmente; wichtig für Host-Reachability.
• Type-3 (Inclusive Multicast Ethernet Tag): steuert BUM-Flooding-Mechanismen (insb. bei Multicast/Ingress Replication Designs).
• Type-5 (IP Prefix): verteilt IP-Präfixe für L3-Services (Inter-VRF/VRF-Routing je nach Design).

Für die normative Grundlage von EVPN ist RFC 7432 die zentrale Referenz. Für VXLAN als Encapsulation ist RFC 7348 ein nützlicher Einstieg.

Multihoming: ESI und DF-Wahl als Ops-Fokus

EVPN unterstützt Multihoming, damit ein Customer Edge oder Access-Switch redundant an zwei (oder mehr) PE/VTEPs angeschlossen werden kann. Dafür werden ESI (Ethernet Segment Identifier) und DF (Designated Forwarder) genutzt. Wenn Multihoming instabil ist, sehen Sie oft MAC-Flapping, asymmetrische Erreichbarkeit oder BUM-Anomalien.

• ESI: identifiziert einen geteilten Ethernet-Segmentanschluss über mehrere PEs.
• DF: bestimmt, welcher PE für bestimmte Forwarding-Aufgaben zuständig ist (v. a. BUM).
• Failure Mode: inkonsistente ESI-Konfiguration oder DF-Instabilität erzeugt duplizierte oder fehlende Flooding-Paths.

MTU und Overhead: der klassische Underlay-Fallstrick

Viele „EVPN ist kaputt“-Tickets sind in Wirklichkeit MTU-Probleme im Underlay. VXLAN fügt Encapsulation-Overhead hinzu. Wenn die Underlay-MTU zu klein ist, werden große Frames gedroppt oder fragmentiert, was sich als sporadische Applikationsprobleme, Retransmissions oder „nur große Pakete gehen nicht“ äußert.

Vereinfachte MTU-Bilanz (MathML)

$\mathrm{UnderlayMTU}\ge \mathrm{OverlayMTU}+\mathrm{EncapOverhead}$

Operativ zählt nicht die perfekte Bytezahl, sondern das Prinzip: Underlay muss genug Reserve für Encapsulation haben. Wenn Sie QinQ oder zusätzliche Tags im Overlay tragen, steigt das Risiko weiter.

Typische Fehlerbilder und die richtige Schichtzuordnung

Ops gewinnt Zeit, wenn Symptome schnell der richtigen Schicht zugeordnet werden. Diese Heuristiken sind praxistauglich:

Symptome, die meist Underlay sind

• VTEP-IPs nicht erreichbar: Routing/IGP/BGP-Underlay, ACLs, ECMP-Bugs.
• Nur große Pakete scheitern: MTU/Fragmentation/Drop im Transport.
• Nach Link-Failure lange Recovery: fehlendes BFD oder langsame Convergence im Underlay.
• Asymmetrische Pfade mit Drops: ECMP/Hashing, LAG-Mitglieder inkonsistent.

Symptome, die meist Overlay sind

• Underlay ok, aber ein Segment ist „unsichtbar“: RT/RD/VNI/EVI Mapping falsch.
• MAC wird lokal gelernt, aber nicht remote bekannt: Type-2 Route fehlt oder wird nicht importiert.
• Flooding zu hoch oder zu niedrig: Type-3/Ingress Replication/Multicast-Setup falsch.
• Dual-homed Kunde flapped: ESI/DF-Probleme, Split-Horizon/ES-Policy inkonsistent.

Step-by-Step Troubleshooting für Ops: Underlay zuerst, dann Overlay

Dieser Ablauf ist so aufgebaut, dass Sie innerhalb kurzer Zeit entscheiden, ob das Problem im Underlay oder Overlay liegt, und danach gezielt tiefer gehen.

Schritt: Scope und Service-Intent klären

• Betroffenes Segment: welches VLAN/BD oder welche VRF?
• Betroffene Endpunkte: ein Host, ein Standort, ein ganzer Service?
• Multihoming? dual-homed CEs sind eine eigene Fehlerklasse.
• Traffic-Typ: nur ARP/ND? nur Unicast? nur bestimmte Größen?

Schritt: Underlay-Health prüfen

• VTEP-Reachability: sind die VTEP/Loopback-IPs end-to-end routbar?
• MTU-Plausibilität: gibt es Drops/Fragmentation-Indizien, besonders bei großen Frames?
• Convergence-Signale: BFD/IGP/BGP Underlay Sessions stabil? keine Flaps?
• Uplink-/ECMP-Health: keine auffälligen Queue Drops, keine LAG-Inkonsistenzen?

Schritt: Overlay-Control-Plane prüfen

• BGP EVPN Sessions: sind EVPN-Nachbarschaften up, werden Routen ausgetauscht?
• RT Import/Export: sieht der empfangende VTEP die Route überhaupt (Policy/RT)?
• Route Types: Type-2 vorhanden für MAC/IP? Type-5 für Prefix? Type-3 für BUM-Handling?
• MAC/IP Bindings: werden IP-MAC Bindings korrekt gelernt/advertised (ARP/ND suppression)?

Schritt: Data Plane im Overlay verifizieren

• Remote MAC Presence: ist die Ziel-MAC im Overlay bekannt oder wird unknown-unicast geflutet?
• ARP/ND Behavior: funktioniert Resolution schnell/stabil oder gibt es Retries/Timeouts?
• Multihoming-Failover: bei dual-homed: DF-Wahl stabil, keine doppelte Flooding-Quelle.

Schritt: Mitigation im Incident (ohne Nebenwirkungen)

• Underlay-Fix priorisieren: Wenn VTEP-Reachability instabil ist, bringt Overlay-Debugging wenig.
• Overlay-Policy-Fix vorsichtig: RT/Import-Fehler sind oft schnell, aber riskant; staged deployment und sofortiger Post-Check.
• Flooding kontrollieren: Bei BUM-Problemen nicht blind Storm-Control verschärfen; zuerst Ursache (Type-3/IR) klären.

Ops-Fallen: Häufige Missverständnisse in EVPN-Umgebungen

• „BGP up = Service ok“: BGP kann up sein, aber RT-Import falsch, sodass Routen nicht genutzt werden.
• „MAC Table leer = Fehler“: EVPN reduziert Flooding; lokale MAC Tables können anders aussehen als klassische Bridging-Umgebungen.
• „Unknown Unicast ist normal“: dauerhaft hoher Unknown Unicast ist in EVPN oft ein Hinweis auf fehlende Type-2 Routen oder churn.
• „Multihoming ist wie LACP“: ESI/DF-Mechanik ist anders; DF-Instabilität kann BUM- oder Blackholing-Probleme verursachen.
• „MTU ist egal“: Encapsulation macht MTU zu einem der häufigsten Underlay-Root-Causes.

Monitoring: Pflicht-Telemetrie getrennt nach Underlay und Overlay

Damit EVPN im Betrieb nicht „Black Box“ bleibt, sollte Monitoring pro Schicht strukturiert sein. So können NOCs bei Incidents schneller triagieren.

Underlay-Pflichttelemetrie

• VTEP/Loopback Reachability: Ping/Probe oder Routing-Health.
• BFD/IGP/BGP Underlay: Session-Status, Flaps, Convergence-Zeiten.
• MTU-/Drop-Indizien: Interface Drops, Fragmentation Counters (wenn verfügbar), PMTU-Probleme.
• ECMP/LAG Health: Member-Status, Hash-Imbalance-Indizien, Queue Drops.

Overlay-Pflichttelemetrie

• EVPN Route Counts: Type-2/Type-5 Anzahl pro VRF/EVI als Trend.
• MAC Move/Churn: MAC mobility Events; hilfreich gegen Flapping und Loops am Rand.
• BUM/Flooding Indikatoren: Broadcast/Unknown-Unicast/Multicast Raten im Overlay.
• Multihoming Status: ESI/DF-State, Failover-Events.

Evidence Pack für EVPN-Incidents: Was Ops immer sichern sollte

• Zeitfenster (UTC): Start, Peak, Mitigation, Stabilitätsfenster.
• Underlay: VTEP Reachability, Routing/BFD-Events, MTU/Drops, ECMP/LAG-Status.
• Overlay: EVPN Session Status, RT/Policy Hinweise, relevante Route Types (Type-2/Type-5/Type-3).
• Service-Sicht: betroffene VLAN/VRF/EVI/VNI, betroffene Endpunkte, ARP/ND-Verhalten.
• Multihoming: ESI/DF-Events und Symptom (Blackhole, Duplicate, Flood).

Outbound-Ressourcen

• RFC 7432 (BGP MPLS-Based Ethernet VPN – EVPN Grundlagen)
• RFC 7348 (VXLAN – Encapsulation-Grundlagen)
• RFC 8365 (EVPN/VXLAN über IP-Underlay – Architekturhinweise)
• IEEE 802.1Q (Bridging/VLANs – Kontext für L2-Segmente)
• RFC 9136 (EVPN Interworking/Erweiterungen – nützlich für fortgeschrittene Ops-Kontexte)

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.