Issue/Introduction
The platform or a manual command might have written the static IP address to Windows, but after Windows DAD marks the address as Duplicate, Windows does not use it as a valid source address and might retain a 169.254/16 APIPA address. In this case, do not conclude that VMTools failed to write the address.
Symptoms
- After the page assigns a static IP address,
ipconfigmainly shows a 169.254 address. Get-NetIPAddressshows the target IP address withAddressState=Duplicate.- Another address in the same subnet becomes Preferred on the same NIC and can reach the gateway.
- A normal ping or ARP check cannot find the original address. This does not disprove a transient conflict during the first DAD attempt.
Environment
Windows guests. The direct mechanism is Windows DAD/the customer Layer 2 network and is not limited to a ZSphere version.
Possible causes
First verify whether the address was written and check its state, and then compare it with a working address. If only one specific address is Duplicate, capture ARP traffic during DAD when that address is added again. Do not use ping alone to conclude that no device is using the address.
Issue classification
- Type: Environment issue (Windows DAD/customer Layer 2 network).
- Known issue: No. TIC-6141 is a Closed/Done field case, not a product bug.
- Direct cause: Windows received conflicting ARP traffic during DAD and marked the address Duplicate.
- Without a packet capture, do not assert that a real duplicate IP exists. Other possibilities include stale Proxy ARP/ARP suppression bindings, transient use, a duplicate MAC address, or reflected packets.
- Confidence: High that DAD prevents the address from taking effect; low for the conflict source until a packet capture identifies the MAC address.
Resolution
Check 1: Read the address state
- Read-only PowerShell:
Get-NetIPAddress -AddressFamily IPv4 |
Format-Table InterfaceIndex,InterfaceAlias,IPAddress,PrefixLength,AddressState,PrefixOrigin -Auto
Get-NetIPConfiguration
- If the target IP exists and is Duplicate: The configuration was written; the direct cause is the DAD conflict decision.
- If the target IP is completely absent: This is the configuration-not-written/interface-matching branch, and this article does not apply.
Check 2: Read NIC and current neighbor information
- Read-only PowerShell:
Get-NetAdapter -IncludeHidden | Format-Table Name,ifIndex,Status,MacAddress,InterfaceDescription -Auto
arp -a
- If the ARP table contains a MAC address for the target IP: Continue locating the device by MAC address, but verify that it is not a gateway proxy.
- If the ARP table has no entry: This shows only that no persistent normal ARP neighbor exists now; it cannot reconstruct the DAD moment.
Check 3: Capture ARP during DAD
- Purpose: Identify who sends the conflict signal for the target IP address.
- A network administrator runs this read-only packet capture on the KVM vnet/tap interface or a switch mirror port:
tcpdump -eni <vm-vnet-interface> arp
- If another source MAC claims or responds for the target IP: Use that MAC to inspect VM NICs, the bridge FDB, switch MAC table, and Proxy ARP/ARP suppression.
- If the local packet is reflected back: Check for a Layer 2 loop or port aggregation issue.
- If no conflict packet is captured but Windows still reports Duplicate: Collect Windows System events and a complete packet capture, and escalate.
Recommended actions
The operations in this section must be performed manually by an administrator with the required permissions.
Use a replacement address that is verified as Preferred and can reach the gateway, and temporarily exclude the problematic address from the address pool. Do not disable Windows DAD or force the use of a Duplicate address. Complete the packet capture and remove the conflict source before restoring the original address.
Long-term solution
Use the responding MAC address to remove the real duplicate, stale gateway proxy/EVPN suppression entry, duplicate MAC address, or Layer 2 loop. Add the address again, confirm that its state is Preferred, and then return it to the address pool.
Additional information
When to escalate
- Re-adding a production address and capturing packets is required.
- A MAC address was found but the device cannot be located.
- Multiple addresses are Duplicate at the same time.
- Windows continues to report Duplicate without any conflict packet.
Information to collect
Windows/ZSphere versions, NIC MAC/ifIndex, address-state output, comparison result with the replacement address, Windows System events, DAD-stage pcap, bridge FDB, and switch/gateway entries.
Related issues
- TIC-6141, Closed/Done.
- Status verified on 2026-08-06.
