Multi-Vendor-EVPN-Interop: Häufigste Probleme und wie man testet

Multi-Vendor-EVPN-Interop ist in der Praxis kein „einmal konfigurieren und vergessen“-Thema, sondern ein wiederkehrendes Ops-Risiko: Zwei Geräte sprechen zwar beide EVPN und VXLAN, aber sie interpretieren Details unterschiedlich, haben abweichende Defaults oder unterstützen bestimmte Optionen nur teilweise. Das Resultat sind Störungen, die im NOC wie „mysteriös“ wirken: BGP EVPN ist up, Underlay ist grün, trotzdem fehlt Host-Reachability in einzelnen Segmenten, ARP/ND-Suppression verhält sich inkonsistent, Multihoming zeigt MAC-Flapping, oder BUM-Traffic (Broadcast/Unknown-Unicast/Multicast) explodiert, obwohl EVPN eigentlich Flooding reduzieren soll. Genau deshalb braucht Multi-Vendor-EVPN-Interop zwei Dinge: eine klare Liste der häufigsten Interop-Probleme (damit Sie Symptome schnell zuordnen können) und eine strukturierte Testmethodik, die vor Go-Live und nach Changes reproduzierbar ist. Dieser Leitfaden beschreibt die typischen Fehlerquellen in EVPN/VXLAN-Mischumgebungen (Route Types, RT/RD, VNI/VRF-Mapping, BUM-Replikation, Multihoming, MTU/PMTUD, Anycast Gateway) und liefert einen einsatzbereiten Testplan, der nicht auf Vendor-spezifische CLI-Details angewiesen ist, sondern auf überprüfbare Zustände und Messungen. Als Referenzrahmen für EVPN dienen RFC 7432 sowie für VXLAN RFC 7348; Architekturhinweise für EVPN/VXLAN über IP-Underlay finden sich in RFC 8365.

Warum Interoperabilität bei EVPN/VXLAN schwieriger ist als bei klassischem VLAN

In klassischen VLAN-Netzen sind die wichtigsten Interop-Fragen oft Layer-2-nah: VLAN-Tagging, STP, LACP, MTU auf Trunks. EVPN/VXLAN bringt zusätzliche Abhängigkeiten und „unsichtbare“ State-Logik mit:

• Underlay/Overlay-Trennung: Underlay muss VTEP-IPs transportieren, Overlay muss EVPN-Routen korrekt signalisieren.
• Control-Plane-Interpretation: EVPN Route Types und Extended Communities werden nicht immer identisch umgesetzt.
• Default-Mechaniken für BUM: Ingress Replication vs. Multicast im Underlay – Interop scheitert häufig an BUM-Details.
• Stateful Features: ARP/ND-Suppression und Multihoming erfordern konsistente Bindings und DF-/Split-Horizon-Logik.

Der operative Schlüssel ist daher: Interop-Tests müssen Underlay und Overlay getrennt prüfen und die erwarteten EVPN-Route-Objekte (Type 2/3/5 und bei Multihoming Type 1/4) als „Service-Beweis“ nutzen.

Die häufigsten Multi-Vendor-EVPN-Interop-Probleme

Die folgenden Problemklassen treten in Mischumgebungen besonders häufig auf. Sie sind so formuliert, dass Ops sie als Symptom-Mapping nutzen kann.

Problemklasse 1: RT/RD- und Policy-Inkonsistenzen

Der häufigste Interop-Fail ist nicht „BGP down“, sondern „Routen werden nicht importiert“. Route Targets (RT) sind der Sichtbarkeitsmechanismus. Unterschiedliche Defaults (z. B. Auto-RT, VRF-RT vs. EVI-RT) oder Policy-Missmatch führen zu Segmenten, die „unsichtbar“ sind.

• Symptom: Underlay ok, EVPN Sessions ok, aber ein Segment/VRF hat keine Remote Hosts.
• Typischer Root Cause: RT-Import/Export inkonsistent, falsches VRF/EVI-Mapping, Filter auf Extended Communities.
• Test-Hebel: Route-Counts pro Type (Type-2/Type-5) und RT-Audit vor und nach Changes.

Problemklasse 2: Route-Type-Interop (Type 2/3/5) und „Teilwahrheiten“

EVPN Route Types bestimmen, was überhaupt signalisiert wird. Mischumgebungen scheitern oft daran, dass ein Vendor MAC-only (Type 2 ohne IP-Binding) liefert, der andere aber IP/MAC-Bindings erwartet (für Suppression), oder dass Type-3/BUM-Mechanik nicht identisch ist.

• Type 2 (MAC/IP): fehlt oder ist unvollständig → Unknown Unicast steigt, Hosts wirken intermittierend.
• Type 3 (BUM): fehlt oder ist inkonsistent → ARP/Broadcast funktioniert nur teilweise.
• Type 5 (Prefix): VRF-Routing fehlt → L2 ok, Inter-Subnet/Inter-VRF kaputt.

Ein guter Troubleshooting-Ansatz ist „Symptom → Route Type“: Unicast/Host-Probleme sind oft Type-2/RT; BUM/ARP-Probleme häufig Type-3/BUM-Policy; L3-Prefix-Probleme Type-5/VRF-RT.

Problemklasse 3: BUM-Replikation (Ingress Replication vs. Multicast) und Flooding-Policies

Ein Vendor nutzt standardmäßig Ingress Replication, ein anderer erwartet Underlay-Multicast, oder die IGMP/PIM-Unterstützung ist asymmetrisch. Das führt zu den typischen „ARP geht nicht, aber Unicast manchmal schon“-Störungen.

• Symptom: neue Hosts lernen schlecht, ARP/ND hat Timeouts, Broadcast „kommt nicht überall an“.
• Symptom: BUM-Traffic plötzlich extrem hoch oder extrem niedrig (beides ist verdächtig).
• Test-Hebel: definierte BUM-Tests (Broadcast/ARP) plus Telemetrie zu BUM-Raten und Type-3 Presence.

Problemklasse 4: Anycast Gateway Unterschiede

Viele Fabrics nutzen Anycast Gateway (gleiche Gateway-IP/MAC auf allen Leafs). Interop-Probleme entstehen, wenn MAC-Handling, Gratuitous ARP/NA-Verhalten, Proxy-ARP/ND oder lokale Policy-Defaults unterschiedlich sind.

• Symptom: nur Default-Gateway-gerichteter Traffic ist instabil, Host-zu-Host im gleichen Subnet ok.
• Symptom: nach Failover stale ARP/ND-Einträge, einzelne Hosts blackholed.
• Test-Hebel: Gateway-Failover-Tests mit ARP/ND-Validierung und Mobility-Szenarien.

Problemklasse 5: ARP/ND-Suppression und Binding-Synchronität

ARP/ND-Suppression reduziert Flooding, ist aber interop-sensitiv: Wenn IP/MAC-Bindings nicht gleich aufgebaut, nicht gleich verteilt oder unterschiedlich geaged werden, entstehen stale Bindings und damit Blackholing.

• Symptom: ARP/ND wirkt „random“, einzelne Hosts sind nach Move/Reboot nicht erreichbar.
• Typischer Root Cause: Type-2 IP-Binding fehlt, RT-Import fehlt, unterschiedliche Suppression-Defaults, Mobility-Handling inkonsistent.
• Test-Hebel: Host-Mobility-Test (Move/Re-IP), ARP/ND-Resolution-Zeit messen, Unknown-Unicast-Baseline prüfen.

Problemklasse 6: Multihoming-Interop (ESI/DF/Split-Horizon) in MLAG/EVPN-Mischungen

Multihoming ist interop-kritisch, weil DF-Wahl, Aliasing und Split-Horizon sauber zusammenspielen müssen. In Multi-Vendor-Umgebungen ist es besonders riskant, wenn auf der einen Seite EVPN Multihoming genutzt wird und auf der anderen Seite klassisches MLAG/vPC oder unterschiedliche Active/Standby-Modelle.

• Symptom: MAC-Flapping ohne sichtbaren L2-Loop, duplizierte Frames, BUM-Spikes nach Failover.
• Typischer Root Cause: ESI inkonsistent, DF-Mechanik unterschiedlich, LACP-Parameter/Hashing nicht abgestimmt.
• Test-Hebel: definierte Link- und Node-Failover-Tests mit MAC move/churn und BUM-Messung.

Problemklasse 7: MTU/PMTUD als „mysteriöser“ Interop-Verstärker

VXLAN-Encapsulation erhöht Paketgrößen. Wenn ein Vendor fragmentiert, ein anderer droppt, oder PMTUD-ICMP unterschiedlich gefiltert wird, entstehen pfadspezifische Drops, die wie „Interop-Bug“ wirken.

MTU-Bilanz als Gate (MathML)

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

• Symptom: kleine Pakete ok, große nicht; Intermittency abhängig von ECMP-Pfad.
• Test-Hebel: „Large vs. Small“-Tests VTEP↔VTEP und Host↔Host; PMTUD-ICMP gezielt erlauben (siehe RFC 1191 und RFC 8201).

Wie man Multi-Vendor-EVPN-Interop richtig testet

Interop-Tests sind am erfolgreichsten, wenn sie in Stufen ablaufen: erst Underlay, dann EVPN Control Plane, dann Overlay Data Plane, dann Failure/Recovery. Jede Stufe muss ein klares „Pass/Fail“ liefern, sonst wird Troubleshooting später unendlich.

Teststufe 1: Underlay-Baseline (Transport ist die Voraussetzung)

• VTEP-Reachability: Loopback/VTEP-IPs über alle relevanten Pfade erreichbar, keine Flaps.
• ECMP-Health: mehrere Pfade aktiv, keine pfadspezifischen Drops/Errors.
• MTU-End-to-End: große Pakete funktionieren, PMTUD nicht blockiert.
• Convergence: Link-Fail führt zu schneller Wiederherstellung ohne lange Blackholes (BFD/IGP-Timer passend).

Teststufe 2: EVPN Control Plane (Routenobjekte sind der Service-Beweis)

• Sessions: BGP EVPN Nachbarschaften stabil, keine wiederkehrenden Resets.
• RT-Import/Export: pro VRF/EVI explizit geprüft; keine unerwarteten Imports (Security-Risiko).
• Route Types Presence: Type-2/Type-3/Type-5 dort vorhanden, wo sie erwartet werden.
• Route Counts als Trend: „Anzahl Type-2 pro Segment“ ist eine praktische Baseline (Spikes/Drops sind Frühindikatoren).

Teststufe 3: Overlay Data Plane (funktionale Tests pro Segment)

• L2-Reachability: Host↔Host im selben Segment (L2VNI) stabil.
• ARP/ND: Resolution schnell und stabil (Suppression-ON und Suppression-OFF Verhalten dokumentieren).
• BUM-Tests: definierte Broadcast/Multicast-Checks, um Type-3/Replication zu validieren.
• L3-Reachability: Inter-Subnet/VRF-Routing (Type-5) stabil, Next Hop korrekt.

Frame Loss Ratio für definierte Testfenster (MathML)

$\mathrm{FLR}=\frac{\mathrm{lost\_frames}}{\mathrm{sent\_frames}}$

Ein einfacher, operativ brauchbarer Ansatz ist, pro Testklasse (Unicast, ARP/ND, BUM) in einem festen Zeitfenster eine Loss-Rate zu ermitteln und als Baseline zu speichern. Entscheidend ist nicht Perfektion, sondern Vergleichbarkeit vor/nach Changes.

Teststufe 4: Failover- und Recovery-Tests (Interop zeigt sich im Stress)

Viele Interop-Probleme treten erst bei Failover auf: DF-Mechanik, BUM-Replikationslisten, MAC Mobility und Route Withdrawal/Replacement. Daher sollten Sie mindestens folgende Tests als Pflicht ansehen:

• Link-Fail (Underlay): ein Underlay-Link down → Overlay bleibt stabil, keine pfadspezifischen MTU-Drops.
• VTEP/Leaf-Fail: ein VTEP aus → Routen withdraw/replace korrekt, Recovery ohne MAC-Storm.
• Multihoming-Fail (falls relevant): ein CE-Link down → keine Duplikate, keine Blackholes, DF stabil.
• Recovery: Link/Node kommt zurück → keine dauerhaft erhöhten MAC move/churn und keine BUM-Spikes.

Teststufe 5: Negative Tests (damit Sie Fehlverhalten sicher erkennen)

Ein häufig unterschätzter Teil ist das absichtliche Erzeugen von „falschen“ Zuständen in einer Testumgebung, damit Ops später die Signaturen erkennt.

• RT-Mismatch simulieren: Segment bewusst unsichtbar machen und prüfen, ob Monitoring es erkennt.
• Type-2 Binding-Lücke simulieren: ARP/ND-Suppression „halb“ aktivieren und Symptome dokumentieren.
• MTU-Knick simulieren: ein Pfad mit kleiner MTU → pfadspezifische Drops sichtbar machen.
• BUM-Replication ändern: IR vs. Multicast (nur im Lab) und Auswirkungen messen.

Ops-Checkliste: Interop-Readiness vor Go-Live

• Feature-Matrix: pro Vendor/Plattform: EVPN Route Types, Multihoming-Modus, ARP/ND-Suppression, BUM-Mechanik, Anycast GW, CoPP/Control-Plane-Handling.
• RT/RD-Governance: Namens- und Nummernkonvention, Audit-Prozess, Drift-Detection.
• MTU-Standard: Underlay-MTU als verbindliche Policy, PMTUD-ICMP gezielt erlaubt.
• Baseline-Telemetrie: Type-2/Type-5 Counts, BUM-Raten, MAC mobility, VTEP-Reachability.
• Failover-Protokoll: definierte Tests, definierte Stop-Kriterien, Stabilitätsfenster nach Recovery.

Monitoring und Guardrails: Was in Multi-Vendor-Fabrics Pflicht ist

Interop-Probleme werden deutlich seltener, wenn Sie nicht nur „Sessions up“ überwachen, sondern die tatsächlichen EVPN-Objekte und ihre Nebenwirkungen.

• EVPN Route Counts pro Type: Type-2/Type-3/Type-5 Trends pro VRF/EVI.
• RT-Drift und Policy-Änderungen: Alarm bei unerwarteten Imports (Security) oder plötzlichen Drops (Outage-Risiko).
• MAC mobility/move Events: Frühindikator für Multihoming-Probleme, Loops oder stale Bindings.
• BUM-Traffic: Broadcast/Unknown-Unicast/Multicast Raten als Indikator für fehlende Bindings oder kaputte Replication.
• MTU-/Drop-Indizien: pfadspezifische Drops, PMTUD-Probleme, „large vs. small“ Testalarme.
• Control Plane Protection: CoPP/CPU-Spikes überwachen, weil CPU-Lags EVPN-Updates und Failover verfälschen können.

Evidence Pack: Standarddaten für Multi-Vendor-Interop-Incidents

• Zeitfenster (UTC): Start, Peak, Fix, Stabilitätsfenster.
• Scope: betroffene VNIs/EVIs/VRFs, betroffene VTEPs, betroffene Vendor-Kombination.
• Underlay: VTEP-Reachability, MTU/PMTUD-Indizien, ECMP/LAG-Status.
• RT/RD: relevante RTs, Import/Export-Status, Policy-Diff.
• Route Types: Presence/Counts Type-2/3/5 (und Type-1/4 bei Multihoming), Next-Hop-Plausibilität.
• Data Plane: BUM-Raten, Unknown Unicast, MAC move/churn, ARP/ND-Anomalien.
• Failover-Korrelation: trat das Problem nach Link-/Node-Events auf? Recovery-Verhalten dokumentiert.

Outbound-Ressourcen

• RFC 7432 (EVPN: Route Types, Multihoming, Control Plane)
• RFC 7348 (VXLAN: Encapsulation und Overhead)
• RFC 8365 (EVPN/VXLAN Architektur über IP-Underlay)
• RFC 1191 (Path MTU Discovery IPv4)
• RFC 8201 (Path MTU Discovery IPv6)
• RFC 4271 (BGP: Basis für EVPN-Signalisierung)

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.