ARP Handling


The FireBrick maintains an ARP cache for each interface, recording the mapping of IP addresses to MAC addresses. The cache is independent for each interface, and within each cache an IP address will only have one MAC address.

The ARP cache is used to allow routing to IP addresses for routed traffic and traffic generated by the FireBrick itself.

Generating ARP requests

The FireBrick will generate an ARP request if it needs to know the MAC address for an IP address. This is only necessary for routed traffic.

The request is NOT generated if the FireBrick cannot complete the source IP/MAC information. To complete the source information the FireBrick checks :-

  1. If it has a subnet on the appropriate interface appropriate to the requested IP, then it will use its IP on that subnet and its MAC address
  2. If not, but the FireBrick has a stealth IP address for that interface, and has noted a MAC for that IP, then it will use that IP and MAC
  3. If not, but the FireBrick has a stealth IP address for that interface, then it will use that IP and its own MAC
  4. If not, then the ARP is not sent
Note, subnets are searched in order for the first match.

While waiting for a reply, a limited number of packets requiring the MAC address are queued. On timeout these packets are discarded and a "no route to host" ICMP generated. On reply, these packets are sent with the MAC address completed.

An ARP request is sent on the first packet requiring a MAC address, and repeated every few seconds for several tries.

Processing ARP replies

Any ARP reply causes the sender IP/MAC to be stored. This may complete a pending ARP request and cause pending packets to be sent.
  1. ARP replies that are targeted at a MAC known to be on the same interface are discarded as local traffic.
  2. ARP replies that are effectively ARP announcements (to self and target broadcast MAC) are simply logged (debug level)
  3. Otherwise, ARP replies that match a previous passed through ARP request are passed back through to the originator
  4. Otehrwise the ARP reply is simply logged (debug level) as unexpected

Processing ARP requests

Any ARP request causes the sender IP/MAC to be stored. This may complete a pending ARP request and cause pending packets to be sent.

ARP requests received are checked as follows. The result may be to discard, or to reply or to pass through.

  1. If the request is for the FireBrick's stealth IP on the LAN and is from the LAN, then a reply is sent
  2. If the request is for the FireBrick's IP address on a subnet on the sending interface then a reply is sent
  3. Routes are checked for a route where the soure interfaces matches the source of the ARP request, and the source IPs (if any) cover the sender IP of the ARP and the target IPs cover the requested address of the ARP and proxy ARP is set, then a reply is sent
  4. If the request is from and for an address in a subnet on the interface from which it came which is marked stealth, then it may be passed through.
  5. If not, then if it is for an address in a subnet on the interface from which it came which is not marked stealth, then it is dropped
  6. If the packet would be passed through, and matches one of the FireBricks own address on the far side interface, then a reply is sent
  7. If not replied or dropped, then the ARP is passed through (subject to global stealth settings) and a session created for the reply to be checked.
The reply quotes the FireBrick's MAC for the interface on which the ARP was received, even if it is for a far IP side address.
ARP requests that are passed through are stored in a session table (discarding the oldest session if the table is full).

ARP session tracking

ARP requests that are passed through are session tracked. A limited number of oustanding ARP requests are tracked, with the entry with the shortest remaining timeout being discarded if there are more than this number received. When an ARP reply is received that matches the request then it is passed back to the originator.

The ARP session is only held open for a limited time, and normally ARP replies are received within milliseconds of the request being sent. However, it is possible for a host to send several requests in rapid sequence without waiting for replies. This can then lead to several replies (i.e. request request reply reply, rather than request reply request reply). As such, when an ARP reply is matched, the session remains in place for a short period of time to pick up further replies and pass these though.

ARP status

The diagnostic display page on the FireBrick will show the current state of the ARP cache, with an indication of the status of each entry as follows :-
 
ARP status
Yellow Cache OK, but being retried
Green Cache OK, and recently used
Blue Cache OK, not recently used
Red Cache not OK, waiting for initial reply

The used status of the cache is set whenever the FireBrick uses the ARP entry to send a packet. This is cleared periodically, and the cache refreshed. As such, entries being regularly used will appear as Green or Blue. If a cache entries is not used, then it will be discarded. Yellow or Red will only show very briefly, or if there is no reply from an ARP request. Red entries do not show a MAC, just zeros.