A duplicate IP is not simply “two devices have the same number”—it creates competing Layer 2 delivery information
In an ordinary host subnet, an IPv4 address is expected to identify one active endpoint or one intentionally coordinated service identity. When two uncoordinated devices use the same address, nearby systems can learn different MAC addresses for that IP. The failure therefore sits at the boundary between Layer 3 identity and Layer 2 delivery.
Investigate the ownership behind an alert with AP Networking ARP and Address Conflicts Practice Test. The scenarios include static addresses inside a dynamic pool, secondary interface addresses, competing claims and supported virtual gateways. A brief recovery after clearing ARP is not evidence that the duplicate owner was removed.
This explains why a conflict can look intermittent even when cables, switching, DNS, and routing are otherwise functioning normally.
The strongest symptom is unstable identity, not generic network failure
One address alternates
The disputed IP works, fails, or reaches different content while neighboring IPs remain stable.
Wrong endpoint appears
A browser, SSH banner, printer page, or appliance interface identifies a different device at the same IP.
ARP owner changes
The same IPv4 address maps to MAC-A at one time and MAC-B later.
DHCP looks valid
A legitimate lease can coexist with an unmanaged static endpoint using the leased address.
Switching remains selective
Other endpoints on the VLAN can remain healthy because their identities are not disputed.
Reboots seem to “help”
Restarting a device may temporarily change which endpoint advertises or wins neighbor state without fixing ownership.
ARP is the key artifact because local IPv4 delivery ultimately needs a destination MAC address
When a host needs to send IPv4 traffic to a local neighbor, it needs a Layer 2 destination. ARP supplies the IPv4-to-MAC mapping. If 10.20.5.44 is legitimately Device A, neighbors should normally associate that IP with Device A's MAC. When Device B independently uses 10.20.5.44, it can introduce a competing mapping.
10:00:03 10.20.5.44 -> 00:11:22:33:44:55 10:01:41 10.20.5.44 -> 00:AA:BB:CC:DD:EE 10:03:08 10.20.5.44 -> 00:11:22:33:44:55
The changing mapping is far more specific than “ping failed twice.” It identifies instability in the address-to-MAC relationship that controls local delivery.
Sample more than one observer before blaming the entire subnet
If one laptop shows an unexpected ARP entry, that observation can still be local. Its cache may be stale, or the evidence may have been captured at an unrepresentative moment. Compare the mapping from another relevant neighbor, especially a default gateway or another client on the same Layer 2 domain.
If the gateway and multiple clients independently see 10.20.5.44 alternate between the same two MAC addresses, a single-client cache explanation becomes much weaker. You now have converging evidence of competing ownership.
A successful ping to a duplicated address may be misleading because it does not identify which device replied
Suppose a ping to 192.168.30.120 succeeds five times. That does not prove the intended printer owns .120. If a laptop also uses .120, the replies could come from whichever endpoint the sender currently reaches. A generic reachability test lacks endpoint identity.
Pair the test with ARP evidence, a device-specific application banner, switch location, or another artifact that distinguishes the competing systems. This is a recurring AP Networking principle: a successful checkpoint is useful only within the boundary of what it actually proves.
A DHCP lease can be completely valid and still collide with a manually configured endpoint
Consider a DHCP pool of 192.168.30.100–150. A printer was manually assigned 192.168.30.120 without a reservation or exclusion. Later, DHCP leases .120 to a laptop. The DHCP server followed its own configured rules: .120 was available in the dynamic pool. The hidden problem is that the address plan did not tell DHCP about the static owner.
This is why “DHCP shows a lease” does not settle ownership. Audit the dynamic range, exclusions, reservations, active leases, and manually addressed infrastructure together.
Fix ownership, not the symptom produced by stale or changing neighbor state
A durable repair makes one intended ownership model authoritative. Depending on the design, that can mean moving the static device outside the dynamic pool, creating an appropriate reservation, adding an exclusion, changing the DHCP range, or correcting the device that should never have used the address.
Repeatedly clearing ARP caches is not a durable repair. It may cause a neighbor to relearn one of the competing devices and temporarily appear healthy, but both endpoints remain capable of reclaiming the address.
ARP tells you who claims the IP; the switch MAC table helps tell you where that claimant is
| Evidence step | Question answered | Example |
|---|---|---|
| ARP/neighbor table | Which MAC is currently associated with the IP? | 10.40.8.55 → MAC-A, later MAC-B |
| Switch MAC table | Where was that source MAC learned in this VLAN? | MAC-A → Gi1/0/12 |
| Follow uplink/trunk | Is the endpoint downstream? | MAC-B → trunk Gi1/0/48 |
| Downstream MAC lookup | Which edge port ultimately contains it? | MAC-B → access Gi1/0/37 |
| Asset/config record | Which device should own the IP? | Server A documented as .55 |
Swipe horizontally to see the full table.
This converts “there may be an IP conflict” into two identifiable endpoints and an ownership decision supported by the address plan.
A duplicate address matters only within the network context where the claims can compete
Identical private IPv4 addresses can legitimately exist in completely separate networks. Even on the same physical switching infrastructure, isolated VLANs can reuse address space because their Layer 2 domains are separate. Record the VLAN and routing context before declaring that matching text strings represent a conflict.
The useful failure is two active identities whose claims affect the same neighbors or forwarding context. That is why ARP evidence and VLAN-aware MAC tracing belong together.
Correct DNS can coexist perfectly with a duplicate IP address
If printer.example consistently resolves to 192.168.30.120, DNS has supplied the expected Layer 3 destination. The failure can happen afterward, when local delivery resolves .120 to different MAC addresses. Changing the DNS record would not remove either competing endpoint.
A particularly strong clue is stable name resolution paired with changing device identity at the resolved IP. Continue with DNS Troubleshooting when name resolution itself is the unstable dependency.
Do not collapse two different identity failures into one diagnosis
Duplicate IP evidence: one IPv4 address is associated with different MAC addresses over time. Duplicate MAC evidence: one MAC address is learned from different switch locations or belongs to more than one active endpoint. The symptoms can overlap because both can disrupt delivery, but the artifacts point in different directions.
If IP X alternates between MAC-A and MAC-B, start with Layer 3 ownership. If MAC-A rapidly alternates between access ports, inspect Layer 2 identity, mobility, topology, or loop behavior. See MAC Address Table Explained for the switching evidence boundary.
Virtual machines and appliances can duplicate a static IP when host-specific configuration survives cloning
A lab image or appliance template can contain a manually configured address. Starting a second copy without changing that identity can immediately create a conflict. This is especially confusing when both systems provide the same service because users may not notice they are reaching different instances.
After cloning, verify the intended addressing method and other host-specific identity settings. Do not assume virtualization itself is the problem; the mechanism is duplicated configuration.
A shared or virtual IP in a high-availability design is not automatically an accidental conflict
Some redundancy designs intentionally present one service or gateway IP while coordinating which system is active and how Layer 2 identity is advertised. Seeing multiple physical systems associated with a service design is therefore not permission to “fix the duplicate” by changing a critical address.
Architecture is part of the evidence
Before modifying a gateway, firewall pair, cluster, or other highly available service, determine whether the address is documented as virtual/shared, how ownership should move during failover, and what MAC behavior is expected. Accidental duplication is uncoordinated ownership; high availability is coordinated ownership.
A printer's static address overlaps the DHCP pool
Expected: Printer P owns 192.168.30.120. Observed: the gateway alternates .120 between PrinterMAC and LaptopMAC. DHCP shows LaptopMAC holds a valid lease for .120. The switch locates PrinterMAC on the printer port and LaptopMAC on a wireless access path.
The evidence fits a static/dynamic overlap. The printer is not automatically wrong because it is static, and DHCP is not automatically malfunctioning because it issued the lease. The address plan allowed two independent allocation methods to claim the same address.
Repair the plan so .120 has one authoritative owner, then verify the DHCP service can no longer issue a conflicting lease and the printer remains the stable owner.
The “server” sometimes displays a new appliance's management page
Users browse to server44.example. DNS consistently returns 10.60.8.44. Sometimes the expected server loads; sometimes a newly installed appliance login appears. The gateway's ARP table alternates .44 between ServerMAC and ApplianceMAC.
This is stronger than a generic packet-loss report because the unintended page fingerprints the second endpoint. DNS is a known-good checkpoint. Trace both MACs, verify the asset/address records, and inspect the appliance's static configuration. Changing DNS would merely redirect around the disputed identity rather than resolve ownership.
Only one laptop shows the “wrong” MAC while the gateway remains stable
A laptop maps 10.50.4.25 to MAC-B, but the default gateway and two other clients consistently map .25 to MAC-A. Switch evidence shows only MAC-A at the expected endpoint location, and no independent observer sees MAC-B claim the address.
The duplicate-IP hypothesis is now weaker. Investigate the laptop's local neighbor state, capture timing, or other local causes before changing the address plan. This counterexample matters because good troubleshooting must identify evidence that can disprove the favored hypothesis.
Record ownership changes alongside user-visible behavior
09:10 User cannot reach 10.40.8.55 09:11 Gateway ARP: .55 -> MAC-A 09:13 Gateway ARP: .55 -> MAC-B 09:14 Client opens Device B interface 09:16 Gateway ARP: .55 -> MAC-A 09:17 Expected service returns
The timeline links a Layer 2 ownership change with the application symptom. It also preserves evidence that would disappear if you immediately cleared caches or rebooted both devices.
24 duplicate-IP evidence flashcards
These cards emphasize diagnosis rather than memorization: ARP boundaries, DHCP/static overlaps, switch tracing, alternative explanations, coordinated virtual IPs, repair, and verification.
One successful ping is not enough—prove one stable owner remains through the old failure window
After correction, sample ARP/neighbor mappings from multiple relevant observers. Confirm they consistently associate the IP with the intended identity. Verify DHCP records and exclusions/reservations agree with the new ownership model. Check the legitimate MAC's switch location and test the actual application that users need.
Observe long enough to exceed the interval in which the conflict previously alternated. If the problem appeared every two or three minutes, a ten-second test is weak verification. Also confirm monitoring, DNS-dependent access, printing, management, or other systems that rely on the disputed address still reach the intended endpoint.
Six tempting conclusions that go beyond what the artifact proves
“Ping works.”
Some endpoint answered; identity is not yet proven.
“DHCP lease is valid.”
The server allocated the address according to its state; an unmanaged static owner can still exist.
“DNS is correct.”
The name points to the expected IP; local IP-to-MAC ownership can still be unstable.
“One ARP entry is wrong.”
A local stale cache remains possible until other observers corroborate it.
“Two systems use a service IP.”
Could be intentional HA behavior; check architecture and coordinated ownership.
“Clearing ARP fixed it.”
Local state changed; the competing endpoint may still reclaim the IP.
Use changing identity → competing-owner hypothesis → two-table trace → ownership decision → verification
Observation: “10.60.8.44 alternates between MAC-A and MAC-B in the gateway ARP table, and users sometimes reach a different appliance.” Mechanism: “Local delivery for the same IPv4 address is being directed to different Layer 2 identities.” Next evidence: “Trace both MACs through switching and compare DHCP/static/asset records.” Correction: “Remove the uncoordinated address claim according to the intended plan.” Verification: “Confirm one stable owner across multiple observers and retest the original service.”
That answer is narrower and more defensible than blaming DNS, replacing a switch, or rebooting every endpoint on the VLAN.
Capture five fields that turn an intermittent complaint into traceable evidence
| Field | What to record | Why it matters |
|---|---|---|
| Observer | Gateway, client, server, etc. | Separates local cache state from shared evidence. |
| Timestamp | Exact observation time | Connects ownership changes to symptoms. |
| IPv4 address | The disputed identity | Keeps the investigation scoped. |
| MAC address | Current claimant | Identifies competing Layer 2 identities. |
| Switch location/VLAN | Learned port/path and VLAN | Turns each MAC into a traceable endpoint. |
Swipe horizontally to see the full table.