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