An IP conflict means one IPv4 address is being claimed by more than one active Layer 2 identity
The useful question is not merely “does the OS say duplicate IP?” The diagnostic goal is to prove competing ownership of the same address, identify both devices, determine why the allocation plan allowed the collision, correct the source of duplication, and verify that the IP-to-MAC relationship remains stable.
Test the conflict correction with AP Networking ARP and Address Conflicts Practice Test. The explanations ask for claimant attribution, an approved nonoverlapping address plan, updated service references and stable task outcomes for both endpoints rather than one successful ping after reassignment.
The strongest evidence pattern
The same IPv4 address maps to different MAC addresses over time, and switch evidence places those MAC addresses on different devices or ports.
What can cause a duplicate IP?
Similar symptoms can come from very different allocation mistakes
Static inside DHCP poolA manually configured device uses an address the DHCP server is still free to lease.
Two static devicesTwo endpoints are manually configured with the same IPv4 address.
Cloned VM or imageA copied system inherits a static address from its source.
Stale reservation / documentationThe address plan says one thing while active configuration says another.
The symptom may look identical to the user—intermittent disconnects, wrong device reached, or “IP address conflict” warnings—but the remediation must match the allocation mechanism.
ARP ownership
Track the disputed IP as an ownership timeline
Gateway ARP table
10:00
10.5.20.44 → 00:11:22:33:44:55
10:02
10.5.20.44 → AA:BB:CC:DD:EE:FF
10:04
10.5.20.44 → 00:11:22:33:44:55
Interpretation:
The same IPv4 address is alternating between two Layer 2 identities.
What this provesTwo different MAC addresses have been associated with the same IPv4 address in the observed neighbor context.
What it does not proveWhich MAC is legitimate, which device owns each MAC, or why both devices claim the address.
Switch localization
Use MAC tables to turn duplicate ownership into physical or logical location
Switch MAC table
00:11:22:33:44:55 → Gi1/0/8
AA:BB:CC:DD:EE:FF → Gi1/0/23
Inventory:
Gi1/0/8 → print room printer
Gi1/0/23 → user desk / laptop dock
ARP identifies the competing Layer 2 owners. The switch MAC table then tells you where those MAC addresses are learned. Together, the artifacts move the diagnosis from “duplicate IP exists” to “these two specific attachment points are competing.”
Do not overclaim: a MAC learned on an uplink may belong to a device behind another switch. The switch table identifies the next Layer 2 direction, not necessarily the final physical endpoint.
DHCP vs static collision
A DHCP server can be working correctly while still participating in the conflict
DHCP scope:
10.5.20.20 – 10.5.20.100
Lease:
10.5.20.44 → laptop MAC AA:BB:CC:DD:EE:FF
Printer:
Static IP 10.5.20.44
Root allocation problem:
Static printer address was never excluded/reserved outside the active dynamic pool.
The DHCP server is not necessarily malfunctioning. From its own database, 10.5.20.44 may appear available. The real design failure is that a static device occupies an address the DHCP service is permitted to assign.
Correct fix: assign the printer an address that follows the site's static-address plan or exclude/reserve the address correctly, then reconcile DHCP records and documentation.
Case 1
A static printer collides with a laptop lease
User symptom:
Laptop intermittently loses access.
Sometimes pinging 10.5.20.44 reaches the printer.
Evidence:
DHCP lease 10.5.20.44 → laptop MAC
Printer config 10.5.20.44 → printer MAC
Gateway ARP entry alternates between both MAC addresses.
Prove the duplicate: the same IP maps to two different MACs.
Identify both owners: DHCP lease identifies one; switch/inventory identifies the other.
Find the allocation fault: static printer IP sits inside the dynamic DHCP range.
Correct the plan: move/reserve/exclude appropriately so each device has a unique address.
Verify stability: ARP remains mapped to one MAC and sessions stop alternating.
Case 2
Two cloned virtual machines boot with the same static address
VM-A:
10.60.8.25/24
MAC 00:50:56:AA:AA:01
VM-B:
10.60.8.25/24
MAC 00:50:56:AA:AA:02
Both boot after template cloning.
This conflict does not involve DHCP at all. Checking only the DHCP lease database would miss the mechanism. Compare the guests' local static configuration and hypervisor inventory.
Shared symptomIntermittent reachability or duplicate-address warnings can look like the printer/DHCP case.
Different causeThe duplicate was copied into two static VM configurations.
Case 3
Two manual static devices use the same address
Server A:
192.168.50.20/24
MAC 10:10:10:10:10:10
Server B:
192.168.50.20/24
MAC 20:20:20:20:20:20
DHCP scope:
192.168.50.100–200
Observation:
No DHCP overlap exists.
The dynamic pool is irrelevant to this specific conflict. The correct branch is static-address inventory and endpoint configuration.
Exam trap: “Check DHCP” is not always the best answer simply because duplicate IPs exist.
Case 4
A device is replaced, but the old static IP is reused accidentally
Old camera:
10.30.4.60 → removed from expected location
New camera:
10.30.4.60 → installed
Unexpected:
old camera remained powered on through a secondary switch path
ARP:
10.30.4.60 alternates between old-camera MAC and new-camera MAC
Change history matters. “The conflict started after replacement” is useful because the replacement event explains why two devices now claim the same static address.
★ Addressing Practice • IP Address Conflict Troubleshooting
A five-minute warm-up for IP Address Conflict Troubleshooting
Tomorrow’s opening question can pick up where this page leaves off: have students explain where the addresses come from and what they would check when a device cannot connect. The 300 Bell Ringers give you short questions and teacher answers you can use without preparing a new starter each morning.
An OS warning is useful, but it is not the complete evidence chain
Many operating systems can detect address conflicts using ARP-based duplicate-address detection behavior. Treat a warning as a strong clue, then identify the competing MAC/device and reconcile the allocation source.
Warning supportsThe host detected evidence that another device is claiming the same address.
Warning does not identifyThe other device's physical location, whether it is static or DHCP, or which device should keep the address.
Why ping is misleading
A successful ping to the disputed IP does not tell you which duplicate answered
ping 10.5.20.44
Reply from 10.5.20.44: time<1ms
Question:
Was the reply from the printer or the laptop?
Ping alone cannot answer.
Use ARP/neighbor identity and switch MAC location to determine which Layer 2 owner received the frame.
Addressing & Subnetting Lab • 120 Missions
Let students try IP Address Conflict Troubleshooting for themselves
Reading the explanation is a start. In the browser simulator, students work through a broken network, choose what to test and see whether their fix worked. It gives them another chance to use what they learned about IP Address Conflict Troubleshooting.
Exam trap: “Ping works” does not prove the correct device owns the address.
Why DNS can still be correct
Correct name resolution can coexist with a duplicate-IP failure
DNS:
printer.example → 10.5.20.44
DNS answer: correct
ARP:
10.5.20.44 → laptop MAC
Result:
Frames may go to the wrong device even though DNS returned the intended IPv4 address.
DNS answers the name-to-IP question. ARP/neighbor resolution answers the local IP-to-link-layer delivery question. A conflict can therefore exist entirely below a correct DNS answer.
Failure signatures
Recognize the patterns that make a duplicate IP worth testing
Observed pattern
Why duplicate IP is plausible
Best next evidence
Competing explanation
IP-to-MAC mapping changes repeatedly
Two devices may claim one IP
ARP/neighbor timeline + MAC table
Legitimate device replacement/failover if designed
User reaches wrong device at same IP
Frames may alternate between duplicate owners
ARP + endpoint identity
Proxy, load balancer, NAT, stale DNS depending on design
Conflict starts when a new device is installed
New device may reuse an existing static address
Change record + endpoint configs
Unrelated topology or VLAN change
DHCP lease matches a static device IP
Dynamic/static allocation overlap
Scope, exclusions, lease, static inventory
Stale lease if device no longer active
Two cloned systems report same static IP
Image/template copied address
Guest configs + MAC identities
Hypervisor or VLAN issue
Swipe horizontally to inspect the failure signatures.
Addressing Exam Practice • IP Address Conflict Troubleshooting
Check whether IP Address Conflict Troubleshooting has really stuck
Once students have worked through this topic, give them questions mixed in with the rest of the course. The Exam Prep Vault includes practice exams, multiple-choice questions and artifact labs so they cannot rely on a chapter heading to tell them what to do.
Gateway ARP changes to laptop MAC. Printing fails.
Printer sends traffic; ARP flips back to printer MAC.
User's laptop session becomes unstable.
The synchronized timeline ties the user-facing failures to competing ownership more strongly than a one-time snapshot.
False positives and lookalikes
Not every changing MAC mapping is an accidental duplicate
Some network designs intentionally move or virtualize addresses. High-availability systems, first-hop redundancy, clustering, proxy ARP, load-balancing, and failover can create address-to-MAC behavior that looks unusual. The scenario's documented design matters.
Premium Routing Feedback
Spend less time marking explanations about IP Address Conflict Troubleshooting
When students explain their answer, it takes more than a right-or-wrong check to see what they understand. The Grading Copilot helps you review how they used the clues, where their explanation falls short and what feedback to give next. You make the final grading decision.
Falsifying question: Is the shared or moving address an intentional virtual IP with documented failover behavior? If yes, do not label it an accidental conflict merely because more than one device participates over time.
DHCP audit
Reconcile four things: scope, exclusions, reservations, and static inventory
Item
Question
Conflict risk
Dynamic scope
Which addresses may be leased?
Static devices inside this range can collide
Exclusions
Which addresses must DHCP never issue?
Missing exclusions can expose static ranges
Reservations
Which client identity should receive a predictable address?
Wrong reservation identity can create unexpected reuse
Static inventory
Which devices are manually configured?
Undocumented statics are hard to protect from reuse
Swipe horizontally to use the DHCP audit table.
Packet-path reasoning
The conflict can redirect local delivery before a router or firewall matters
Client wants 10.5.20.44 on same /24.
1. Client resolves 10.5.20.44 to a MAC using ARP.
2. Switch forwards frame toward that MAC.
3. If ARP points to the wrong duplicate owner,
traffic never reaches the intended device.
Remote firewall:
Not part of this same-subnet forwarding decision.
This is why changing a remote firewall or Internet route is a poor first response to a demonstrated local duplicate-IP conflict.
NEW • COMPLETE 180-DAY TEACHER CURRICULUM
Teach IP Address Conflict Troubleshooting as part of a planned school year
This page gives you one topic. The 180-Day Teacher Curriculum puts it into a full course plan, with daily teaching notes, student activities and checks for understanding. Use it when you need to know what comes before this lesson and what to teach next.
Capture both MAC addresses associated with the disputed IPv4 address.
Locate each MAC in switch tables, AP client tables, hypervisor inventory, or endpoint management.
Read each device's IP source: DHCP, reservation, static, cloned template, or other configuration.
Compare against the authoritative address plan to determine which ownership is intended.
Remediation
Fix the allocation source—not only the symptom
Static/DHCP collisionMove static assignment or correct DHCP exclusion/reservation policy.
Two static devicesRenumber one according to the address plan and update dependent records.
Cloned systemAssign unique network configuration before putting both instances in service.
Stale documentationUpdate the authoritative inventory so the same collision is not reintroduced.
Clearing ARP/neighbor cache may accelerate recovery after the underlying conflict is fixed, but cache clearing alone does not solve duplicate ownership.
Verification
One stable IP-to-MAC owner is the key post-fix evidence
Repeat ARP/neighbor observations over time and confirm one intended MAC remains associated with the IP.
Verify DHCP leases, exclusions, reservations, and static inventory now agree.
Confirm switch/AP location matches the intended device.
Retest the original application or service, not only ping.
Observe long enough to cover the previous recurrence pattern.
Confirm duplicate-address warnings stop.
Weak verification: one successful ping immediately after clearing caches. The conflict may simply not have resurfaced yet.
Changed-fact reasoning
One new artifact should be allowed to change the diagnosis