In EVPN-VXLAN environments running Juniper QFX5120 switches, we may experience packet loss and prolonged service disruptions (up to 30 minutes) during server failovers. This occurs even though Gratuitous ARP (GARP) packets are marked as “Pass” in EVPN and should be transparently forwarded. The root cause is often related to Juniper’s default ARP suppression in EVPN-VXLAN, which prevents flooding of ARP requests but can delay MAC/IP table updates if GARP timing or server behavior is misaligned.

• MAC/IP table entries do not update promptly after server failover, leading to traffic blackholing.

• Service disruptions lasting ~30 minutes during VIP (Virtual IP) or MAC address migration.

• GARP packets are generated by servers but not processed effectively by remote switches.

• Logs show no explicit drops of GARP packets, but `show ethernet-switching table` reveals stale MAC entries.

• Potential MAC mobility warnings or DDoS policer violations if GARP floods occur (e.g., during mass failovers).

Since Juniper is transparently forwarding GARP frames (PASS mode), the GARP packet generation, timing, and response behaviour on the server are the most probable root causes of the issue.

ARP suppression is turned on by default in EVPN-VXLAN setups and can’t be disabled starting from Junos OS 19.1R1. Even though it might seem like GARP packets are being blocked, Juniper actually allows them to pass through, as they’re marked under the “Pass” category.

So, the issue likely isn’t with the switch dropping GARP packets. It’s more likely related to the timing or behaviour of the server when it sends the GARP—especially during a failover.

If the GARP isn’t sent at the right moment, or if the old server still responds to address queries after the VIP has moved, the MAC/IP update might not take effect immediately, which can lead to packet loss.

Recommendations:

• Please make sure the new server sends a GARP right after it takes over the MAC or VIP. Also, ensure the interface is fully up and ready before the GARP is sent.
• It’s important to confirm that the previous server no longer replies to traffic or ARP requests for the same IP or MAC once the VIP has moved.
• On the Juniper side, you can monitor the interface to verify that GARP packets are actually being forwarded and are visible to the remote devices.
• It might help to review and fine-tune the server failover or clustering logic so that the VIP is properly removed from the old server before being brought up on the new one.