Duplicate MAC addresses after cross-cluster VM migration causing ARP flaps and intermittent VM network loss

Environment

VMware ESXi 7.0 environment: VMs migrated between clusters using vMotion and exported/imported between vCenter instances for DR testing. Guest OSes are Linux and Windows; distributed vSwitches and some static MACs were previously assigned for older VMs.

Symptoms

After recent migrations, multiple VMs intermittently lose network connectivity and other hosts report duplicate-ARP/MAC entries for the same MAC on different uplink ports; ping to affected VMs sometimes reaches one path and then fails. Affected VMs can briefly respond after a vSwitch respawn or host-side port reset.

Observations

vCenter and ESXi logs show repeated entries indicating 'duplicate MAC address detected' and ARP/forwarding table oscillation on upstream physical switches. Some VMs have MAC addresses set explicitly in their VMX files; others have been cloned from templates and may carry identical MACs if cloning workflow did not generate new addresses.

Already attempted

Restarted the affected vSwitch port groups, power-cycled a small number of VMs (temporary relief), and reviewed vCenter for manual MAC overrides. Tried removing static MAC entries on a test VM and letting vCenter reassign — test VM regained stable connectivity.

Question

What are the likely root causes of duplicate MACs appearing after cross-cluster migrations and what are safe methods to restore unique MAC addresses and prevent recurrence in a production ESXi environment?

Post timeline

COMMUNITY RESPONSES

Verified community troubleshooting

0 replies

No answers yet..

Showing 0 of 0 community responses

AI DIAGNOSTICS

Incident analysis

Updated 1w ago• Trouble ID

Most likely causes

Manual/static MAC assignments retained during migration or template cloning, leading to collisions when VMs coexist on the same L2 network. 90%

Imported/registered VMs from other vCenter instances with MACs that overlap the current MAC allocation pool. 80%

Bug or misconfiguration in the vCenter migration workflow that prevented MAC reallocation on vMotion/import. 30%

Summary

Duplicate MACs typically arise from manual/static MAC assignments, cloning without MAC regeneration, or importing VMs between vCenter instances where the MAC allocation pools overlap. When two VMs present the same MAC on the network, upstream switches and hypervisor virtual switches generate ARP flaps and connectivity issues. Fixes involve regenerating MACs in a controlled manner and enforcing policies so future migrations allocate unique addresses.

Suggested Fixes

Diagnostic step 1

Identify collisions without downtime: run 'esxcli network vm list' and compare MACs across hosts to find duplicates; capture ARP tables on upstream switches to confirm which ports are advertising the duplicate MACs.

Diagnostic step 2

For each collided VM, change the MAC in vCenter by editing the VM's network adapter and enabling 'Generate MAC address' (or set a new MAC within your allowed range). Do this one VM at a time for minimal disruption; reboot of the VM's network interface or a quick VM power-cycle may be required (reversible by reassigning the previous MAC if needed).

Diagnostic step 3

Audit cloning and import processes: ensure templates and automation do not preserve MAC addresses; enable 'Generate new MAC' during cloning or importing workflows.