M-LAG+EVPN network with abnormal ARP learning under leaf

Devices and versions: S6800 F2707+H0303

Network: Two S6800 devices act as leaf devices with M-LAG, and the downstream server NICs work in active-standby mode, that is, the servers are single-connected to the M-LAG.

When the server's active-standby NIC is switched, the ARP of the server on the M-LAG devices is not migrated normally, resulting in abnormal traffic forwarding. The server NIC does not actively send ARP packets when migrating (i.e., silent host).

During the problem handling process, the on-site engineer fully reproduced the fault. In the initial state, the main NIC of the server was connected to port T1/0/14 of leaf-2. At this time, the entries on the two M-LAG devices were as follows, with the MACs learned on the peer-link interface and the downstream single port, respectively:

The MAC entries were also normal, with the MACs learned on the peer-link interface and the downstream single port, respectively:

Then, the on-site engineer switched the server's active-standby NIC and migrated the main NIC to the downstream port T1/0/14 of leaf-1. At this time, the MAC table entries on the devices were normal:

But the ARP was abnormal. The ARP entries on the two M-LAG devices were learned on the peer-link interface:

After the server NIC migration, the MAC table entries were migrated, but the ARP table entries were learned abnormally.

We know that switches learn MAC addresses based on the source MAC of received packets on ports. After the server NIC migration, as long as the main NIC sends packets on the new port, MAC learning can be triggered, and MAC migration can be completed. However, the on-site server is a silent host and does not actively send ARP packets after migration. Therefore, the switch cannot perform ARP migration through the normal ARP learning process.

In this case, MAC and ARP can be migrated together. When the MAC of an ARP entry is migrated, the ARP entry will also be refreshed synchronously. However, in the current version, there is an exception in the ARP refresh process in the M-LAG scenario, resulting in ARP learning on the peer-link interfaces of the two M-LAG devices.

Temporary workaround: Configure the server NIC to actively send ARP packets when migrating to trigger the normal ARP learning process on the M-LAG devices.

Solution: The current S6800 device has released the F2707H07 patch to solve this problem, canceling the MAC/ARP linkage migration of the peer-link interface.