ARP/ND Suppression in EVPN: Nutzen und operative Pitfalls

ARP/ND Suppression in EVPN ist ein zentraler Baustein moderner Overlay-Netze, weil er eines der klassischen Probleme großer Layer-2-Domänen entschärft: Flooding. In traditionellen VLAN- oder VPLS-Umgebungen werden ARP (IPv4) und Neighbor Discovery (IPv6) häufig als Broadcast bzw. Multicast über die gesamte Broadcast-Domain verteilt. Je größer die Domain, desto größer das Grundrauschen – und desto höher das Risiko, dass Loops, Storms oder MAC-Table-Probleme eskalieren. EVPN ändert die Spielregeln: Statt „wer ist 10.0.0.5?“ als ARP-Request an alle zu schicken, kann ein VTEP diese Frage lokal beantworten, wenn er das IP/MAC-Binding bereits aus der EVPN-Control-Plane kennt. Das ist der Nutzen von ARP/ND Suppression: weniger Broadcast/Multicast, schnellere Resolution, weniger BUM-Traffic (Broadcast/Unknown-Unicast/Multicast) und damit bessere Stabilität und Skalierung. Gleichzeitig ist ARP/ND Suppression eine Quelle operativer Pitfalls, weil sie ein „unsichtbares“ State-Problem einführt: Wenn Bindings stale werden, wenn Host-Mobility nicht sauber verarbeitet wird, wenn Multihoming/DF-Mechanik inkonsistent ist oder wenn Policies/RTs eine Teilmenge der EVPN-Routen blockieren, entstehen Fehlerbilder, die wie „mysteriöse“ Drops wirken. Im NOC sieht es dann so aus, als ob EVPN/VXLAN „spinnt“, obwohl die eigentliche Ursache eine falsche oder veraltete IP/MAC-Zuordnung im Overlay ist. Dieser Leitfaden erklärt ARP/ND Suppression in EVPN praxisnah: was sie leistet, wie sie konzeptionell funktioniert, welche Telemetrie für Ops Pflicht ist, welche Failure Modes typisch sind und wie Sie sie mit einem reproduzierbaren Troubleshooting-Workflow sicher beherrschen.

Was ist ARP/ND Suppression und warum wird sie in EVPN eingesetzt?

ARP/ND Suppression ist ein Mechanismus, bei dem der VTEP (oder PE) ARP-Requests (IPv4) und ND-Nachrichten (IPv6) nicht mehr ungefiltert als Flooding in die gesamte Broadcast-Domain weiterleitet, sondern – sofern möglich – lokal beantwortet. Voraussetzung ist, dass der VTEP die Zuordnung aus IP-Adresse und MAC-Adresse (das „Binding“) bereits kennt. In EVPN wird dieses Binding häufig über BGP EVPN verteilt, typischerweise als Teil der MAC/IP-Advertisement-Routen (Route Type 2). Dadurch wird aus einer Flooding-basierten Ermittlung eine Control-Plane-basierte Auflösung.

• Skalierung: Weniger Broadcast/Multicast reduziert Last auf Uplinks und Geräten.
• Stabilität: Weniger BUM-Traffic senkt das Risiko von Storms und MAC-Table-Thrashing.
• Performance: Schnellere ARP/ND-Auflösung, besonders bei verteilten Workloads und Microservices.
• Operatives Debugging: Weniger „Noise“ in der Datenebene, wenn alles korrekt ist.

Als normativer Einstieg in EVPN eignet sich RFC 7432. Für VXLAN als Encapsulation ist RFC 7348 relevant. Architekturhinweise für EVPN/VXLAN über IP-Underlay finden sich in RFC 8365.

Wie ARP/ND ohne Suppression funktioniert und warum das problematisch ist

In klassischen Bridging-Domänen läuft ARP als Broadcast: Ein Host sendet „Who has IP X?“ an alle, und der Besitzer antwortet. IPv6 ND arbeitet überwiegend über Multicast, ist aber vom Effekt her ähnlich: Viele Control-Frames gehen an viele Empfänger. In großen Segmenten führt das zu:

• Grundrauschen: auch ohne Störung ist ARP/ND ein permanenter Anteil am Traffic.
• Peaks nach Failover: nach Outages oder Topologieänderungen entstehen ARP/ND-Spitzen.
• Amplifikation bei Problemen: Loops und Storms vervielfachen Broadcast/Multicast.
• Operational Blind Spots: Flooding kann Ursache und Symptom gleichzeitig sein.

In EVPN ist das Ziel häufig, diese Flooding-Anteile drastisch zu reduzieren, damit BUM-Traffic nicht mehr die natürliche „Default-Mechanik“ des Netzes ist.

Konzept: IP/MAC-Bindings als Teil der EVPN-Control-Plane

Die zentrale Idee ist simpel: Der VTEP lernt nicht nur MACs, sondern auch IP/MAC-Zuordnungen und verteilt sie über EVPN. Dadurch kann er ARP/ND lokal beantworten oder gezielt weiterleiten. Im Betrieb sollten Sie sich merken: ARP/ND Suppression ist nur so gut wie die Qualität der Bindings und deren Aktualität.

Binding-Logik als Vereinfachung (MathML)

$\mathrm{Binding}=(\mathrm{IP},\mathrm{MAC},\mathrm{VNI},\mathrm{VTEP})$

Operativ ist das relevant, weil Bindings immer in einem Kontext gelten: Segment/VNI und „wo“ (welcher VTEP) der Host erreichbar ist.

Nutzen in der Praxis: Was sich im Betrieb messbar verbessert

Wenn ARP/ND Suppression korrekt umgesetzt ist, sehen Sie typischerweise folgende Effekte:

• Reduzierter Broadcast/Multicast: ARP/ND-Anteil sinkt deutlich, besonders in großen Segmenten.
• Weniger Unknown Unicast: da Hosts schneller und gezielter aufgelöst werden, sinkt Flooding indirekt.
• Stabilere Aggregation: geringere Wahrscheinlichkeit von MAC-Table-Exhaustion durch Flood-Events.
• Schnelleres Recovery: nach Failover weniger „ARP-Storm“-Nachlauf, weil Bindings bereits verteilt sind.

Operative Pitfalls: Warum ARP/ND Suppression Fehlerbilder erzeugen kann

Die Schattenseite ist die State-Abhängigkeit. Während klassisches Flooding „dumm, aber robust“ sein kann, ist Suppression „smart, aber anfällig“, wenn Bindings nicht stimmen. Die folgenden Failure Modes sind in Ops-Teams besonders relevant.

Pitfall 1: Stale Bindings nach Host-Mobility oder VM-Migration

Wenn ein Host (oder eine VM) seinen Attachment Point wechselt, muss das Binding aktualisiert werden. Wenn das nicht schnell und konsistent geschieht, kann der VTEP weiterhin auf eine alte MAC oder einen alten Remote-VTEP zeigen. Das erzeugt Blackholing oder „nur manchmal“-Erreichbarkeit.

• Symptom: ARP/ND Resolves liefern eine MAC, aber Unicast geht ins Leere.
• Symptom: Probleme beginnen nach VM-Move, Host-Reboot oder Link-Failover.
• Indiz: erhöhte MAC mobility/move Events, gleichzeitig sporadische Timeouts.

Pitfall 2: Teilweise Control-Plane-Sicht durch RT/Policy-Fehler

EVPN verteilt Bindings über BGP. Wenn Route Targets (RT) oder Policies falsch sind, importiert nicht jeder VTEP alle relevanten Bindings. Dann entsteht eine „partielle Wahrheit“: Ein Teil des Netzes kann ARP/ND unterdrücken (weil es Bindings kennt), ein anderer Teil muss doch fluten oder kann nicht auflösen.

• Symptom: Problem betrifft nur bestimmte VTEPs/Standorte oder nur bestimmte Segmente.
• Symptom: BGP Sessions sind up, aber Route Counts für Type-2 sind auffällig niedrig.
• Indiz: hoher Unknown Unicast/BUM in einem Bereich, normaler BUM in einem anderen.

Pitfall 3: Multihoming/DF-Interaktion – ARP/ND verhält sich „einseitig“

In EVPN Multihoming (ESI/DF) kann ARP/ND Suppression besondere Effekte haben, weil BUM-Forwarding (und damit ARP/ND-Flooding, falls es noch passiert) oft DF-gesteuert ist. Wenn DF-Wahl instabil ist oder Split-Horizon/Aliasing inkonsistent, kann ARP/ND in Richtung CE fehlen oder doppelt auftreten.

• Symptom: DHCP/ARP/ND sporadisch, Unicast teilweise ok.
• Symptom: nach Link-Failover Blackhole, bis ARP/ND neu gelernt wird.
• Indiz: DF-change Events, BUM-Spikes, MAC move/churn steigt.

Pitfall 4: ARP/ND Suppression maskiert Underlay-MTU- oder Transportprobleme

Wenn Underlay-MTU knapp ist, kann die Datenebene „nur große Pakete“ droppen. ARP/ND funktioniert aber oft trotzdem, weil diese Pakete klein sind. Dadurch wirkt das Problem wie „ARP/ND ok, aber Service kaputt“ – und Teams verdächtigen EVPN-Routen. In Wirklichkeit ist es ein Underlay-/MTU-Thema.

• Symptom: ARP/ND Resolves schnell, aber Applikationen brechen ab.
• Indiz: große Payloads scheitern, Retransmissions steigen.
• Merke: ARP/ND Suppression ist kein Beweis für gesunde Data Plane; sie ist nur ein Teilaspekt.

Pitfall 5: Sicherheits- und Anti-Spoofing-Mechanismen blockieren legitime Bindings

Viele Designs kombinieren Suppression mit Anti-Spoofing, IP/MAC-Bindings und ggf. ARP Inspection/ND Inspection. Das ist sinnvoll, kann aber legitimen Traffic blockieren, wenn:

• IP-Wechsel: ein Host ändert IP (z. B. DHCP), aber Policy erwartet statische Bindings.
• Dual-Stack-Komplexität: IPv4 und IPv6 Bindings werden unterschiedlich gehandhabt; ND-Suppression kann strenger sein.
• Stale Security State: Binding ist im Security-Modul alt, obwohl EVPN es aktualisiert hat.

Step-by-Step Troubleshooting: ARP/ND Suppression operativ prüfen

Das Ziel ist, schnell zu entscheiden: Liegt das Problem in der Binding-Distribution (Control Plane), in der Data Plane (VXLAN/Underlay), oder in Multihoming/Policy-Interaktion? Das folgende Vorgehen ist bewusst NOC-tauglich und setzt auf klare Checks.

Schritt: Scope definieren und Symptom klassifizieren

• Nur ein Host oder viele? Einzelhost spricht eher für Binding/Mobility; viele Hosts eher für Policy/Underlay.
• Nur IPv4 oder auch IPv6? Wenn nur IPv6 betroffen ist, liegt ND/MLD/Policy nahe.
• Nur nach Event? Nach Failover, Migration oder Change sind stale Bindings sehr wahrscheinlich.

Schritt: Underlay-Health als Basischeck

• VTEP-Reachability: VTEPs müssen stabil erreichbar sein.
• MTU-Indizien: „nur große Pakete“ testen, Drops/Fragmentation-Hinweise prüfen.
• ECMP-Pfade: bei intermittierenden Problemen an unterschiedliche Underlay-Pfade denken.

Schritt: EVPN Control Plane – sind Type-2 Bindings vorhanden und korrekt?

• Type-2 Routen: existieren Routen für die betroffenen MACs/IPs?
• RT Import/Export: importiert der Ziel-VTEP diese Routen (Policy)?
• Route Updates: gab es Withdraw/Replace-Events im Zeitfenster des Problems?

Schritt: Binding-Qualität prüfen (stale vs. fresh)

• Attachment Point: zeigt das Binding auf den richtigen VTEP/Port?
• Mobility Events: wurden MAC/IP kürzlich verschoben?
• Timeout/Refresh: werden Bindings regelmäßig erneuert oder bleiben sie zu lange stehen?

Schritt: Multihoming-Interaktion prüfen (falls dual-homed)

• ESI konsistent: beide PEs müssen denselben ESI führen.
• DF stabil: keine DF-change Spikes im Problemzeitraum.
• Split-Horizon: keine Hinweise auf Duplikate oder loop-ähnliche BUM-Anomalien.

Schritt: Mitigation wählen – abhängig vom Failure Mode

• Stale Bindings: kontrollierte Refresh-/Relearn-Strategie (konzeptionell), ohne großflächig MAC/ARP „blind“ zu flushen.
• RT/Policy-Fehler: Import/Export korrigieren, staged ausrollen, sofortige Validierung.
• Multihoming-Probleme: DF/ESI stabilisieren; temporär aktiven Pfad klar definieren, bis Fix implementiert ist.
• Underlay-Probleme: MTU/Transport korrigieren; Suppression ist hier nicht der Hebel.

Validierungs-Checkliste: ARP/ND Suppression sicher betreiben

Diese Checkliste eignet sich für Go-Live, nach Changes und nach Incidents, um „Second Outages“ durch versteckte Binding-Probleme zu vermeiden.

Checkliste Bereich A: Design und Intent

• Suppression-Policy definiert: für welche VNIs/Segments aktiv? Ausnahmen dokumentiert?
• Dual-Stack bedacht: IPv4 ARP und IPv6 ND sind beide betrachtet, inklusive MLD/IGMP-Snooping-Design.
• Security-Policy konsistent: Anti-Spoofing/Inspection passt zur Dynamik (DHCP, Mobility).

Checkliste Bereich B: Control Plane Konsistenz

• EVPN Sessions stabil: keine Flaps im Normalbetrieb.
• RTs korrekt: alle relevanten VTEPs importieren Type-2 Routen der Segmente.
• Route Counts plausibel: Type-2 Anzahl pro Segment entspricht der erwarteten Hostzahl (Trend statt Momentaufnahme).

Checkliste Bereich C: Data Plane und BUM

• ARP/ND Flooding niedrig: BUM im erwarteten Baseline-Band.
• Unknown Unicast niedrig: dauerhaft hohe Werte sind ein Warnsignal für fehlende Bindings.
• Performance stabil: keine Retransmissions-Spikes, keine „nur große Pakete“-Fehlerbilder (MTU).

Checkliste Bereich D: Mobility und Failover

• Host-Mobility getestet: VM-Move oder Port-Failover führt nicht zu stale Bindings.
• Multihoming getestet: DF/ESI stabil, Failover führt nicht zu ARP/ND-Blackholes.
• Recovery getestet: Rückkehr eines Links erzeugt keine BUM-Storms oder MAC move-Spikes.

Stabilitätskriterium für Bindings (MathML)

$\mathrm{BindingsStable}\Leftarrow \mathrm{mac\_move\_events}\le \mathrm{Baseline}\wedge \mathrm{unknown\_unicast\_rate}\le \mathrm{Baseline}$

Monitoring: Pflicht-Telemetrie für ARP/ND Suppression

Damit Suppression nicht zur Black Box wird, brauchen Sie Telemetrie, die Bindings, BUM und Mobility sichtbar macht. Sinnvolle Pflichtsignale:

• Type-2 Route Counts: Anzahl MAC/IP-Advertisements pro Segment/VNI als Trend.
• MAC mobility/move Events: Frühindikator für stale Bindings oder Multihoming-Instabilität.
• ARP/ND Request/Reply Rates: Baseline vs. Spike, getrennt nach Segmenten.
• Unknown Unicast Rate: dauerhaft hoch = Bindings fehlen oder werden nicht importiert.
• DF/ESI Events: bei Multihoming DF-Change-Spikes als starker Indikator.
• Underlay MTU/Drops: um „Control Plane ok, Data Plane kaputt“ schnell abzugrenzen.

Evidence Pack: Was Sie bei ARP/ND-Suppression-Incidents immer sichern sollten

• Zeitfenster (UTC): Start, Peak, Fix, Stabilitätsfenster.
• Scope: betroffene VNIs/VRFs, betroffene VTEPs, betroffene Hosts (IPv4/IPv6).
• Control Plane: EVPN Sessions, RT-Import/Export Hinweise, Type-2 Route Presence/Counts.
• Bindings: erwartete IP/MAC-Zuordnung vs. beobachtete Zuordnung, Mobility-Events.
• Data Plane: BUM-Raten (Broadcast/Multicast/Unknown Unicast), Drops/Storm-Control-Counter.
• Underlay: MTU-/Drop-Indizien, VTEP-Reachability, ECMP-Pfadhinweise bei Intermittency.
• Multihoming (falls relevant): ESI/DF-Status, DF-change Events, LACP/LAG-Health.

Outbound-Ressourcen

• RFC 7432 (EVPN Grundlagen, Route Types und MAC/IP Advertisement)
• RFC 7348 (VXLAN Encapsulation, Overhead/MTU-Kontext)
• RFC 8365 (EVPN/VXLAN Architektur über IP-Underlay)
• RFC 4861 (IPv6 Neighbor Discovery – ND Grundlagen)
• RFC 826 (ARP – IPv4 Grundlagen)

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.