ARP. One host wants to know the MAC of another host for which it only has the IP. So it sends out a broadcast ARP request packet. The machine with the target IP sends back a unicast ARP reply packet to let the first host know what its MAC is. ARP requests are broadcast, ARP replies are unicast.
Actually, an ARP request doesn’t have to be broadcast but pretty much every learning resource you encounter talks about ARP traffic as though the only packets you’ll ever see are those from a host searching for an unknown MAC as described in the original protocol spec in RFC 826.
This often sets up an assumption in people’s minds – I know it did in mine – which leads to confusion when you see a unicast ARP request. I checked the first few pages of google hits for arp tutorial and found no mention of unicast requests, or indeed broadcast replies, in any of them.
The original intent for the protocol was as a mechanism for discovery using broadcast requests, but additional functionality has been added to ARP over the years – things like efficiency improvements, and increased network reliability and stability. The core ARP functionality remains as it was but now there’s just more.
In reality the vast majority of ARP traffic you see on networks is hosts checking their caches are up to date (see section 2.3.2.1 of RFC 1122 which talks about refreshing the ARP cache for known hosts using a unicast poll) and there’s no need for these conversations to be broadcast. You’re unlikely to see broadcast ARP request traffic unless something ‘interesting’ happens on the network, someone swaps out a NIC for example, or unless you deliberately take steps to trigger it, by deleting an ARP cache entry for a host and then pinging the host you just deleted for example.
There are other instances where you’ll see unicast ARP requests as well. For example the utility arping will send out a unicast request to a specified host.
Lessons?
It’s a good idea to get a baseline for expected network traffic because you should not be surprised by your network’s normal operation. If you are, you won’t have the confidence to consider something to be sketchy when you should.
As Chris Greer says:
[…] we could just be looking at perfectly normal performance. Which, by the way, is nice to have. When we’re looking for broken it’s also nice to have a trace of things that do work. 07:44
What you should expect is not always what you think you should expect. Be able to recognise surprising inputs and be prepared to consider them as valuable learning points rather than discountable anomalies.
Serendipitously, RFC 826 opens with the statement,
The world is a jungle in general, and the networking game contributes many animals.
Sometimes there’s a raptor staring right into your face, focusing your mind to such an extent that you don’t even see the clever girl off to the left, ready to eat your face off. Everyone’s so busy waving 826 at you that the possibility of 2.3.2.1 lurking in 1122 never even registers.