Two Owners, One Address: Duplicate IPs on a TAP Bridge

One Windows client holds 10.8.0.2 and works until the startup order changes, then the same address is reported as a conflict and nothing about the client has changed. A second host on the same bridged segment claims the same value, and whichever machine finishes configuring last tends to lose. Both believe they own it, and the loser quietly stops using an address it was told to use. Treating that as a timing problem is what makes it recur at every reboot.

Read the conflict evidence before touching a bridge

Windows reports an address conflict together with the hardware address of the other claimant. That hardware address is the useful fact, because it maps to one interface on one host, while the event's display name tells you nothing about where the duplicate lives. Write the hardware address down before you change anything.

ARP-based duplicate detection probes for competing owners before an address is used and keeps watching afterwards. That is why a host which was absent while you configured the network can still cause a conflict an hour later. Probing is not a one-time check at boot. A machine that appears afterwards can take an address that has been in quiet use all day, which is why the failure reads as a race instead of a configuration error.

A conflict event on its own does not say which configuration created the other claim, and clearing addresses experimentally destroys the mapping that would have told you. The point of the evidence is to turn a hardware address into an interface you can inspect. Searching inventory by machine name usually sends you to the wrong host.

Inventory every claim on the segment

A bridged TAP setup joins Ethernet segments that used to be separate, so addresses that were unique inside their own networks can collide once frames share one link. That is why this fault class exists on a VPN and does not exist on the routed networks it replaced. Enumerate every possible owner rather than the first one you suspect.

Walk the list in this order: the addresses on each bridge device and its member ports, the OpenVPN pool and any per-client fixed assignment, and any DHCP server covering the bridged segment. Then match the hardware address from the conflict report against the interfaces you found.

ip -4 addr show | grep -E 'inet |^[0-9]+: '
bridge link show
ip neigh show dev br0

The pool and the DHCP range are the two owners people forget. Print both ranges together and look for an overlap before doing anything else. A hand-assigned bridge address and a pool that issues the same value will collide eventually, and the collision looks random until both ranges are printed side by side.

Number bridges only where they need an identity

In a normal host bridge, the bridge device carries the host's layer-three configuration and the Ethernet and TAP members act as ports. Giving each member its own address, or copying one setup script across several machines without changing the address, is how a single segment ends up with three owners of the same value. The members do not need identities of their own to forward frames. They need exactly one identity per host that must be reachable on that segment.

A bridge that only switches frames does not need an address on that segment at all. Leaving it unnumbered removes a whole class of collision, provided the host still has a management path you have verified. Confirm access first, remove the address second, and check reachability third.

If the address you are about to delete is the only route into the machine, deleting it as an experiment is a self-inflicted outage rather than a diagnosis. Verify the out-of-band path before you test anything.

Make the correction survive a reboot

Changing a live interface fixes the current boot and nothing else. Whatever recreates the address at startup will restore the conflict on the next reboot, and you will conclude the fix did not work when in fact it was never persistent. Note which file you changed, so the next reboot confirms a decision instead of revealing a surprise.

Find the owner of that configuration: a network manager profile, a per-interface file, a container or VM definition, or a cloud-init fragment. Change it there, then reboot one affected host deliberately to confirm the new value is what comes back. A reboot is the only test that proves persistence.

Reserve the bridge addresses inside the DHCP range as exclusions, or move them outside it. A reservation that exists only in a spreadsheet is not an exclusion, and the allocator will not read it.

Prove it with every client online

A single successful connection proves nothing, because the original symptom only appeared when the ordering changed. Bring up every intended client, vary the startup order, and repeat after a reconnect. Then restart the host that used to lose the race and confirm the address survives.

For direct confirmation, probe for a duplicate owner before assigning the address and watch the neighbour table afterwards. If nothing answers the probe and the address stays uniquely owned through a full restart cycle, the conflict is resolved rather than merely hidden. The commands below perform both checks on the bridge device. RFC 5227 describes the probing and announcement behaviour these tools exercise, and it is the reference to cite when someone proposes disabling detection instead.

arping -D -I br0 10.8.0.2
ip neigh show dev br0 | grep 10.8.0.2

A probe that gets no reply is the expected result on a clean segment. A probe that draws a response gives you the hardware address of the remaining owner, which is the same evidence the Windows event gave you at the start. Keep that output with the change record, because it is the only proof that the address is uniquely held.