MAC Address Conflict – What Happens When Two Hosts Have the Same MAC Address

arpmac addressswitching

I am aware that situation, where duplicate MAC addresses appear in the same broadcast domain, should never happen. However, if such situation happens, then how will the network work? I think one should distinguish three scenarios here:

1) If NIC's with the same MAC address are directly connected with a crossover-cable, then based on my tests, some kernels will not send the ARP reply(for example FreeBSD 9.2 kernel, IOS 12.2) if the MAC address in "ARP reply" message is the same as configured to the NIC, while others do(for example Linux 2.6 and 3.7).

2) If NIC's with the same MAC address are connected through a switch and those two hosts try to communicate with each other. This should not work because if one host sends an unicast frame which has the same source and destination MAC address, then switch would like to send the frame out of the port where it received the frame which is an illegal operation? In other words, such traffic should be dropped by the switch.

3) If two NIC's with the same MAC address are connected to switch and try to communicate with other hosts in the same broadcast domain. In this case, only one host at a time should be reachable? Depends on which of the switch ports has learned the MAC address. If both hosts generate traffic, then MAC address will flap between the two switch ports and there is a packet loss to both hosts?

Best Answer

I have seen this a few times, where manufacturers are lazy and store MAC addresses in CMOS or similar, and fall back to a common default. It would also be easy to arrange if using locally assigned addresses (e.g. when provisioning VMs)

  1. I've not tested what individual OSs do. If your only problem is ARP, then static ARP entries might work for you.

    1. Some old DEC systems used to send loopback packets to their own address, as a duplicate address check. I believe some Cisco switches do the same for loop detection. Either way, it's a special case of destination MAC filtering. If the address wasn't in the cache, I wouldn't be sure that first packet would be dropped immediately: it might be added to the forwarding tables and forwarded. Otherwise, silently drop.

    2. The MAC address would flap; if you are running a stateless protocol at the higher levels, you may end up with something like a crude unicast load balancer. For something like TCP, you'll get a lot of RST's as well as packet loss. And as others have said, to an 'enterprise' switch it looks like MAC spoofing and some may log/trap on this event.

Related Topic