У нас есть сеть коммутаторов HP 2510G, подключенных к HP2912al для агрегирования. Мы заметили, что длительные соединения, такие как дамп БД MySQL, начинают рассылать потоки на все сетевые порты по истечении времени ожидания mac-cache-timeout. Выполнение «arping» против IP-адреса назначения останавливает лавинную рассылку (переход от порта к порту) до тех пор, пока снова не истечет время ожидания кеширования.
Я могу понять, почему это происходит с однонаправленным трафиком UDP, но я не понимаю, почему это происходит с TCP. Я бы подумал, что ACK от принимающей машины заставят Procurves обновить MAC-адрес в своем кеше. Вместо этого кажется, что они учатся только на ARP.
Любые идеи?
Основная проблема, с которой вы здесь сталкиваетесь, заключается в том, что запись MAC истекает и не обновляется во времени, что вызывает одноадресную лавинную рассылку. В этой ситуации можно заподозрить несколько вещей:
Отток таблицы MAC-адресов. Если у вас слишком много хостов в домене коллизии коммутатора, вы можете получить отток таблицы MAC, когда истекло время для используемых записей. Обычно это происходит, когда вы соединяете большое количество VLAN через коммутатор для соединения двух основных сетей.
Изменения STP обычно вызывают наводнение. Неправильная конфигурация в STP (переключатели с идентичными идентификаторами ...) и нестабильные ссылки могут вызвать очистку кешей и неожиданное лавинное сообщение.
Если вы используете 802.1q и у вас нет симметричной настройки, вы можете заставить коммутатор узнать пункт назначения в неправильной VLAN. Это приведет к тому, что коммутатор в конечном итоге забудет запись и начнет лавинную рассылку. Поскольку ответы поступают в другой VLAN, коммутатор будет продолжать лавинную рассылку.
У вас ситуация с асимметричной маршрутизацией. Если ваша маршрутизация асимметрична и трафик не идет в обратном направлении, вы можете легко сократить время для записей в таблице MAC-адресов. Например, на следующем рисунке трафик от router1 к маршрутизатору 2 проходит через Switch1, а трафик от router2 к Router1 проходит через Switch2. В этом случае вы рискуете получить наводнение host3.
host1
|
Router1
| |
Switch1 Switch2 - Host3
| |
Router2
|
host2
Чисто однонаправленный трафик. В этом случае вам нужно увеличить ttl таблицы Mac настолько, чтобы изящные arps из ОС (если они настроены на отправку) сохраняли актуальность таблицы, или даже жестко настроить пересылку. Обратите внимание, что чисто однонаправленный трафик встречается очень редко. Дамп MYSQL не должен быть однонаправленным. Я видел это только в случаях асимметричной маршрутизации.
В качестве временной меры я рекомендую развернуть arpd (или аналогичный), чтобы обеспечить изящные arps и остановить наводнение. Он должен иметь тот же эффект, что и ARPPing (который, как вы обнаружили, временно решает проблему). Но вам действительно стоит отладить это.
Моя первая остановка - проверить, действительно ли маршрутизация полностью симметрична, поскольку проблема с асимметричной маршрутизацией кажется наиболее вероятной.
Также ознакомьтесь с документацией Cisco по Одноадресное наводнение в сетях кампуса что довольно хорошо.