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