ARP translates IPv4 addresses into MAC addresses so Layer 3 can communicate correctly over Layer 2 on the local network.

Facts (key topics)

• ARP is used only inside the same broadcast domain (LAN)
• ARP is stateless and unauthenticated (security risk)
• ARP cache reduces broadcast traffic and latency
• Gratuitous ARP is used for IP conflict detection and updating caches
• ARP works for IPv4 only (IPv6 uses NDP)

Overview

Function	Description
ARP request	Broadcast: “who has IP X?”
ARP reply	Unicast reply with the MAC address
Gratuitous ARP	An ARP sent by a device about itself
ARP cache	Temporary storage of IP↔MAC mappings
Timeout	Entries age out automatically

How ARP works

1. A host wants to send to a known IP but is missing the MAC
2. The host sends an ARP request (broadcast)
3. The correct host answers with an ARP reply (unicast)
4. IP↔MAC is stored in the ARP cache
5. Traffic can now be sent as normal Ethernet frames

📌 Only the first packet needs ARP – the rest uses cache.

ARP request / reply fields

Field	Request	Reply
Ethernet destination MAC	FF:FF:FF:FF:FF:FF (broadcast)	Requester’s MAC
Ethernet source MAC	Sender’s MAC	Target’s MAC
Sender IP / MAC	Sender IPv4 + MAC	Target IP + MAC
Target IP / MAC	Sought IPv4 / 00:00:00:00:00:00	Requester’s IP + MAC

Switches flood ARP requests to all ports in the VLAN. Example: PC1 (192.168.1.10) wants PC2 (192.168.1.20): “Who has 192.168.1.20? Tell 192.168.1.10”. Only one device replies – the owner of the IP.

ARP and routers (exam critical)

📌 A router never ARPs for the final destination – it ARPs for the next-hop IP. A PC sending to a remote network ARPs for its default gateway (192.168.1.1), not for the destination host. Routers keep one ARP table per interface.

Gratuitous ARP

An ARP request or reply where sender IP = target IP – “is anyone else using my IP?”. Sent proactively, not in response to anything. Usually an ARP request, sometimes a reply.

Used for

1. IP conflict detection: if another host answers, there is a conflict – common on interface up, DHCP lease, reboot
2. Updating ARP caches everywhere – after MAC changes or NIC failover
3. Redundancy/failover: when HSRP/VRRP/load balancer/firewall failover switches the active device, the new active sends a gratuitous ARP and hosts instantly learn the new MAC for the same IP – traffic continues without timeouts

Feature	Normal ARP	Gratuitous ARP
Initiative	Only when needed	Proactive
Sender IP ≠ target IP	Yes	❌ No
Purpose	Find a MAC	Announce own IP
Cache update	Requester only	All devices
Used for failover	Indirectly	Yes

⚠️ Can be abused for ARP spoofing / man-in-the-middle → countermeasures: DHCP snooping, Dynamic ARP Inspection (DAI).

ARP caching

• Local table on PCs, routers and L3 switches mapping IPv4 ↔ MAC
• Without cache every single packet would need an ARP request
• Dynamic entries: learned automatically, expire (Cisco aging ~4 hours), refreshed by new replies, traffic or gratuitous ARP
• Static entries: manual, never expire (rarely used – poor fault tolerance)

Problem	Without cache	With cache
Broadcast traffic	High	Low
Latency	High	Low
CPU load	High	Low
Scalability	Poor	Good

ARP cache	CAM table
IP → MAC	MAC → port
Layer 3	Layer 2
Hosts/routers	Switches

Cisco CLI

show ip arp
show ip arp vlan 10
show ip arp interface GigabitEthernet0/1
clear ip arp
arp 192.168.1.50 0050.56AA.BBCC ARPA    ! static entry
debug arp                                ! with care

Typical exam traps 🚨

Wrong assumption	Correct
ARP works across routers	❌ LAN only
ARP reply is broadcast	❌ Unicast
ARP entries are permanent	❌ Unless static
ARP is secure	❌ Can be spoofed

Common failure scenarios

Problem	Cause
No connectivity	ARP entry missing
Intermittent traffic	Stale ARP cache
Traffic to the wrong device	ARP poisoning
Slow failover	Cache not updated

CCNA rules: no ARP → no MAC → no Ethernet frame → no connectivity. No connectivity in the same subnet → check ARP before routing. Device announces its own IP → think gratuitous ARP.