Two devices with the same MAC address can disrupt a switched Ethernet network even when they use different static IP addresses. IP uniqueness does not repair Layer 2 identity duplication. The switch learns one source MAC on one port, then relearns it on the other, causing the forwarding entry to move back and forth.
The result may be intermittent connectivity rather than a clean error, which makes duplicate MAC problems easy to misdiagnose.
How a Switch Learns the Wrong Path
An Ethernet switch maintains a forwarding table that maps a MAC address and VLAN to a physical port. Every time it receives a frame, it learns the source MAC on the ingress port.
Suppose PC A and PC B use the same MAC:
- PC A transmits, so the switch maps the MAC to port 1.
- PC B transmits, so the switch moves the same entry to port 2.
- Return traffic for either device follows whichever port was learned most recently.
Managed switches may log this as MAC flapping. On a busy network the entry can oscillate rapidly, producing packet loss, broken sessions, duplicate-address warnings, or traffic delivered to the wrong endpoint.
Separate VLANs create separate forwarding domains, so an identical MAC in two isolated VLANs may be tolerated. The problem occurs when both identities are visible in the same Layer 2 domain or are bridged together.
Why Different Static IPs Do Not Help
Hosts use ARP to resolve each local IPv4 address to a destination MAC. If two different IP addresses resolve to the same MAC, senders construct both streams for the same Layer 2 identity. The switch cannot use the destination IP to decide which physical port should receive an ordinary Ethernet frame.
The symptoms can include:
- one PC working only after the other becomes quiet;
- remote sessions dropping when either device sends traffic;
- ARP entries for different IPs showing the same MAC;
- switch logs reporting MAC movement;
- DHCP, network-access control, or monitoring combining two hosts;
- security alerts that appear to follow the wrong machine.
On Windows, arp -a shows neighbour mappings. On a managed switch, inspect the MAC address table and logs. Packet capture on a mirror port can prove that the same source MAC arrives from two switch ports.
Do Not Clone a Production MAC for Licensing
Some legacy applications bind a licence to a NIC MAC address. Assigning that same address to a replacement PC while the original remains connected creates a network fault and may violate the licence terms.
Ask the vendor to rehost or reset the licence. If the application genuinely checks only a local adapter identity and the vendor approves the design, isolate that identity from the production LAN:
- keep the licensed legacy adapter disconnected or on an isolated virtual network;
- use a second physical or virtual NIC with a unique MAC for normal network access;
- ensure the operating system and application consistently select the intended adapter;
- document the configuration so cloning or failover does not expose the legacy MAC twice.
A router or NAT boundary can present different Layer 2 identities on different network segments, but it does not change the MAC that a local process enumerates inside the host. A bridge normally forwards source MAC addresses and therefore does not solve duplication.
Locally Administered Addresses
Many NIC drivers and hypervisors allow a locally administered MAC. Use this only to assign a unique address under central control. The first octet should indicate a unicast, locally administered address, and the value must not collide anywhere in the relevant VLAN.
Randomisation designed for Wi-Fi privacy is not a licensing strategy. It can change per network, profile, or operating-system policy and make the application lose its binding.
In virtual environments, let the platform allocate MAC addresses unless an application has a documented requirement. When copying a VM, generate a new virtual NIC identity rather than retaining the source MAC. Hypervisor security policies may also block forged source addresses or MAC changes.
A Safe Resolution Workflow
Disconnect one suspected endpoint and confirm whether connectivity stabilises. Record both physical switch ports, VLANs, IP addresses, adapter identifiers, and the application’s licensing dependency. Give every active production NIC a unique MAC, clear or allow ageing of affected switch and ARP caches, then reconnect one device at a time.
Verify that each IP resolves to its own MAC and that the switch table remains stable. Review DHCP reservations, monitoring inventory, port-security entries, and access-control systems that may have cached the duplicate identity.
Do not attempt to hide one duplicate with a different static IP. Ethernet delivery on the local network still depends on the MAC. The durable fix is uniqueness—or true Layer 2 isolation with an approved reason for retaining the legacy identity.
