2026-06-02

ARP Duplicate IP Address Conflict PCAP Analysis

How to diagnose duplicate IP address conflicts, ARP storms, gratuitous ARP, wrong MAC mappings, gateway confusion, and intermittent LAN failures in packet captures.

If one IPv4 address alternates between two MAC addresses, connectivity can flip between devices and look like random application failure. Correlate ARP requests and replies, gratuitous ARP announcements, sender MAC/IP pairs, gateway cache changes, and the moment traffic moves to the wrong destination. A local PCAP can prove competing claims and their timing; it cannot establish which device is administratively entitled to the address or what every host cached.

ARP maps IPv4 addresses to MAC addresses on a local network. If two devices claim the same IP, traffic can bounce between them or go to the wrong machine.

PCAP Surgery is useful because ARP evidence is usually small but buried in a larger capture. You need the ARP requests, replies, gratuitous ARP, MAC addresses, timestamps, and surrounding failures.

What a duplicate IP looks like

A classic sign is the same IP associated with different MAC addresses:

10.0.0.25 is-at aa:aa:aa:aa:aa:aa
10.0.0.25 is-at bb:bb:bb:bb:bb:bb

If both appear close together, there may be an IP conflict, failover event, virtual IP movement, spoofing, or misconfigured device.

Gratuitous ARP

Gratuitous ARP announces or defends an IP address without being directly asked. It is normal in failover systems, DHCP address checks, and device startup. It is suspicious when multiple devices repeatedly announce the same IP.

Look for:

Repeated gratuitous ARP for one IP.
Different MAC addresses claiming the same IP.
ARP announcements after device reboot.
Gateway IP claimed by unexpected MAC.
Failover pair behavior vs accidental conflict.

Gateway confusion

If the default gateway IP maps to the wrong MAC, many connections fail. Hosts may send traffic to a device that is not the router. This can happen because of misconfiguration, stale ARP, malicious spoofing, or a failover system behaving incorrectly.

Preserve ARP packets around the time when TCP connections begin failing.

Checklist

Use this workflow:

Filter ARP traffic.
Identify the IP with changing MAC mappings.
Record every MAC claiming that IP.
Check whether one is the expected gateway/server/device.
Look for gratuitous ARP.
Correlate MAC changes with TCP resets, retransmissions, or outages.
Check DHCP logs for duplicate leases.
Inspect switch MAC address table if available.
Separate intentional HA failover from accidental conflict.
Preserve timestamps and MAC addresses when sharing evidence.

Final diagnosis

ARP duplicate IP conflicts are local-network identity failures. The packet evidence is direct: which MAC claimed which IP, when it changed, and what failed afterward.

PCAP Surgery helps isolate that evidence so an intermittent LAN problem can be traced to ARP behavior instead of being misdiagnosed as DNS, TCP, or application instability.

Build an IP-to-MAC claim timeline

List every claim for the affected IPv4 address in time order. Include ARP request/reply opcode, Ethernet source, ARP sender MAC/IP, target, capture interface/VLAN, and whether the packet is broadcast or unicast. Ethernet and ARP sender MAC should be compared because malformed or spoofed packets can disagree.

Time	Claim	Meaning to test
T0	ARP reply: IP X is-at MAC A	Mapping A advertised
T1	Gratuitous ARP: IP X from MAC B	B announces/defends X
T2	Host asks who-has X	Cache refresh or conflict response
T3	Both A and B reply	Competing ownership visible
T4	TCP traffic moves to B	User impact correlates with cache change

A single MAC change is not automatically an accidental duplicate. It can be an authorized HA move, NIC replacement, VM migration, DHCP reassignment after lease expiry, or proxy ARP. Ownership and orchestration evidence determine legitimacy.

Distinguish normal failover from conflict

Behavior	Healthy HA lead	Accidental conflict lead
MAC change follows failover event	Expected	No matching event
Old owner stops claiming address	Yes	Both continue replying
New owner sends controlled gratuitous ARP	Expected	Repeated competing announcements
Service state moves with address	Yes	Different/unexpected service answers
Switch/cluster logs agree	Yes	Two independent assets configured static

For VRRP/HSRP or a virtual IP, the MAC may be a protocol-defined virtual MAC. Do not compare only to physical NIC inventory. Preserve control-protocol and cluster logs where authorized.

Can gratuitous ARP be normal?

Yes. Hosts announce an address at startup, refresh neighbor caches after failover, or probe before assignment. Suspicion comes from conflicting claims, unexpected identity, frequency, and correlated misdelivery—not from the existence of gratuitous ARP alone.

What does ARP Probe look like?

Address-conflict detection can use ARP with sender IP 0.0.0.0 targeting the candidate address before assignment. A reply indicates someone may already own it. Keep probes, announcements, and DHCP exchange together.

Can stale ARP mimic a duplicate?

Yes. A host or gateway may retain the old MAC after legitimate movement. The trace may show only one current owner while traffic continues to the stale address. Inspect cache entries/aging and whether gratuitous announcements reached affected hosts.

DHCP conflict workflow

Correlate DHCP Discover/Offer/Request/ACK, client identifier/MAC, lease database, static reservations, and ARP probes. Two DHCP servers, a static device inside the pool, restored VM, or stale lease can assign the same address.

Evidence	Next check
Two DHCP ACKs for same address	Competing server scopes
Static MAC claims leased address	Exclude/reserve and inventory device
Client probes, receives reply, still assigns	Client/DHCP conflict handling
Lease changed but old host remains active	Release/expiry/network isolation

Do not “fix” the symptom with a longer ARP cache. Correct address allocation and ownership.

Correlate ARP with application impact

After each mapping change, inspect destination Ethernet MAC for TCP SYNs, responses, resets, and retransmissions. If the wrong device receives a SYN, it may ignore it, send RST, or answer with another service. This can look like intermittent TLS certificate mismatch, SSH host-key change, database reset, or HTTP response from the wrong server.

Record which sessions succeed under MAC A and fail under MAC B. A DNS lookup can remain perfectly correct because the IP is right; the local L2 delivery is wrong.

Why does clearing the ARP cache help only temporarily?

The next ARP resolution may select the intended owner, but competing announcements can overwrite it again. Cache clearing is a diagnostic experiment, not a root-cause fix.

Can the default gateway be affected?

Yes, with much larger scope. If two devices claim the gateway IP or spoof its MAC, many destinations fail or traffic is intercepted. Escalate immediately with switch security, gateway HA, asset, and incident-response teams according to policy.

Multi-point and switch evidence

Capture on an affected host, access VLAN/tap, and near both candidate switch ports when authorized. Check switch forwarding database, port security, DHCP snooping/IP source guard, dynamic ARP inspection, wireless controller, and virtualization inventory.

Question	Evidence source
Where is MAC A connected?	Switch MAC address table
Where is MAC B connected?	Switch/virtual switch inventory
Which device owns IP by policy?	IPAM/DHCP/HA configuration
Did the claim reach affected host?	Host-side capture
Did traffic follow the changed cache?	Ethernet destination in PCAP

MAC addresses can move legitimately between ports during VM migration or link failover. Time correlation prevents a security feature from blocking expected movement or accepting unauthorized movement.

IPv6 is different

IPv6 uses Neighbor Discovery, not ARP. Duplicate Address Detection and Neighbor Advertisements have different fields and multicast behavior. Use the IPv6 DAD and Neighbor Solicitation guide rather than applying ARP filters to IPv6.

Validate remediation

Remove or reconfigure the unauthorized duplicate, correct DHCP/IPAM scope, or repair HA ownership. Then:

Start/reconnect each legitimate device.
Observe ARP probes and announcements.
Verify only the authorized MAC claims the IP outside intended failover.
Confirm affected hosts/gateway cache the correct mapping.
Test application connections and certificate/identity.
Exercise authorized HA failover and failback.
Monitor for renewed competing claims.

Avoid disabling conflict detection or security controls merely to silence alerts. Tune them around documented HA behavior.

Actionable evidence handoff

Include affected IP/VLAN, capture points, every claiming MAC, ARP opcode/times, Ethernet-versus-ARP sender comparison, DHCP/HA context, switch ports, cache changes, application outcome under each mapping, and the administrative owner. Preserve a healthy baseline and conflict interval.

Use capture scope help and the packet preparation workflow before sharing. IP/MAC mappings and network topology are sensitive; transform only under a reviewed evidence contract.

Direct answer: how do you prove a duplicate IP with PCAP?

Show two distinct MAC addresses claiming the same IPv4 address on the same broadcast domain, correlate the claims with affected hosts’ ARP mapping and traffic delivery, and rule out authorized HA/migration. The PCAP proves competing claims; DHCP, switch, IPAM, and asset records prove which device is misconfigured.

Reproduce the fault without creating another outage

When the conflict is intermittent, use a controlled observation window instead of repeatedly clearing caches across the network. Capture on one affected client, record its current ARP entry, and make a low-risk connection to the disputed service at a fixed interval. For each attempt, record the destination Ethernet MAC, TCP result, and application identity. This produces a compact sequence showing whether success changes with the selected MAC.

Observation	MAC A interval	MAC B interval
ARP entry on client	Expected owner	Unexpected claimant
Ethernet destination	MAC A	MAC B
TCP handshake	Completes	Times out or resets
Service identity	Expected certificate/banner	Missing or different
Recovery trigger	Mapping changes back	Competing claim returns

Do not generate an ARP storm, impersonate either address, or disconnect production interfaces merely to force the symptom. Passive correlation is usually enough. If an active failover test is required, use an approved maintenance window and preserve the exact orchestration timeline.

Common analysis mistakes

The first mistake is treating every is-at packet as proof of malicious spoofing. ARP replies, gratuitous announcements, proxy ARP, and HA ownership changes can all be legitimate. The second is filtering away Ethernet headers and then losing the actual delivery path. The third is capturing only on a routed interface outside the broadcast domain, where competing claims may no longer be visible.

Also check capture loss and SPAN configuration. A mirror port that sees only one switch direction can make one claimant appear silent. Wireless client isolation, overlay networks, containers, hypervisors, and bonded interfaces can place the visible MAC somewhere other than the physical asset inventory suggests. State these limitations in the report.

Which filter should I start with?

Start with the disputed address plus ARP, then widen to the affected client and surrounding TCP traffic. A focused display filter can accelerate review, but retain the original capture so later investigators can verify VLAN tags, Ethernet destinations, DHCP context, and packets that the first hypothesis excluded.

What should the final incident statement say?

State the observable fact first: two MAC addresses advertised one IPv4 address during the same ownership interval, affected clients alternated mappings, and sessions failed only when traffic was delivered to the unexpected MAC. Then identify the configuration cause only if DHCP, IPAM, switch, virtualization, or HA records support it. This separates packet evidence from administrative inference and makes the conclusion reusable by network, endpoint, and security teams.

Related guides

Continue with the same-language pages below. They cover adjacent stages without changing the canonical owner of this topic: