What Is ARP? Address Resolution Protocol Explained

The MAC address hiding behind an IP address

When an SSH connection fails, I do not start by restarting SSH. I first ask a smaller question: can this machine reach the next hop on the local network? For IPv4, that question often leads to ARP, the protocol that connects a known IP address to the MAC address needed to deliver an Ethernet frame.

ARP, or Address Resolution Protocol, maps an IPv4 address to a MAC address on the local network. Before sending an IP packet to a nearby destination, a device broadcasts an ARP request. The device using that IPv4 address replies, and the sender temporarily stores the mapping in its neighbor cache.

When you connect to a VPS over SSH, you usually think about its IP address. An Ethernet interface also needs the link-layer address of the next device on the local network. IP identifies the destination logically; Ethernet delivers the frame to a MAC address.

“Physical address” is slightly old-fashioned wording here. A MAC address is associated with a network interface, but virtual machines, Linux bridges, and container networks can assign one in software. The job remains the same: move an IPv4 packet across a local Ethernet network.

How ARP finds a local neighbor

ARP works only on the same local network segment. When you connect to a web server on another network, your machine does not look for that server’s MAC address. It resolves the MAC address of the default gateway and hands the IP packet to that device. The router creates a new frame for the next network.

The exchange described in RFC 826 is straightforward:

1. The sender checks its ARP cache for the target IPv4 address.
2. If there is no matching entry, it sends an ARP Request to the Ethernet broadcast address, ff:ff:ff:ff:ff:ff.
3. Every device on the local network receives the request. The device configured with that IP address responds with an ARP Reply containing its MAC address.
4. The sender caches the mapping and sends the waiting IP packet to that MAC address.

The target MAC field inside an ARP Request is not known yet, so it is normally set to zeroes. The surrounding Ethernet frame uses the broadcast address. An ARP Reply usually goes directly to the sender’s MAC address.

What an ARP request contains

An ARP message carries more than a simple “who has this IP?” question. It includes the hardware type, protocol type, address lengths, operation type, and address pairs for the sender and target. On an ordinary IPv4-over-Ethernet network, the useful fields look like this:

Keep the boundary clear: ARP is not DNS. DNS resolves a domain name to an IP address; ARP finds the local MAC address associated with an IPv4 address you already know. Mixing up those jobs makes troubleshooting harder than it needs to be.

Reading the ARP table on Linux

On Linux, I use ip neigh to inspect neighbor entries. Older systems may still have arp -n or arp -a, but the iproute2 tools present IPv4 ARP entries and IPv6 neighbor-discovery records more consistently.

ip neigh show

A sample output might look like this:

192.168.1.1 dev eth0 lladdr 9c:5c:8e:12:34:56 REACHABLE
192.168.1.42 dev eth0 lladdr 08:00:27:ab:cd:ef STALE
192.168.1.77 dev eth0 INCOMPLETE

dev eth0 identifies the interface holding the entry. lladdr, short for link-layer address, shows the MAC address. REACHABLE means the entry was verified recently. STALE means it may need verification, but Linux has not declared it invalid. INCOMPLETE means address resolution has not finished or no reply has arrived.

These states belong to Linux’s neighbor-cache state machine. An entry does not stay in one state forever. The kernel tracks whether the connection is being used and whether the mapping needs to be checked again.

How long does an ARP entry last?

There is no universal rule that ARP entries disappear every 60 seconds. Timing depends on the operating system, kernel, distribution, and network settings. On Linux, neighbor behavior is related to settings below /proc/sys/net/ipv4/neigh/. To inspect the interface-related values, run:

sysctl -a 2>/dev/null | grep 'net.ipv4.neigh.*base_reachable_time'

The filter keeps the large sysctl listing manageable. That small detail matters when I am checking a production host at three in the morning.

When changing these values, measure the network behavior of your distribution and application instead of copying a random number from a forum. Very short intervals create unnecessary ARP traffic. Very long intervals can delay detection of an IP-to-MAC change.

Inspecting and clearing neighbor entries

My first check is usually which interface and MAC address will be used for the target. To see the route toward a public address, for example:

ip route get 8.8.8.8

On many Linux servers, the output resembles:

8.8.8.8 via 192.168.1.1 dev eth0 src 192.168.1.20 uid 0

This tells you that the server will not ARP for 8.8.8.8 directly. The next hop is 192.168.1.1, so that is the address whose MAC will be resolved. I then inspect that entry:

ip neigh show 192.168.1.1 dev eth0

If necessary, you can remove one entry and let Linux learn it again:

sudo ip neigh del 192.168.1.1 dev eth0

The dev eth0 part matters; the same IP can exist on different interfaces. Deleting an entry does not repair a physical fault. If the switch port is disabled, the VLAN is wrong, or the other device is silent, the new ARP request will be silent too.

To flush neighbor entries on one interface:

sudo ip neigh flush dev eth0

I do not run that as my first reflex on a production server. I check ip route, ip addr, the switch or virtualization layer, and relevant kernel logs first. The command is short. Its effect can be wider than expected.

A practical ARP troubleshooting order

A failed ping does not prove an ARP failure. ICMP may be blocked, the service may be stopped, or the destination may be on another network. I separate the layers instead of restarting a service and hoping the network feels better afterward.

1. Check the local address and route

ip addr show dev eth0
ip route show

First, check that the server actually has the expected IPv4 address. Then verify that the target uses the intended interface and gateway. A wrong netmask, an unexpected local route, or a missing default route often looks like an ARP problem at first.

2. Inspect the neighbor state

ip neigh show dev eth0

An entry that is FAILED or remains INCOMPLETE for a long time suggests that no ARP reply arrived. If other devices on the same network resolve correctly but one target does not, inspect that target’s interface, IP configuration, and network policy.

3. Watch the packets

sudo tcpdump -ni eth0 arp

-n disables DNS lookups, while -i eth0 selects the interface. In a working exchange, you should see an ARP Request containing who-has, followed by a Reply containing is-at. If the request leaves but no reply returns, investigate the path or the target. If the reply arrives but application traffic still fails, the problem has moved beyond ARP.

You can also watch ARP and ICMP together:

sudo tcpdump -ni any 'arp or icmp'

Here, any is a virtual capture option that combines traffic from multiple interfaces. On a busy server, the output grows quickly. I use it for a short observation window.

4. Check VLANs, bridges, and virtual networks

In VPS infrastructure, ARP does not depend only on a physical cable. Linux bridges, VLANs, hypervisors, and virtual switches determine how the local network is assembled. If your VPS cannot reach another address in the same subnet, inspect the hosting panel’s network configuration, the virtual NIC state, and any anti-spoofing rules enforced by the provider.

During a night shift, a customer moved a failover IP to a new server, but some connections continued reaching the old machine. The application logs looked healthy. The MAC address in ip neigh, however, still pointed to the old node. Before deleting the entry, I checked the switch MAC table and the virtual IP announcement. The new node was not sending a gratuitous ARP on the correct interface. Once that announcement was fixed, clients began learning the new MAC address. Since then, I treat deleting an ARP entry as an observation step, not a repair.

Problems I see around ARP

Stale or incorrect entries

When an IP address moves to another interface, or a virtual IP changes nodes in a high-availability setup, an old MAC mapping can cause trouble for a short time. New ARP announcements and normal revalidation usually update the entry. Where failover must be fast, gratuitous ARP can speed up the change, although network security policies may restrict it.

A common symptom is that some clients on the same subnet reach the new node while others still reach the old one. Clearing the entry on one client can help with diagnosis. A lasting fix requires checking the failover mechanism, the ARP announcement, switch behavior, and virtual IP design together.

Too many ARP broadcasts

Because ARP uses broadcast on IPv4 Ethernet networks, every device on the local segment receives the request. Normal traffic is manageable, but unnecessarily large broadcast domains can make these requests noisy. Segmenting subnets correctly, finding the misbehaving device, and capturing packets to identify the source are better approaches than randomly changing cache timers.

ARP spoofing and poisoning

ARP does not strongly authenticate replies on the local network. A malicious device can claim the gateway’s IP address and advertise its own MAC address, attempting to pull traffic through itself. This is called ARP spoofing or ARP poisoning, and it affects traffic within the same local segment.

Useful controls depend on the environment:

• If the managed switch supports DHCP snooping and Dynamic ARP Inspection, configure them carefully and verify their trusted ports.
• A static neighbor entry for a trusted gateway can work in a small, controlled network, but it creates maintenance work in larger environments.
• Keep administrative access on trusted networks or use encrypted tunnels such as WireGuard.
• When a mapping changes unexpectedly, compare ip neigh, the switch MAC table, and a packet capture.

Changing the SSH port does not solve this attack. It may quiet one category of log noise, but the real question is where the network’s trust boundaries and management paths are.

ARP and IPv6 neighbor discovery are different

ARP is used for IPv4. IPv6 uses Neighbor Discovery Protocol, or NDP, for equivalent address-resolution work, and NDP is built on ICMPv6. NDP also covers router discovery, address autoconfiguration, and duplicate address detection, as RFC 4861 describes.

On an IPv6 server, looking only at the IPv4 output of ip neigh leaves out an important part of the diagnosis. To inspect IPv6 neighbors:

ip -6 neigh show dev eth0

That is why an IPv6 connectivity problem cannot be explained by ARP. Check NDP, ICMPv6 filtering, and router advertisements instead.

Keep the troubleshooting order simple

• ARP resolves IPv4 neighbors; it is not a replacement for DNS or a routing protocol.
• For remote destinations, the resolved MAC address usually belongs to the default gateway, not the destination server.
• A STALE entry is not automatically a fault; Linux can verify it again when needed.
• INCOMPLETE and FAILED suggest that no ARP reply arrived, so physical, virtual, and security layers should all be checked.
• Flushing the ARP table is a diagnostic action, not a general repair method.
• VLAN, bridge, and hypervisor configuration directly affects whether ARP can reach its destination.
• For IPv6 problems, inspect NDP commands and ICMPv6 traffic instead of looking for ARP.

If you want the wider picture first, What Is an IP Address and How Does It Work? explains the logical address involved here. For ARP’s place in the protocol stack, Demystifying Internet Protocols: From TCP/IP to HTTP/3 is the more useful next read.

When I troubleshoot a network fault, I check whether the target is on the same subnet, then the gateway MAC address, and only afterward the application. I learned that order after spending too long staring at service logs for a problem that had never reached the server.

Frequently asked questions

What is ARP in simple terms?

ARP finds the MAC address associated with an IPv4 address on the local network. Devices temporarily cache that mapping and use it to put IP packets into Ethernet frames for the correct neighbor.

How do you view the ARP table?

On Linux, ip neigh show displays IPv4 neighbor entries. To inspect one interface, use ip neigh show dev eth0.

Does clearing the ARP table fix connectivity problems?

Sometimes it forces an old or incorrect MAC mapping to be learned again, which can help with diagnosis. It does not permanently fix a VLAN, bridge, switch, or remote-device problem.

Is ARP used with IPv6?

No. IPv6 uses Neighbor Discovery Protocol for neighbor resolution and related discovery tasks. On Linux, view IPv6 neighbors with ip -6 neigh show.

Sources

• RFC 826 – An Ethernet Address Resolution Protocol — rfc-editor.org
• RFC 4861 – Neighbor Discovery for IPv6 — rfc-editor.org
• Linux kernel documentation – IP sysctl — kernel.org