Juniper EVPN/VXLAN ARP

Bei Juniper QFX, brauche ich manchmal no-arp-suppression im VLAN, weil das Kundenequipment nicht richtig ARP macht oder akzeptiert. Das kommt bei Juniper QFX-EVPN/VXLAN Umgebungen öfter vor als ich am Anfange gedacht habe. Das no-arp-suppression im VLAN/BD ist meistens ein Workaround für Geräte, die mit EVPN Distributed ARP nicht sauber umgehen.

Typische Fälle, die mir schon vorgekommen sind:

• Einige neue Arista-Switches
• Legacy-Firewalls
• Storage-Systeme
• ältere Hypervisor
• industrielle/embedded Geräte
• manche Loadbalancer
• Geräte mit “gratuitous ARP”
• Appliances mit statischen ARP/MACs

Die letzten zwei Fälle waren tatsächlich Arista-Switche, jeweils neu gekaufte und up2date. Einer war im L3 Modus, der andere normal im L2.

Wenn ARP Suppression aktiv ist, beantwortet der Leaf ARP Requests lokal aus der EVPN Control Plane. Manche Geräte erwarten aber:

• echte Broadcast-ARP Frames,
• bestimmte Timing-Verhalten,
• oder reagieren komisch auf Proxy-ARP/ARP Reply vom Switch.

Dann hilft in jedem betroffenen VLAN:

set vlans CUSTOMER-VLAN no-arp-suppression

oder je nach Release innerhalb der Bridge-Domain. Man muss es explizit eintippen, da es ab etwa 20.x deprecated ist und nicht mehr mit Tab auto-vervollständigt wird.

Der Tradeoff, den man dann annehmen muss:

• mehr BUM-Traffic im VXLAN Fabric
• mehr ARP Broadcasts im Netzwerk
• weniger Skalierung bei größeren Netzen
• aber oft bessere Kompatibilität

Praxisregel, die ich inzwischen ausgearbeitet habe:

• ARP suppression standardmäßig AN lassen (keine Config)
• nur für problematische VLANs deaktivieren (no-arp-suppression)
• idealerweise kleine/Legacy-Segmente isolieren

Bei größeren QFXen mit EVPN sieht man das besonders oft zusammen mit:

• vMotion/VM mobility (VMware)
• Anycast Gateway
• IRB interfaces
• asymmetrischem Routing
• alten Linux Kerneln
• proprietären Appliances

Einige typische Symptome:

• MAC wird gelernt, aber verschwindet einfach wieder
• Ping geht nur in eine Richtung oder erster Ping droppt
• ARP Table auf Endgerät bleibt auf INCOMPLETE
• Manchmal kurzzeitige, unregelmäßige Untebrechungen
• Allgemein intermittierende Connectivity, nicht verlässlich

Dann ist no-arp-suppression oft tatsächlich der schnellste Fix.

Zum Verifizieren hilft:

show evpn arp-table
show ethernet-switching table
show arp no-resolve
monitor traffic interface ...

und schauen:

• beantwortet der Leaf lokal?
• sieht man überhaupt Broadcast-ARP?
• kommen Gratuitous ARPs an?

Außerdem wichtig, unterdrücktes ARP interagiert teilweise unschön mit:

• EVPN type-2 route aging (speziell)
• MAC mobility (z.B. active/active oder ähnliches)
• silent hosts, die kein ARP beantworten
• EVPN duplicate MAC detection

Weitere Infos:

https://blog.apnic.net/2021/12/01/arp-problems-in-evpn

Last updated on 2026-05-18 at 19:22 UTC