Internet Core Protocols: The Definitive Guide

Bursted Duplicate ARP Requests

Whenever a system tries to send data to a local destination system that does not have an entry in the sender’s ARP table, the ARP module on the sender will try to locate the device’s hardware address using an ARP query. If the sender tries to send a lot of packets to that destination system in a burst, then the ARP module may end up issuing several queries in a burst as well.

Although RFC 1122 recommends that ARP not issue duplicate lookups at a rate faster than once per second, some systems ignore this recommendation and cause each of the generated IP packets to also trigger an immediate ARP request. Some systems will wait for at least one second before issuing a subsequent ARP lookup, although those systems still may lose data as the higher-layer protocol continues to submit data faster than this.

Most ARP agents can only keep track of one lookup to any given host at a time. As such, if they receive an IP packet for a device while an ARP lookup for that device is already in progress, then the first packet in the ARP queue will get destroyed, and another lookup may get generated for the second packet. If the end-point applications are not using TCP or some other reliable protocol, then the packet will be lost forever. This situation is particularly problematic with ICMP- and UDP-based applications that generate many IP packets in a single operation. For more information on those scenarios, refer to Section 5.4.4 in Chapter 5, and Section 6.3.5 in