Коммутаторы должны отправлять трафик в систему только в том случае, если он предназначен для этой системы. Наш, похоже, не работает: если я запускаю «tcpdump not host myhostname», я вижу много пакетов, которые явно не широковещательные (ssh, nfs), перемещающиеся между другими хостами. Как я могу предотвратить это? Я думаю, это может быть причиной плохой производительности (у нас интенсивное использование NFS; если он выходит из всех портов коммутатора, это не может быть хорошо).
Коммутатор представляет собой стек из трех управляемых коммутаторов Netgear GS748TS. Индикаторы активности переключателя все мигают синхронно, что тоже кажется неправильным.
Обычно коммутатор не должен возвращаться в режим «концентратора», если вы не перегрузили его таблицу MAC-адресов (обычно около 8000+ MAC-адресов, но проверьте детали производителя / модели). Вы можете проверить количество MAC-адресов на данном коммутаторе Cisco с помощью этой команды:
sh mac-address-table | inc Total
Коммутаторы принимают все свои решения на основе тега vlan (если вы их используете) и MAC-адреса. Если вы получаете наводнение, вам нужно посмотреть, почему коммутатор не создает точную таблицу MAC-адресов.
Однако вы можете получить такое поведение, если получите то, что я называю «vlan bleed». Если у вас есть два порта коммутатора, подключенных друг к другу, но на разных vlan, вы можете увидеть это поведение.
Устройство с несколькими сетевыми картами также может соединять вланы вместе. У Microsoft была «функция» для объединения сетевых карт, чтобы ваши беспроводные и проводные сети были соединены для экземпляра.
Посмотрите в своей таблице Mac порты с более чем одним адресом, которые не связаны с другим коммутатором. Вы также можете отслеживать MAC-адрес одного из устройств, которое должно быть одноадресным, через таблицы MAC-адресов ваших коммутаторов.
На коммутаторах Cisco эти команды могут быть полезны:
sh mac-address-table | ex CPU
sh mac-address-table | ex CPU|<uplink port name>
Возможно, вы не видите того, что я собираюсь описать, но есть шанс, что это так. Я видел симптомы, о которых вы говорите, на нескольких коммутаторах Netgear и Linksys низкого и среднего ценового сегмента. Коммутаторы, с которыми я наблюдал такое "сумасшедшее" поведение, некоторое время были на месте, работают нормально, но начинают заливать кадрами все порты. Обычно я получаю сообщение «сеть работает медленно», и последующий мониторинг пропускной способности обычно обнаруживает один коммутатор, который «сошел с ума», часто с постоянным светом его активности, выкачивая большое количество «фиктивного» трафика (иногда созданного законного трафика, а иногда и случайного мусора).
Мне нравится предложение Zypher о проверке использования ЦП, но я бы также подумал о разбиении «стека» (на этих конкретных коммутаторах я не знаю, работает ли «стек» как единая логическая единица или нет) и тестирование каждого коммутатора. индивидуально.
Похоже, что за последние несколько лет эта проблема усугубилась из-за безымянных коммутаторов Ethernet, Linksys и Netgear. Я не знаю, есть ли общий кремний, у которого есть проблема с переключателями, которые я видел, или нет. (Мы рекомендуем нашим клиентам приобретать коммутаторы Dell PowerConnect и пока не сталкивались с подобными проблемами с их коммутаторами.)
Первое, что я проверю, - это нагрузка на ваш коммутатор. Если вы запускаете его при такой высокой нагрузке, что он не может правильно переключать пакеты (на большинстве коммутаторов это начинает происходить в области загрузки процессора 80-90%), он не сможет эффективно выступать в роли концентратора, а также возможность отбрасывания пакетов.
Хотя другие ответы кажутся более вероятными из того, что вы описали, убедитесь, что порт, к которому вы подключены, не настроен как зеркальный порт.
Такое поведение обычно указывает на то, что коммутатор не имеет записи в своей таблице моста (также известной как таблица CAM или таблица MAC-адресов) для MAC-адреса назначения кадра. Cisco называет это одноадресное наводнение.
Не могли бы вы подробнее рассказать о своей топологии? Предназначен ли весь «неожиданный» трафик для одного хоста или для нескольких хостов? Использует ли какой-либо из ваших хостов связанные сетевые адаптеры / объединенные сетевые адаптеры? Возможно, что входящий трафик отправляется на один MAC-адрес, но исходящий трафик с хоста поступает от другого сетевого адаптера.
РЕДАКТИРОВАТЬ: поскольку ложный трафик ограничен некоторыми MAC, это может быть хорошим местом для начала. Можете ли вы опросить таблицу моста коммутатора (показать таблицу mac-адресов на устройствах Cisco) и найти, есть ли запись для ошибочных MAC-адресов назначения? Кроме того, можете ли вы подтвердить значение тайм-аута для таблицы моста коммутатора?
Один случай, когда я видел такое поведение раньше, - это подсети, где значение тайм-аута ARP установлено выше тайм-аута таблицы MAC-адресов. Обычно, когда запись ARP устаревает, отправляется зонд ARP. Ответ на зонд фиксируется коммутатором, который сохраняет исходный MAC-адрес хоста в своей таблице мостов. Когда эти таймеры меняются местами, мостовая запись устаревает раньше, чем запись ARP. Это означает, что маршрутизаторы / хосты в подсети знают, какой MAC-адрес владеет данным IP, но коммутатор не знает, к какому порту подключен этот MAC. В этом случае коммутатор направит трафик на все порты в этой VLAN.
Предполагается, что коммутатор отправляет направленный трафик, но не всегда.
Каждый коммутатор поддерживает таблицу ARP, как и каждый хост в сети.
Простая атака -
Если вам нужно прослушать пакет, который вам не принадлежит в коммутируемой локальной сети. Что вы делаете, так это генерируете множество поддельных запросов arp и перегружаете таблицу ARP в коммутаторе. После перегрузки таблицы ARP коммутатор работает в режиме HUB по умолчанию.
Чрезмерное использование ЦП может быть причиной низкой производительности, но я почти наверняка думаю, что не за такие штормы пакетов.