G
GuideDevOps
Lesson 9 of 28

ARP (Address Resolution Protocol)

Part of the Networking Basics tutorial series.

ARP is the protocol that answers the fundamental question: "I know your IP address, but what's your MAC address?"

The Problem ARP Solves

Devices on a local network (LAN) communicate using MAC addresses, but applications communicate using IP addresses. We need a way to map between them.

Application layer knows: "Send to 192.168.1.50"
Network layer knows: "That resolves to IP 192.168.1.50"
Link layer needs: "Send to MAC address aa:bb:cc:dd:ee:01"
But how do we figure out the MAC? → ARP!

How ARP Works

Scenario: Your computer (192.168.1.100) wants to reach 192.168.1.50

Step 1: Check ARP Cache

  • Your computer checks its local ARP cache
  • If found, use the cached MAC address
  • If not found, proceed to Step 2

Step 2: Send ARP Request

"Who has IP 192.168.1.50? Send your MAC to 192.168.1.100"

Source MAC: aa:bb:cc:dd:ee:01 (your MAC)
Source IP: 192.168.1.100 (your IP)
Dest MAC: ff:ff:ff:ff:ff:ff (broadcast — everyone)
Dest IP: 192.168.1.50 (who has this?)

Message: ARP Request

Step 3: Broadcast on Local Network

  • ARP request sent to everyone on the network (broadcast)
  • Every device receives it
  • Devices check: "Is this my IP?"

Step 4: ARP Reply Only 192.168.1.50 responds:

Source MAC: bb:cc:dd:ee:ff:02 (target's MAC)
Source IP: 192.168.1.50 (target's IP)
Dest MAC: aa:bb:cc:dd:ee:01 (your MAC)
Dest IP: 192.168.1.100 (your IP)

Message: ARP Reply

Step 5: Cache and Use

  • Your computer receives reply
  • Stores mapping in ARP cache: 192.168.1.50 = bb:cc:dd:ee:ff:02
  • Uses MAC to send data on local network

ARP Cache

View ARP Cache:

# Linux/Mac
arp -a
 
# Output:
# device (192.168.1.1) at aa:bb:cc:dd:ee:01 on en0
# server (192.168.1.50) at bb:cc:dd:ee:ff:02 on en0
# Windows
arp -a
 
# Output:
# Internet Address      Physical Address      Type
# 192.168.1.1          aa-bb-cc-dd-ee-01     dynamic
# 192.168.1.50         bb-cc-dd-ee-ff-02     dynamic

Clear ARP Cache (Linux):

sudo arp -d 192.168.1.50
# or clear all
sudo ip neigh flush all

ARP Packet Structure

Hardware Type:     1 (Ethernet)
Protocol Type:     0x0800 (IPv4)
Hardware Length:   6 (MAC address = 48 bits)
Protocol Length:   4 (IP address = 32 bits)
Operation:         1 (Request) or 2 (Reply)
Sender MAC:        aa:bb:cc:dd:ee:01
Sender IP:         192.168.1.100
Target MAC:        00:00:00:00:00:00 (unknown in request)
Target IP:         192.168.1.50

ARP Limitations and Scope

ARP Only Works Locally

  • ARP uses broadcast
  • Routers don't forward broadcast packets
  • Only devices on same network segment respond

Example:

LAN: 192.168.1.0/24
- Device A (192.168.1.100)
- Device B (192.168.1.50)

ARP works between A and B.

Device C on different LAN: 10.0.0.50
Can't reach C with ARP from LAN 192.168.1.0/24
Must use IP routing instead.

ARP for Remote Networks

How does traffic reach a remote network?

Device A: "I want to reach 10.0.0.50"
Check routing table: "10.0.0.0/8 goes via router 192.168.1.1"
ARP for router: "Who has 192.168.1.1?"
Get router's MAC: aa:bb:cc:dd:ee:01
Send packet to router's MAC (but IP still says 10.0.0.50)
Router forwards to next hop

ARP Security Issues

1. ARP Spoofing Attacker sends fake ARP replies:

Attacker: "192.168.1.1 is at aa:bb:cc:dd:ee:AA"
(But attacker's MAC is really aa:bb:cc:dd:ee:99)

Device gets tricked, sends traffic to attacker instead of router
→ Man-in-the-middle attack!

2. ARP Flooding Attacker sends thousands of ARP requests:

  • Consumes network bandwidth
  • Exhausts device resources
  • Can cause network outage

3. Gratuitous ARP Device sends ARP reply without being asked:

"FYI, I'm 192.168.1.100 at aa:bb:cc:dd:ee:01"

Legitimate use: Notify others of IP address change Malicious use: Inject false address mappings into ARP caches

ARP Security Defenses

Static ARP Entries Manually configure ARP mappings instead of using ARP:

# Linux
arp -s 192.168.1.1 aa:bb:cc:dd:ee:01
 
# Windows
arp -s 192.168.1.1 aa-bb-cc-dd-ee-01

DHCP Snooping

  • Switch monitors DHCP traffic
  • Validates legitimate IP/MAC mappings
  • Blocks fake DHCP responses

Dynamic ARP Inspection (DAI)

  • Validates ARP requests/replies against DHCP database
  • Prevents ARP spoofing at switch level

IPsec

  • Encrypts all traffic
  • Prevents man-in-the-middle attacks
  • More overhead than ARP security alone

ARP Monitoring

# Watch for ARP activity
tcpdump -i eth0 arp
 
# Example output:
# 14:32:15.123456 arp who-has 192.168.1.50 tell 192.168.1.100
# 14:32:15.123789 arp reply 192.168.1.50 is-at bb:cc:dd:ee:ff:02

ARP in Container/Kubernetes Networks

In containerized environments, ARP operates normally but:

Considerations:

  • Each container has its own MAC address
  • Virtual switches handle ARP just like physical switches
  • Overlay networks may encapsulate ARP
  • Service discovery takes precedence over ARP in many cases

Example: Kubernetes Service

Service IP: 10.0.0.50 (virtual, no MAC)
→ Kube-proxy handles mapping to actual pod IPs
→ Traditional ARP not used for service discovery

Practical ARP Scenarios

Scenario 1: New Device on Network

New server boots up
1. Sends ARP request: "Who can route my packets?"
2. Router replies with its MAC
3. Server sends data to router's MAC
4. Router forwards to internet

Scenario 2: Duplicate IP Address

Device A: 192.168.1.100 at aa:bb:cc:dd:ee:01
Device B: 192.168.1.100 at aa:bb:cc:dd:ee:02 (misconfigured)

→ Network chaos! Devices send ARP requests/replies, invalidating caches

Scenario 3: Virtual IP for High Availability

Router A: 192.168.1.1 at aa:bb:cc:dd:00:01
Router B: 192.168.1.1 at aa:bb:cc:dd:00:02 (standby)

If Router A fails → Router B sends gratuitous ARP
Devices update ARP cache to point to Router B
Traffic redirected to Router B automatically

ARP Troubleshooting

Issue: Device can't reach gateway

# Check if gateway is in ARP cache
arp -a | grep [gateway-ip]
 
# If missing, can't communicate
# Solution: Check network cable, ensure gateway is online
 
# Force ARP resolution
ping [gateway-ip]
# Generates ARP request, populates cache

Issue: Slow network startup

# Might be excessive ARP traffic during boot
tcpdump -i eth0 arp | head -20
 
# If many gratuitous ARP packets → investigate
# Might be flapping IP addresses

Key Concepts

  • ARP maps IP addresses → MAC addresses on local network
  • ARP Request broadcast "Who has this IP?"
  • ARP Reply unicast "I'm at this MAC"
  • ARP Cache stores recent mappings (expires in minutes)
  • ARP Spoofing is a security risk → use DAI, static entries, or IPsec
  • ARP Scope limited to local network segment
  • Device MUST ARP before sending first packet on local network
  • Broadcast MAC ff:ff:ff:ff:ff:ff reaches everyone