Physical switch reports "Detected duplicate host MAC in topology" due to ESXi host link flapping

Products

• VMware vSphere ESXi

Issue/Introduction

Network administrators may observe alerts on physical top-of-rack switches stating "Detected duplicate host MAC in topology" or similar loop-detection warnings.

Coinciding with these alerts, the VMware vSphere environment may experience:

Intermittent network connectivity on specific ESXi hosts.

Guest VM network interruption.

Analysis of the /var/run/log/vmkernel.log file on the affected ESXi host reveals a high frequency of link state changes (flapping) on a specific uplink (e.g., vmnic0).

Example Log Pattern:

2026-02-09T15:50:49.018Z cpu0:2097152)IGBN: 1234: vmnic0: link is down
2026-02-09T15:50:52.104Z cpu0:2097152)IGBN: 1234: vmnic0: link is up

 

Environment

VMware vSphere ESXi (All Versions)

Physical Network Switches

Cause

The issue is caused by Physical Layer Instability (Link Flapping).

When an ESXi host uplink (vmnic) rapidly oscillates between "UP" and "DOWN" states, the physical switch must repeatedly flush and re-learn the MAC addresses associated with that port.

If the rate of oscillation is high enough, the switch's control plane may interpret the rapid re-appearance of MAC addresses as a topology loop or a duplicate MAC scenario, triggering the protective alert.

This is a hardware fault in the physical data path, not a software driver or firmware defect.

Resolution

To resolve the issue, identify and replace the faulty physical component in the data path for the affected uplink.

Troubleshooting Steps:

1. Identify the Flapping Uplink:

   • Review vmkernel.log or vobd.log to identify which vmnic is generating "Link DOWN" events.

2. Inspect Physical Cabling:

   • Reseat or replace the Ethernet/Fiber cable connecting the ESXi host to the physical switch.

3. Replace Transceivers (SFP/SFP+):

   • Replace the optical transceiver module on the ESXi host side.

   • If the issue persists, request the network team replace the transceiver on the physical switch side.

4. Port Migration:

   • Move the physical cable to a different free port on the upstream switch to rule out a localized physical port failure on the switch hardware.

5. Verify Stability:

   • Monitor the vmkernel.log for at least 1 hour to ensure no further unexpected link state changes occur