Кто-нибудь знает, от чего зависит количество попыток arp на роутере? У меня разное поведение с двумя устройствами, если я попытаюсь выполнить трассировку до несуществующего хоста в подсети, которая принадлежит интерфейсу на маршрутизаторе, ящик Linux попытается выполнить arp 3 раза, а затем вернет сообщение icmp о недоступности хоста . Junos будет непрерывно пытаться воспроизвести арп и ничего не вернуть. Есть ли значение sysctl, которое определяет это или что-то вообще.
В linux вас интересуют:
% sysctl net.ipv4.neigh.eth0.mcast_solicit
net.ipv4.neigh.eth0.mcast_solicit = 3
Ядро linux вернет узел icmp, недоступный исходному процессу отправки, если он не сможет разрешить ARP после mcast_solicit пытается.
В BSD (включая Junos) вы можете установить это так:
% sysctl net.link.ether.inet.maxtries
net.link.ether.inet.maxtries: 4
Это устанавливает количество повторных попыток, поэтому установите его на 0 если вам нужен только один ARP. В отличие от linux, BSD не отбрасывает сообщения о недоступности ICMP; время ожидания чего-то другого (таймаут TCP SYN_SENT или что-то еще).
Если вы выполняли traceroute на несуществующий локальный адрес в Linux, вы должны были увидеть 3 ARP, за которыми следует traceroute, выходящий с !H !H !H. (Вы получаете все три !Hs потому что net.ipv4.neigh.eth0.unres_qlen по умолчанию установлено значение 3, поэтому ARP будет удерживать до 3 пакетов в своей очереди, пока пытается разрешиться. Если вы установите net.ipv4.neigh.eth0.unres_qlen к 2, трассировка на несуществующий локальный адрес даст вам !H !H *
Если вы выполняли трассировку для несуществующего локального адреса в Junos (BSD), вы должны увидеть 5 ARP с последующей печатью трассировки. *, то traceroute попытается снова, вы увидите еще 5 ARP, еще один * и так далее с продолжением traceroute до тех пор, пока он в конечном итоге не откажется от 3 зондов для 30 переходов, 5 раз ARP на зонд (всего 450 ARP, я полагаю).