Запросы ARP с нечетным исходным IP остаются без ответа
nginx имеет плагин, который принимает Perl в файлах конфигурации. Вы могли использовать это для запросов дб.
Сегодня произошло интересное изменение ситуации.
В конце концов, все свелось к двум вещам:
Маршрутизатор Juniper, или фактически кластерная система межсетевого экрана, каким-то образом потеряла синхронизацию конфигурации между стороны кластера. В результате не все части кластера FW имели актуальную конфигурацию, и это приводило к неправильным запросам arp (да, неправильные запросы arp действительно исходили от маршрутизатора / брандмауэра).
Управляющее приложение поскольку брандмауэр также вел себя неправильно, пытаясь протолкнуть некоторую, отличную от текущей, правильную конфигурацию, по крайней мере, в часть кластера брандмауэра.
У меня нет подробностей о том, что было сделано для самого брандмауэра, ни для управления приложение, но конечный результат таков, что теперь адресом "tell" в запросах arp является IP-адрес маршрутизатора (.
Я наткнулся на точно такая же проблема. Оказалось, что кто-то установил в качестве значения manage-ip адрес подсети:
Cluster: name (M) -> get config | inc совокупный 10.200
установить агрегат интерфейса 10.200 ip x.x.x.x.225 / 28
...
установить агрегат интерфейса 10.200 manage-ip x.x.x.224
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^
Чтобы исправить:
unset interface aggregate 10.200 manage-ip.
В нашем случае это была неправильная конфигурация.