Arp tries on various *nix based systems

Question

Does anyone know what determines the amount of arp tries a router will make? I have different behaviors with two devices, if I try to traceroute to a non-existent host on a subnet that belongs to an interface on the router, a Linux box will try to arp 3 times and then return a host un-reacheable icmp message. Junos will continuosly try to arp and not return anything. Is there a sysctl value that determines this or anything at all.

Answer 1

On linux, you're interested in:

% sysctl net.ipv4.neigh.eth0.mcast_solicit
net.ipv4.neigh.eth0.mcast_solicit = 3

The linux kernel will return an icmp host unreachable to the original sending process if it's unable to resolve an ARP after the mcast_solicit tries.

In BSD (including Junos), you can set it thusly:

% sysctl net.link.ether.inet.maxtries
net.link.ether.inet.maxtries: 4

This sets the number of retries, so set it to 0 if you just want one ARP. Unlike linux, BSD doesn't kick back an ICMP unreachable; it's up to something else to time out (TCP SYN_SENT timeout or whatever).

If you were doing traceroutes to a non-existent local address on Linux, you should have seen 3 ARPs followed by traceroute exiting with !H !H !H. (You get all three !Hs because net.ipv4.neigh.eth0.unres_qlen is set to 3 by default, so ARP will hold up to 3 packets in its queue while it's trying to resolve. If you set net.ipv4.neigh.eth0.unres_qlen to 2, a traceroute to a non-existent local address would give you !H !H *

If you were doing traceroutes to a non-existent local address on Junos (BSD), you should see 5 ARPs followed by traceroute printing *, then traceroute will try again, you'll see another 5 ARPs, another * and so forth with traceroute continuing until it eventually gives up after 3 probes for 30 hops, ARPing 5 times per probe (a total of 450 ARPs I suppose).