On QFX5120 switches in an EVPN-VXLAN fabric, a large MAC-mobility or convergence event can expose a condition where a remote MAC/IP entry is not fully reprogrammed after it changes. The EVPN control-plane update can be present while the corresponding ARP and forwarding-hardware state on a remote VTEP remains incomplete, causing traffic to stay blackholed after the original convergence event has ended.

This behavior is consistent with PR1936648. The issue was observed on Junos OS 23.4R2-S7.7 and is corrected in 23.4R2-S8.

A burst of MAC moves may trigger the condition, but PR1936648 does not explain the original source of abnormal or unexpected local MAC learning. If a large number of remote MAC addresses are first learned locally on one interface, investigate that event separately.

One or more of the following symptoms may be seen during or after an EVPN convergence event:

• Traffic to some remote endpoints is unreachable or blackholed even after EVPN convergence appears to complete.
• A large number of EVPN duplicate-MAC or MAC-mobility events are recorded after access/server-facing interfaces recover.
• MAC/IP programming requests are dropped by l2ald.
• The EVPN route may exist, but ARP or forwarding-hardware programming for the remote MAC/IP entry is missing or incomplete.

Example error message:

<date> <device> l2ald[<pid>]: L2ALD_MAC_IP_ADD_DROPPED: mac 00:00:00:00:00:01 is not available l2 ifl (<index>:et-0/0/0.0). Drop mac+ip 192.0.2.10

Useful checks on the affected remote VTEP:

show evpn database mac-address 00:00:00:00:00:01 extensive

show arp no-resolve | match 192.0.2.10

show ethernet-switching table | match 00:00:00:00:00:01

A key indicator is a mismatch between the EVPN control-plane state and the local ARP/forwarding state for the same remote endpoint.

Upgrade the affected QFX5120 VTEPs to Junos OS 23.4R2-S8 or a later maintenance release that includes the correction for PR1936648. In a redundant fabric, perform the upgrade in stages and validate EVPN routes, ESI state, MAC/IP entries, ARP, and traffic before continuing to the next device.

The software upgrade is the permanent correction for PR1936648.

If an upgrade cannot be performed immediately, the following command can be used on the affected remote VTEP to force MAC and MAC/IP relearning:

clear ethernet-switching table

Caution: This operation is disruptive and provides only temporary recovery. There is no documented permanent configuration workaround for PR1936648.

Where operationally practical, reduce the chance of a large convergence burst while waiting for the upgrade:

• Avoid restoring many server-facing interfaces at exactly the same time.
• Restore interfaces in smaller groups and allow EVPN to converge between groups.
• Do not use periodic MAC-table clearing as a preventive measure; it can create additional convergence and obscure the original condition.
• If abnormal mass local MAC learning is seen, capture traffic on the affected access interface and investigate the source independently from PR1936648.

https://prsearch.juniper.net/problemreport/PR1936648