Переключите пакеты Floods, которые должны быть одноадресными
Я работаю сетевым администратором в большой компании. В последнее время мы заметили проблему с нашей сетевой инфраструктурой. По сути, наш сетевой сервер находится на 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 охватывают множество коммутаторов)? Все коммутаторы соединены магистралью с Катализатором...
Есть идеи?
Благодарю.
Редактировать:
Кажется, мы нашли источник наших проблем.
По сути, каждый раз, когда один из коммутаторов получает фрейм с MAC-адресом, который он не распознает, он перенаправляет его на все порты. Это нормально - и так должно быть. Однако в наших текущих настройках запись MAC в коммутаторе должна "жить" в течение 30 минут. Если MAC не был замечен в течение 30 минут, он будет удален с коммутатора до повторного просмотра. Если пакет отправлен на этот MAC, а его нет в таблице - все порты будут заполнены, чтобы найти целевой MAC-порт (мы ожидаем получить ответ от одного из портов).
Мы нашли один из MAC-адресов назначения и искали его в таблице MAC-адресов коммутатора. Таблица не содержала MAC, когда сеть была затоплена. Мы попытались ARPing адрес, связанный с этим MAC - и поток прекратился (поскольку MAC вновь появился в таблице MAC).
Однако через несколько секунд MAC снова исчез из таблицы MAC, и поток снова начался.
Кажется, что проблема с флудом возникает из-за проблем с таблицами MAC на наших коммутаторах. Похоже, что они "забывают" MAC-адреса быстрее, чем должны (MAC должен оставаться в течение 30 минут) и заполняют все пакеты этим MAC.
2 ответа
Быстрый приквел-
Таблица 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 вещает (подбросьте проволочную акулу, и вы увидите "У кого есть бла-бла-бла. Скажите бла".).
Клиент должен ответить обратно "Это я!" Итак, я бы расследовал клиента, который не отвечает.