На этой неделе у меня было две ситуации, когда моему провайдеру восходящего канала пришлось отключить нашу ссылку, потому что их маршрутизатор обнаружил широковещательный шторм. К сожалению, они не могут предоставить дополнительную информацию об источнике проблемы.
Как лучше всего определить причину этой проблемы?
У меня есть маршрутизатор Vyatta между провайдером восходящего канала и моей сетью. Является ли запуск "tcpdump broadcast" и регистрация его жизнеспособным решением?
Таким образом, возможно, я смогу хотя бы вести журнал и идентифицировать IP-адреса с большим широковещательным трафиком, если эта проблема повторится.
Существует более одного типа трансляции.
Широковещательные сообщения уровня 2 (сетевой) (трафик на MAC-адрес all-1) используются протоколами, такими как ARP, для сбора информации о том, как подключиться к определенному узлу, когда он уже знает его адрес более высокого уровня (обычно IP).
Широковещательные рассылки уровня 3 (IP) (трафик на самый высокий адрес подсети) выполняют совершенно другие функции.
Если на вашего сетевого провайдера влияет широковещательный трафик уровня 2, я серьезно недоумеваю, насколько он компетентен.
Ваш сетевой провайдер обычно подключается через маршрутизатор IP (уровня 3), который вообще не пропускает трафик уровня 2.
Единственное, что следует отметить широковещательную рассылку уровня 3, - это типичные запросы службы имен Windows (WINS и т.п.)
Такое поведение может указывать на проблему с оборудованием на маршрутизаторе или в любой другой точке между конечными узлами (вашим компьютером и поставщиком сети).
Я не знаком с Vyatta, но возможно, что происходит какой-то беспричинный arp (обычно при аварийном переключении), вызывающий проблему. Это довольно распространенный механизм для принудительного обновления кэша arp во время отработки отказа, но он может вызвать такие проблемы, как эта, в зависимости от того, насколько агрессивны широковещательные рассылки и насколько чувствительны получатели.
Стоит посмотреть в любом случае.
Спасибо всем, кто ответил!
После дальнейшего исследования выяснилось, что предел кэша arp был установлен на очень низкое значение, и он не удерживал все хосты в нашей сети.
После установки большего значения проблема была решена.