[j-nsp] ARP resolution algorithm? Storage of MX transit packets?

[Saku Ytti]

On Fri, 1 Feb 2019 at 01:32, Clarke Morledge <chmorl at wm.edu> wrote:

> Specifically, what would be nice, is if there was a way to manipulate that
> ARP retry mechanism, from 4 retries, down to 2, to cut down on the noise.
> So far, I have not found a knob in Junos on the MX to do this.

> Am I missing something?

I don't think you are. You have not described the practical problem
you are facing, which may help people with proposing a solution. What
practical consequences you have with the unnecessary ARP traffic?

Some options to consider.

1. arp-new-hold-limit (Max no. of new unresolved nexthops)
   May be interesting to explore setting this to a very low number.

2. arp sponge or static arp entries for non-existing host
   If you have mechanism to know which addresses are currently not in use

I tried to check for hidden commands to change the actual ARP
resolution retry count, but found nothing:

I, [2019-02-01T07:23:24.407919 #16301]  INFO -- : Found: 'arp-cpu-threshold'
I, [2019-02-01T07:23:27.424754 #16301]  INFO -- : Found:
'arp-reply-bump-priority'
I, [2019-02-01T07:23:30.600803 #16301]  INFO -- : Found:
'arp-request-bump-priority'
I, [2019-02-01T07:23:46.780875 #16301]  INFO -- : Found:
'no-proxy-arp-overwrite'
I, [2019-02-01T07:23:53.618055 #16301]  INFO -- : Found:
'proxy-arp-reply-for-default'

Last three ones seem like interesting options to explore as well:

% sysctl -a | grep inet.arp_cache
net.link.ether.inet.arp_cache_size: 12
net.link.ether.inet.arp_cache_perm_size: 0
net.link.ether.inet.arp_cache_size_threshold: 0
net.link.ether.inet.arp_cache_timeout_size: 11
net.link.ether.inet.arp_cache_rearp_size: 0
net.link.ether.inet.arp_cache_retry_size: 1


If you are running subscriber services and DHCP is guaranteed, you
should be able to just disable ARP, as you can populate ARP cache from
DHCP in subscriber environment.

-- 
  ++ytti