Duplicate MAC Addresses: Symptoms and How to Track Them Down

Two identical MAC addresses in one broadcast domain do not cause a clean outage. They cause intermittent failures that look random. Because the symptoms are unstable, the problem is often misdiagnosed as cabling or driver trouble and the investigation starts off in the wrong direction.

Typical symptoms

Both devices drop in and out. A switch's MAC address table can only record one port. As the two devices take turns transmitting, the entry flips between ports. Frames for that address go to whichever port was learned most recently, and the other device receives nothing. Ping loss appears in blocks rather than evenly spread.

ARP mappings keep changing. The IP behind one MAC keeps changing, or the MAC behind one IP stays put while connectivity comes and goes.

Switch logs complain. Managed switches usually log something like "host flapping" or "MAC move", which is the most direct evidence available.

The operating system reports an address conflict. That message usually refers to IP conflict, but the root cause of an IP conflict is sometimes a MAC-layer problem.

Common causes

Cloned virtual machines that were never re-addressed. This is by far the most frequent source today. Copy a VM image, boot it, and two machines share one virtual adapter address. The rules are in MAC addresses in virtual machines and containers.

Duplicate batches from cheap adapters or embedded gear. Some inexpensive USB adapters, development boards and surveillance cameras ship whole batches burned with one address. Their MACs often return no vendor or point at a module supplier.

Someone copied a real address by hand. See changing a MAC address on each platform.

A network loop producing a false conflict. When switches form a loop, one MAC is seen on several ports and the logs look almost identical to a genuine duplicate. Check spanning tree before anything else.

Active and standby devices configured alike. Some high-availability designs share a virtual MAC, and a split-brain situation turns that into a real conflict.

Investigation steps

First, confirm it really is a duplicate. Query the address on the switch:

show mac address-table address 001b.a912.3456

If it keeps jumping between two ports, or logs show MAC move events, you have your answer. Check spanning tree at the same time to rule out a loop creating the illusion:

show spanning-tree

Second, find out what is behind each port. Trace hop by hop as described in locating a device by MAC. If one of them is an uplink, the second device sits on a downstream switch.

Third, isolate to verify. Shut one of the ports and watch whether the fault disappears:

interface Gi1/0/7
 shutdown

Immediate recovery confirms it. This is the most reliable test available.

Fourth, confirm from the hosts. Check the interface address on both suspects:

ip link show          # Linux
ifconfig              # macOS
getmac /v             # Windows

Prevention

Give virtual machines random addresses. Every mainstream hypervisor can generate them, and when cloning you should choose to regenerate the MAC rather than keep it.

Enable port security. Capping MACs per port makes the switch alert or shut the port down when a conflict occurs, which converts an intermittent fault into a definite one and is far easier to diagnose. Configuration is in the switch MAC address table.

Spot-check purchases. When buying inexpensive network gear in volume, check a few units for duplicate MACs. Pasting the addresses into the lookup page also reveals whether they come from a questionable module supplier.

Always use locally administered addresses when changing one by hand. Pick 2, 6, A or E as the second hex character and collision with a real device becomes structurally impossible.