Duplicate IP or MAC Address After a VM Clone or Restore: Prove It, Contain It, Fix the Copy

Direct answer: When users see intermittent drops, RDP sessions freezing or pings that work one minute and fail the next shortly after someone cloned, restored or test-recovered a virtual machine, suspect two machines claiming one network identity. There are two different faults. A duplicate IP address means the copy came up with the same static address as the original. A duplicate MAC address means two virtual NICs share one hardware address, so the physical switches keep moving that address between ports. Prove which one you have from evidence (Windows Tcpip event 4199, neighbour tables that change MAC, the vCenter MAC conflict alarm, a PowerCLI MAC listing). Then contain it by disconnecting the copy's virtual NIC, not the original's. Only then fix the copy: give it a unique, automatically generated MAC while it is powered off and re-address it before it touches the production network again.

Why it matters

A duplicate identity on a shared network is rarely a clean outage. It is a flapping fault: traffic follows whichever machine answered ARP last, or whichever switch port last saw the MAC. The symptom looks like a bad link, a firewall problem or an application bug. Teams lose hours checking the wrong layer, and the original production server is often the one that gets rebooted, re-IP'd or "repaired". That turns a contained mistake into a real change on a working system.

A second risk is subtler. If the copy is a domain member or a domain controller and it reaches the network with the original's name and address, it can also talk to Active Directory as the original. That causes problems well beyond networking. Handling of domain controller copies is covered in Domain Controllers on VMware: Snapshots and Restores, and member server trust is covered in the "The Trust Relationship Failed" After a Member Server Restore: Prove the Secure Channel and Repair It in Place listed below.

How it works

Duplicate IP: two machines, one address

Windows documents that it checks whether an IPv4 address is already in use before using it. On Linux, whether a static address is checked depends on the network manager and its configuration, so do not assume it. RFC 5227 (IPv4 Address Conflict Detection) defines ARP probes sent from source address 0.0.0.0 before claiming an address, and ARP announcements afterwards. It also covers passive detection of a host that starts using the same address later, and limits how often a host defends its address (DEFEND_INTERVAL, 10 seconds). For IPv6, RFC 4862 Duplicate Address Detection says an address found to be a duplicate must not be assigned to the interface, and the node should log a system management error.

On Windows, Microsoft documents the result. The System log records Source: Tcpip, Event ID 4199, Level: Error with the text "The system detected an address conflict for IP address … with the system having network hardware address …". Microsoft also notes that Windows DHCP clients use gratuitous ARP for conflict detection, and that the DHCP server can record a conflicting lease as BAD_ADDRESS. In PowerShell, Get-NetIPAddress reports an AddressState of Duplicate for an address on which a duplicate has been detected and that will not be used.

What happens next depends on timing. If the copy boots while the original is online, the copy's own detection may refuse the address, and the copy has no working IP. That is the lucky case. If the original was offline when the copy booted (for example a restore test during a maintenance window), the copy holds the address, and the original detects the conflict when it returns. Either way, other hosts' ARP caches can point at the wrong MAC until the entry ages out or is refreshed.

Duplicate MAC: two virtual NICs, one hardware address

vCenter generates MAC addresses for virtual NICs. Broadcom documents three schemes: VMware OUI (default), prefix-based and range-based. With the default VMware OUI scheme the address has the form 00:50:56:xx:yy:zz, and the fourth octet comes from the vCenter instance ID, a value from 0 to 63 chosen at installation. Broadcom's guidance on generated MACs:

• Once generated, a MAC does not change unless it conflicts with another registered virtual machine. It is saved in the VM's configuration file.
• The MAC of a powered-off VM is not checked against running or suspended VMs. A VM powered on again might acquire a different MAC because of such a conflict.
• Two vCenter instances with the same instance ID can generate the same MACs. If their VMs share a physical network, duplicates appear. Duplicates can also appear when the default MAC pool is exhausted.

A manually set MAC is a different case. Broadcom KB 433860 describes a clone that inherited the exact same manual MAC as its source. The result was MAC flapping on the upstream physical switches and intermittent RDP and ping drops on both machines. vCenter's automatic conflict handling is for generated addresses, so a manual MAC is copied as-is.

Restores and file-level copies can also carry the MAC across. If a VM's files are copied or re-registered, ESXi asks on power-on whether the VM was moved or copied. Broadcom KB 342208 warns that answering "I copied it" changes both the UUID and the MAC address. It follows that "I moved it" keeps them, so a copy answered as "moved" keeps the original's identity. Restore products and disaster-recovery tools handle this in their own ways; check your tool's documentation rather than assuming either outcome.

Read-only checks

None of these was run for this article. Each lists the privileges it needs and its side effects. None changes configuration.

1. On an affected Windows machine, look for the conflict event.

Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Tcpip'; Id=4199} -MaxEvents 20 |
  Format-List TimeCreated, Message

Reading the System log works for ordinary users on most builds; use an elevated session if access is denied. The message names the conflicting hardware address. Record it: this is the strongest single clue to which machine is the intruder.

2. Check whether Windows refused the address.

Get-NetIPAddress -AddressFamily IPv4 | Format-Table InterfaceAlias, IPAddress, AddressState, PrefixOrigin

Read-only. Duplicate means this machine detected a conflict and is not using the address.

3. From a third machine on the same subnet, see which MAC currently answers.

Windows:

Get-NetNeighbor -IPAddress 192.0.2.25 | Format-Table IPAddress, LinkLayerAddress, State

Linux:

ip neigh show 192.0.2.25

Both are read-only and need no elevation. Repeat a few times over several minutes, after normal traffic to the address. A link-layer address that alternates between two values is a strong lead to a duplicate IP, but expected failover or a planned move (a cluster address, a load balancer, a vMotion of the copy) can do the same. The neighbour cache only shows the most recent answer, so one reading proves little.

4. On Linux, probe for a second owner in duplicate address detection mode.

sudo arping -D -I eth0 -c 3 192.0.2.25

Needs root or CAP_NET_RAW, and sends three ARP probes with source 0.0.0.0. According to the iputils manual, in -D mode arping exits with status 0 if no replies were received. Run it from a machine that does not own the address; a reply then names the MAC of whoever answers. One reply from the original's MAC is expected and proves only that an owner exists. Two different MACs replying, or a reply from an unexpected MAC, is the lead. No reply does not prove the address is unallocated: its owner may be powered off or disconnected. Do not use -U or -A: they send unsolicited ARP that updates every neighbour's cache, which can move traffic to the wrong machine. arping is IPv4 only; for IPv6 use the neighbour cache or a dedicated NDP tool.

5. In vCenter, list virtual NIC MAC addresses and look for repeats.

Get-VM | Get-NetworkAdapter |
  Select-Object @{n='VM';e={$_.Parent.Name}}, Name, MacAddress, NetworkName, ConnectionState |
  Group-Object MacAddress | Where-Object Count -gt 1 |
  ForEach-Object { $_.Group }

Read-only PowerCLI; needs an existing Connect-VIServer session with read access to the inventory. Never paste credentials into a script or a ticket. This only covers one vCenter. If you run more than one vCenter on the same physical network, run it against each and compare. Also check the vCenter alarms; Broadcom KB 313916 refers to a VM MAC conflict alarm.

6. On the physical network, ask the switch team for MAC move events.

Most managed switches log or count MAC addresses moving between ports ("MAC flapping"). The commands are vendor-specific. Ask for the MAC address from steps 1–5, the ports involved and timestamps. Two ports alternating, each leading to a different ESXi host or uplink, is consistent with a duplicate MAC. Teaming changes, vMotion, failover and loops can also move a MAC, so confirm by finding two distinct powered-on VMs (or devices) with that MAC in step 5.

7. Record what was cloned, restored or recovered, and when.

Compare the first conflict events with the time of the clone, restore, test recovery or DR test. A conflict that starts within minutes of a restore test is a strong lead, not proof. Microsoft documents a counterexample: a switch or router feature called IP Device Tracking sends ARP probes that a Windows client in its duplicate-address check reads as a conflict, with no second machine assigned the address. An event naming the address 0.0.0.0, or a MAC that belongs to a switch, points that way.

Interpreting the results

Watch out for a common misreading. The machine that logs event 4199 is not necessarily the intruder. Usually it is the one that was already there and saw someone else claim its address. The MAC in the event message tells you who the other party is.

Decision guidance

Step 1: decide which machine is the copy, then contain it

Before changing anything, write down which VM is the production original and which is the clone or restored copy. Use vCenter creation and registration times, restore job records and the change ticket. If you cannot tell, stop and get the owner to confirm. Changing the original by mistake is the worst outcome of this incident.

Contain: in vCenter, edit the copy's settings and clear Connected on its network adapter, or move it to an isolated port group with no uplink. Both are reversible in seconds.

• Verification: the neighbour cache on a third machine shows only the original's MAC for the address after the next ARP exchange, the switch stops logging MAC moves, and users' drops stop.
• Rollback: reconnect the adapter. Do this only if you contained the wrong machine.

Do not power off or delete the copy yet; you may need it to finish the restore test or to recover data from it.

Step 2: fix a duplicate MAC on the copy

Broadcom KB 313916 and KB 433860 describe the same approach: power off the copy, edit the network adapter, and change the MAC assignment. If it was Manual, set it to Automatic so vCenter generates a unique address, or enter a unique manual value from your own allocation register. To make vCenter regenerate an existing automatic address, Broadcom describes switching to Manual and back to Automatic.

Broadcom also gives an alternative for production machines: record the static IP configuration, remove the adapter, add a new adapter, then re-apply the IP.

• Verification: the PowerCLI check in step 5 shows no repeated MAC, the copy's adapter is still disconnected, and the new MAC appears in the copy's configuration.
• Rollback: re-entering the old MAC brings the conflict back. Only roll back if the copy is being retired.

Guest side effect: a new MAC, or a new adapter, is a new NIC to the guest. Windows may treat it as a new interface without the old static IP, and Linux may rename the interface. Re-apply the address deliberately; see Static IP Lost After a VM Restore or Virtual NIC Change. Software licensed to a MAC address may also need re-activation.

Step 3: fix a duplicate IP on the copy

While still isolated, give the copy a different address, or change its port group to a test network that is truly separate (its own VLAN, no route to production). Consider name and identity as well as the IP. A copy with the original's hostname that registers in DNS can still break clients after the IP is changed; see DNS Changed but Users Still Reach the Old Application.

• Verification: before reconnecting, confirm the copy's new address is free in IPAM, DHCP scopes and reservations, and with the address owner's allocation record, then check from a third machine that arping -D against it gets no reply (no reply alone is not enough, because an assigned owner may be offline); after reconnecting, both the original and the copy appear in neighbour caches with distinct IP–MAC pairs; event 4199 stops.
• Rollback: disconnect the copy's adapter again.

Step 4: two vCenters with the same instance ID

If the duplicate MACs come from two vCenter instances, fixing the VMs one by one is not enough. New VMs will keep colliding. Broadcom KB 313916 explains that you can change the instance ID. Changing it does not change existing VMs (only new VMs and new adapters get addresses from the new ID), and it requires a vCenter service restart. Treat this as a planned change with its own approval window:

• record the current ID and the existing MACs;
• check what else relies on the instance ID in your environment (the KB notes it is also used for UUID generation);
• schedule the restart;
• then fix existing duplicates as in step 2.

Verification: a test VM created afterwards gets a MAC with the new fourth octet. Rollback: set the old ID back and restart again; existing VMs are not affected either way.

Prefix- or range-based allocation is the longer-term design for sites with several vCenters on one network. It should be designed, not improvised during an incident.

Step 5: make restores and clones safe by default

• Restore and clone tests go to an isolated port group first, then connect to production only when deliberately promoted.
• Avoid manual MACs on templates and on VMs that will be cloned; if a MAC must be fixed for licensing, keep a register.
• When ESXi asks "moved or copied" for a VM whose original still exists, answer "I copied it" (the prompt's own advice is to answer "I copied it" if you don't know).
• Templates are generalised with Sysprep or the equivalent; see How to build and validate Windows Server templates for VMware.

What not to do

• Do not disconnect, re-IP or re-MAC the original until you have proved which machine is the copy.
• Do not disable duplicate address detection. Microsoft mentions Set-NetIPInterface -DadTransmits 0 only for well-managed environments. Turning detection off removes the warning, not the conflict, and lets two machines claim the address silently.
• Do not send gratuitous ARP from the copy (arping -U/-A) to "win" the address. It moves production traffic to the wrong machine.
• Do not flush ARP caches across the network as the fix. It hides the evidence for a few minutes and the conflict returns.
• Do not delete the original's virtual NIC. Removing and re-adding an adapter is a fix for the copy, not a diagnostic step.
• Do not change a vCenter instance ID during an incident without a planned service restart and approval.

Limitations

• Broadcom's MAC allocation guidance on TechDocs and in the KBs covers vCenter-generated addresses; behaviour of restore, replication and DR products after recovery varies by product and version, and was not verified here.
• Neighbour caches are sampled snapshots. A clean reading during a quiet period does not rule out a duplicate.
• The PowerCLI check covers one vCenter per connection and does not see physical machines or other hypervisors.
• arping only works within one broadcast domain and only for IPv4.
• Switch MAC-move logging and its commands differ by vendor and are not described here.
• This article does not cover domain identity problems a copy can cause (machine account passwords, DC replication). Those are separate decisions; see the related articles.

Acceptance checklist

• [ ] The production original and the copy are identified from records, not guesses.
• [ ] Evidence recorded: event 4199 text and MAC, neighbour cache readings with times, PowerCLI MAC listing, switch MAC-move logs if available.
• [ ] The copy's adapter was disconnected or isolated first; the original was untouched.
• [ ] A duplicate MAC on the copy was replaced while powered off; no repeated MAC remains in any vCenter on that network.
• [ ] The copy has a unique IP, or sits on a separate network, before reconnection.
• [ ] Hostname and DNS registration of the copy were considered.
• [ ] After reconnection: no new 4199 events, stable neighbour entries, no switch MAC moves, user drops stopped.
• [ ] If two vCenters share an instance ID, a planned change is raised rather than done ad hoc.
• [ ] Restore and clone procedures updated to use an isolated network first.

References

All accessed 2 November 2026. Broadcom knowledge base articles carry no stable publication date in the captured text; content as displayed on the access date.

• Broadcom KB 313916, "Virtual machine MAC address conflicts or has a duplicate MAC address when creating a virtual machine": https://knowledge.broadcom.com/external/article/313916/virtual-machine-mac-address-conflicts-or.html
• Broadcom KB 433860, "Intermittent RDP and Ping Drops Due to Cloned Virtual Machine MAC Address Conflict": https://knowledge.broadcom.com/external/article/433860/intermittent-rdp-and-ping-drops-due-to-c.html
• Broadcom KB 342208, "Renaming a virtual machine and its files in vSphere": https://knowledge.broadcom.com/external/article/342208/renaming-a-virtual-machine-and-its-files.html
• Broadcom KB 320246, "Changing or keeping a UUID for a moved virtual machine": https://knowledge.broadcom.com/external/article/320246/changing-or-keeping-a-uuid-for-a-moved-v.html
• Broadcom TechDocs, vSphere 7.0, "MAC Address Assignment from vCenter Server": https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/7-0/vsphere-networking/mac-addresses/mac-address-generation.html
• Microsoft Learn, "Event ID 4199 and Windows client can't get an IP address from the DHCP server": https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/event-4199-windows-client-cannot-get-ip-address-dhcp-server
• Microsoft Learn, Get-NetIPAddress: https://learn.microsoft.com/en-us/powershell/module/nettcpip/get-netipaddress
• Microsoft Learn, Get-NetNeighbor: https://learn.microsoft.com/en-us/powershell/module/nettcpip/get-netneighbor
• arping(8), iputils: https://man7.org/linux/man-pages/man8/arping.8.html
• ip-neighbour(8), iproute2: https://man7.org/linux/man-pages/man8/ip-neighbour.8.html
• RFC 5227, IPv4 Address Conflict Detection: https://www.rfc-editor.org/rfc/rfc5227.txt
• RFC 4862, IPv6 Stateless Address Autoconfiguration (Duplicate Address Detection): https://www.rfc-editor.org/rfc/rfc4862.txt

Related articles

• Static IP Lost After a VM Restore or Virtual NIC Change
• Domain Controllers on VMware: Snapshots and Restores
• How to build and validate Windows Server templates for VMware
• How to design and troubleshoot VMware networking

• DNS Changed but Users Still Reach the Old Application

• "The Trust Relationship Failed" After a Member Server Restore: Prove the Secure Channel and Repair It in Place

• Connections Half-Work Through Two Gateways: Proving Asymmetric Routing

Learning notes

1. A duplicate IP and a duplicate MAC are different faults with different evidence: the first shows one IP moving between two MACs, the second shows one MAC moving between switch ports.
2. The machine that logs event 4199 is usually the victim; the MAC in the message identifies the other party.
3. Contain first by disconnecting the copy's adapter. Fixing comes after you are certain which machine is the copy.
4. vCenter manages conflicts for generated MACs only; manual MACs and shared instance IDs across vCenters are the usual sources of duplicates.
5. A MAC change can make the guest see a new NIC, depending on the operating system and how it identifies interfaces, so plan the IP re-application and any MAC-bound licences.