Сеть переполнена кажущимися пустыми пакетами
Позвольте мне предварить это тем фактом, что я всего лишь веб-разработчик в своей компании с небольшими знаниями в области сетевых технологий.
Ранее сегодня был отдел, который потерял все свои сетевые соединения, поэтому я открыл Wireshark и наблюдал за притоком пакетов на мою машину.
Нормальный трафик (запросы ARP и т. Д.) Приходил примерно по 50 пакетов каждую секунду. Затем внезапно журнал был переполнен пакетами, приходящими ~ 5000 в секунду. Похоже, что все они содержат одни и те же данные, просто зацикленную последовательность.
Кто-то здесь смотрит на это, но я подумал, что спрошу, видел ли кто-нибудь что-нибудь подобное раньше.
Вот выбор из одного из снимков в Wireshark (щелкните изображение, чтобы открыть снимок Cloudshark): 
Во-первых, ни количество кадров, ни объем данных не должны как таковые существенно влиять на сетевые соединения даже при наличии только Fast Ethernet - 5000 кадров по 500 байт составляют немного меньше 2,5 МБ / с данных. Однако они могут запускать механизмы обнаружения широковещательного шторма на ваших коммутаторах, что приводит к отбрасыванию широковещательных кадров законного трафика, особенно запросов ARP, что может отрицательно повлиять на IP-соединение (хотя обычно не прерывает его полностью, вы, вероятно, увидите потери пакетов из-за несвоевременного ARP. разрешающая способность).
Кадры LLC в отправленном вами снимке выглядят странно. Ни исходный адрес, ни адрес назначения многоадресной рассылки не похожи на действительные реальные адреса. Кроме того, формат кадра LLC нарушает стандарт - адреса NULL используются в сочетании с типом кадра пользовательского интерфейса, чего никогда не должно происходить:
Нулевой адрес действителен только для использования в адресных полях XID и TEST PDU. Использование нулевого адреса (DSAP и SSAP) определено в ISO / IEC 8802-2.
(Источник: Руководство IEEE LLC)
Я бы заподозрил какое-то устройство (предположительно не Xerox, хотя исходный адрес разрешается в адресное пространство MAC Xerox - я бы ожидал, что они знают об основных правилах и соблюдают их) нарушает протокол. Попробуйте найти его, заглянув в таблицы FDB / адресов ваших управляемых коммутаторов: начните с произвольного управляемого коммутатора, найдите 00:00:03:20:00:00 адрес в таблице, который предположительно будет связан с восходящим портом к другому коммутатору, следуйте к следующему коммутатору, повторяя процедуру, если вы не найдете адрес, связанный с пограничным портом (т.е.порт с одним подключенным хостом).
Неисправная сетевая карта может это сделать, и я не знаю почему. Я очень редко вижу это, но всегда сходит с ума одна сетевая карта. Поменяйте его местами, и вы, вероятно, никогда больше этого не увидите.
Когда я смотрю на шестнадцатеричный дамп, я замечаю, что это одна и та же последовательность из четырех байтов, повторяющаяся снова и снова. Эта последовательность из четырех байтов не является действительными данными, и попытка ее декодирования не даст никакой полезной информации.
Эта повторяющаяся последовательность охватывает как исходный, так и целевой MAC-адреса, а также тип Ether. Это означает, что ни MAC-адрес источника, ни назначения ничего не значит, они были повреждены. Это тоже не кадр LLC, просто так получилось, что эта последовательность байтов была декодирована как LLC.
Если вы снова увидите что-то подобное, я сначала попробую захватить трафик, используя адаптеры Ethernet более чем одной марки, чтобы убедиться, что эти поврежденные кадры действительно отправляются по сети, а не просто артефакт, представленный на машине, выполняющей захват.
Если вы установили, что этот трафик действительно пересылается по сети, вам нужно будет начать искать, какое устройство его производит. Это похоже на проблему низкого уровня на физическом уровне ниже уровня MAC. У вас не будет MAC-адресов, поэтому единственный способ найти источник может заключаться в том, чтобы посмотреть на мигающий статус канала и отсоединить провода, пока вы не найдете тот, который производит эти пакеты.
Не исключено, что основной причиной было неисправное оборудование.