Я работаю администратором сети в большой компании. Недавно мы заметили проблему с нашей сетевой инфраструктурой. В основном наш сетевой бэкэнд находится на Catalyst в качестве основного внутреннего коммутатора L3 и нескольких коммутаторах Cisco Nexus в качестве граничных коммутаторов L2, подключенных к этому Catalyst.
Проблема возникает, когда мы пытаемся перехватить трафик на одном из наших хостов - затем мы (всегда) видеть одноадресный трафик между другими хостами.
Я постараюсь уточнить: предполагая, что я нахожусь на хосте 10.0.0.1, с mac MAC, Запускаю команду -
tcpdump -i eth0 ether host not MAC and host not 10.0.0.1 and not broadcast and not multicast
я буду всегда увидеть трафик между другими хостами.
Я прочитал статью Cisco о Одноадресное наводнениеОднако это «явление» происходит не только при прохождении между VLAN в нашей сети, но и в одной и той же VLAN. Возможно ли, что это происходит при передаче между коммутаторами в одной и той же VLAN (наши VLAN охватывают множество коммутаторов)? Все коммутаторы соединены транком с Catalyst ...
Любые идеи?
Спасибо.
Редактировать:
Похоже, мы нашли источник наших проблем.
По сути, каждый раз, когда один из коммутаторов получает кадр с нераспознаваемым MAC-адресом, он рассылает его по всем портам. Это нормально - и так должно быть. Однако в наших текущих настройках запись MAC в коммутаторе должна «жить» 30 минут. Если MAC-адрес не был замечен в течение 30 минут, он будет удален с коммутатора до тех пор, пока его снова не увидят. Если пакет отправлен на этот MAC-адрес, а его нет в таблице, все порты будут затоплены, чтобы найти MAC-порт назначения (мы ожидаем получить ответ от одного из портов).
Мы нашли один из MAC-адресов назначения и искали его в таблице MAC-адресов коммутатора. Таблица не содержала MAC, пока сеть была затоплена. Мы попробовали ARP-адрес, связанный с этим MAC-адресом, и лавинная рассылка остановилась (поскольку MAC-адрес снова появился в таблице MAC-адресов).
Однако через несколько секунд MAC снова исчез из таблицы MAC, и лавинная рассылка снова началась.
Похоже, что проблема лавинной рассылки возникает из-за проблем с таблицами MAC-адресов на наших коммутаторах. Кажется, что они «забывают» MAC-адреса быстрее, чем должны (MAC-адреса должны оставаться в течение 30 минут), и заполняют все пакеты этим MAC-адресом.
Быстрый приквел-
Таблица ARP - устройство L3 (маршрутизатор, хост и т. Д.) Поддерживает отображение между заданным IP-адресом и соответствующим MAC-адресом.
Таблица CAM - это может быть известно под другими именами в определенных платформах коммутатора, но в результате данное коммутационное устройство L2 поддерживает отображение между заданным аппаратным адресом и одним или несколькими физическими портами коммутатора.
То, что происходит в приведенном выше случае, называется одноадресным флудом. Это условие, при котором маршрутизатор все еще имеет действующую запись ARP, даже если таблица CAM коммутатора сбросила соответствующую запись. В результате, когда маршрутизатор получает пакет для данного хоста, он просто пересылается коммутатору без предварительной отправки запроса ARP (сопоставление IP: MAC все еще кэшируется). Однако коммутатор больше не знает порт, которому сопоставлен этот MAC-адрес (эта запись устарела ранее). Если коммутатор не имеет записи CAM для данного одноадресного MAC-адреса, он будет лавинно рассылать пакеты для этого MAC-адреса на все порты, пока не увидит ответ (то есть ответ на запрос ARP).
По непонятным причинам таймеры ARP и CAM обычно сильно различаются на коммутаторах Cisco. Значения несколько различаются, но несоответствие сохраняется на самых современных устройствах Nexus. Лучшая практика - установить для таймеров ARP и CAM одинаковые значения - в идеале с таблицей CAM, установленной на 5 секунд или около того дольше, чем ARP. Лучше, чтобы маршрутизатор повторно использовал ARP, чем коммутатору приходилось лавировать. Установка обоих значений на ~ 600 секунд (10 минут) обычно не так уж и плохо, но в некоторых средах может потребоваться немного больше времени, если на маршрутизаторе наблюдается чрезмерный трафик ARP.
Да, вещает ARP (бросьте wirehark, и вы увидите: «У кого есть бла-бла-бла. Скажи-бла.»).
Клиент должен ответить: «Это я!» Итак, я бы исследовал клиента, который не отвечает.