On Fri, 1 Feb 2019 at 01:32, Clarke Morledge <chm...@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 _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
