Juniper EVPN/VXLAN ARP

Bei Juniper QFX, brauche ich manchmal no-arp-suppression im VLAN, weil manches Kundenequipment nicht richtig ARP macht. 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:

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

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.

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