Does FreeBSD do proactive ARP refresh?

[sthaug at nethelp.no]

> > > > I have a reproducible problem on 11.1-STABLE where, during a longterm
> > > > iperf3 session, some packets are lost every time ARP is refreshed (every
> > > > net.link.ether.inet.max_age seconds). Checking with tcpdump, I can
> > > > indeed see that the packet loss is happening as the hosts are doing
> > > > ARP request/reply.
> > > I'll take a look. Indeed, the intended behaviour is to proactively refresh the record.
> > > Is the situation the same with forwarding and locally-originated traffic?
> > > With local TCP socket inpcb route caching might come into play. 
> > 
> > My testing is with locally-originated UDP traffic (iperf3 -u). Haven't
> > tested what happens if the box is forwarding the traffic - however, I
> > believe TCP socket inpcb route caching should not be relevant for the
> > UDP traffic? (But there is also a TCP transaction between the iperf3
> > sender and the iperf3 receiver at the *start* of the iperf3 session.)
> > 
> > In any case, I will also test what happens if the box is forwarding
> > the traffic.
> 
> And thank you for that suggestion! The packet loss during ARP refresh
> (of the destination address connected to the output interface) does
> *not* happen when the box is forwarding! It only happens with locally
> generated traffic.

Checking once per second with "arp -n <destination IP>" I can see the
following behavior with net.link.ether.inet.max_age=120:

- Locally generated traffic: The ARP entry is refreshed after
net.link.ether.inet.max_age seconds - which presumably means it
actually expires first. And there is some packet loss.

- Transit traffic (the box is forwarding): The ARP entry is refreshed
5 seconds *before* net.link.ether.inet.max_age has passed, and there
is no packet loss.

Steinar Haug, Nethelp consulting, sthaug at nethelp.no