ARP monitoring bond: выбранный target определяет, какой отказ будет замечен
Фотография конкретного исполнения не приложена.
Проверка соседнего адреса позволяет наблюдать больше, чем физический carrier, но только в границах выбранного target. Ответ ближайшего шлюза не доказывает доступность сервиса за ним. Для резервирования нужно явно определить, какой сетевой участок считается пригодным.
Документация bonding описывает arp_interval, список targets и arp_validate. Политика arp_all_targets для предусмотренного active-backup с validation различает достаточность любого ответа и необходимость всех targets. Не следует переносить её действие на все режимы без проверки области параметра.
Важен и путь обратных ответов: распределение коммутатора может привести их к одному члену, делая оценку другого неверной. Обычный посторонний трафик также не должен случайно подменять нужное подтверждение. Источник отдельно предостерегает от совместного использования ARP monitoring и miimon как будто это два независимых складываемых контроля.
В приёмке проверяют потерю одного target, всего набора и отказ только backup-направления. Сопоставляют validation с состоянием каждого члена. Критерий доступности должен соответствовать топологии и классу отказа. Успешный ARP-ответ подтверждает выбранную сетевую границу, а работоспособность приложения требует отдельной проверки.
Основание — Official versioned Linux network documentation displaying6.18.0, networking/bonding, scaling and bridge, разделы arp_interval; arp_ip_target; arp_validate; arp_all_targets. Сохранён текст публичной справочной публикации; конкретная реализация может поддерживать только часть возможностей. Основание — официальная версия документации Linux с заголовком 6.18.0. Это фиксированная редакция, а не утверждение об установленном или последнем ядре. Реальные NIC, драйвер, switch и параметры хоста не проверялись; настройки и сетевые испытания не выполнялись.
Запросы отправляются на наш e-mail из вашей почтовой программы.
