What does arp -a show, and how can you tell from the ARP table that you've been ARP-poisoned?

arp -a lists IP↔MAC mappings the host has cached. After poisoning, you'll see the gateway's IP paired with the attacker's MAC — same MAC for two different IPs is a giveaway.

Normal output:

? (192.168.1.1) at 00:11:22:33:44:55 [ether] on eth0   ← real gateway
? (192.168.1.42) at AA:BB:CC:DD:EE:FF [ether] on eth0  ← some other host

Poisoned output:

? (192.168.1.1) at AA:BB:CC:DD:EE:FF [ether] on eth0   ← gateway IP, attacker MAC!
? (192.168.1.42) at AA:BB:CC:DD:EE:FF [ether] on eth0  ← attacker IP, attacker MAC

Same MAC in two rows = red flag.

Cross-platform:

Detection in practice:

• Compare current MAC of gateway to a known-good baseline
• Tools like arpwatch monitor changes and alert
• Switch with Dynamic ARP Inspection rejects forged ARPs

Why ARP cache lifetime matters:

Default ARP cache timeout is short (60-300 seconds). After cache entries expire, your machine ARPs again — if the attacker is still flooding forged ARPs, the new entry is poisoned again. If they stopped, you'd get the real MAC.

Sanity check the gateway:

ip route                     # See current default gateway IP
arp -n | grep <gateway_ip>   # Get its MAC
# Compare to expected MAC (from inventory, baseline, or a trusted host)

Tip: On a switched network, normally you don't see other hosts' MACs unless you've talked to them. After a sweep + DHCP request, your ARP table fills up — and that's also when poisoning becomes detectable.

Go deeper:

• Address Resolution Protocol (Wikipedia) — the IP↔MAC cache arp -a reads, and why the same MAC under two IPs is anomalous.
• arpwatch (Wikipedia) — the daemon that automates this detection by alerting on changed IP↔MAC pairings.