That's a great question! After an ARP entry becomes stale, the system doesn't just delete it immediately. Instead, it uses a "probing" mechanism to refresh the entry and ensure the destination is still there.
Here is how the ARP Probe process works:
1. The Trigger
When an entry is in the STALE state, it means the timer has expired, but the system hasn't deleted the mapping yet. As soon as you try to send a new packet to that IP address (like performing a ping), the kernel realizes the entry is stale and triggers a probe.
2. Unicast Probing (The Quiet Check)
Before broadcasting to the whole network, Linux tries to be efficient:
- The system sends a Unicast ARP Request directly to the MAC address currently stored in the cache.
- It essentially asks: "Hey, [MAC Address], are you still the owner of this IP?"
- If the device replies, the entry is immediately marked as REACHABLE again, and the timer resets.
3. Broadcast Probing (The Final Attempt)
If the unicast probes fail (usually after a few attempts), the system assumes the device might have changed its MAC address or moved. It then:
- Deletes the old entry.
- Sends a standard Broadcast ARP Request (asking everyone on the local network: "Who has this IP?").
- If a reply comes back, a brand new entry is created.
4. Transition to "Incomplete"
If no response is received even after broadcast attempts, the entry is marked as incomplete and eventually removed from the table entirely.
How to see this in action?
In your current LabEx environment, you can view more detailed states (like STALE, DELAY, or REACHABLE) by using the ip neigh command instead of arp -a:
ip neigh showThis command provides a more modern and detailed look at how the Linux kernel is managing these "neighbors"!
