2 LPD61: Соберите, пожалуйста, запрошенную информацию.
2 `kk: Я запросил Вас кое-что уточнить почтой.

Добрый день. Со своей стороны проблему решили. Нашли ошибку в конфигурации.

2 LPD61: Вас понял. Спасибо.

Прошу поделиться исправлениями в конфигурации. Подозреваю, что такая проблема не только у вас

Прошу поделиться решением, проблему подтверждаю.

2 ALL

снимите след. данные во время проблемы (перед ребутом):


а дальше Денис скажет, что нам делать =)

Возможно, у меня проблема в другом, но хотелось бы увидеть исправления конфига от LPD61. Вдруг именно их не хватает в моём случае.
Ситуация такая, что около трёх-четырёх раз в день отваливается управление одного из свичей доступа. Влан на пользователя. Топология - звезда. В ядре стоит Микротик, который показывает, что в момент отвала трафик на агрегирующем интерфейсе стремится к максимуму пропускной способности этого интерфейса. Источник трафика - один из свичей, назначение - DHCP-сервер, порт 67.
Есть предположение, что несколько клиентов одновременно отправляют броадкастовые запросы IP-адреса (например, сразу после перезагрузки свича), свич их релеит и тем самым забивает всю полосу. Ответ от DHCP пройти не может, так как не хватает полосы. Клиенты в панике запрашивают адрес заново. Отсюда коллапс.
Пока "испытания" приостановлены костылём в виде ограничения полосы для данного типа трафика на Микротике (это действительно помогло). Сеть живая, возможности для тестов нет. Достучаться до свича во время проблемы не реально, поэтому выполнить приведённые команды не представляется возможным.

У Вас скорее всего петля возникает в сети, которую нужно устранить. Если используется DHCP Relay, то рекомендуется этот функционал отключать на магистральных портах и оставлять включенным только на клиентских. Прошивку нужно обновить до актуальной версии.

Денис, первоначально подозрение было на логическую петлю, физической петли быть не может, так как звезда и включен loopdetect на клиентских портах. Изучение сетевых настроек на всех устройствах показало, что и логической петли тоже нет. К тому же, при петле не дублировался бы юникастовый трафик, как в нашем случае. Прошивки на всём доступе обновили до последней версии. DHCP Relay на магистралях отключен, кроме того используется повиланный релэй в схеме влан на пользователя. Обратил внимание, что возникает проблема только на свичах, подключенных по магистрали в 100 Мбит/с.

Приведите, пожалуйста, настройки из секции DHCP Relay. И уточните, пожалуйста, текущую версию прошивки.

Обновление прошивок мониторим почти каждый день.
Привожу пример с одного из коммутаторов DES-3200-28 rev.C1, который был замечен в шторме. Кроме них на доступе имеются DES-3200-xx rev.A1, DES-3028, DES-3552. Аплинк - первый комбо-порт (здесь - 25).

Чаще всего штормил DES-3200-10 (аплинк - 9):


Пока писал, обнаружил ошибку во втором конфиге:
Как я понимаю, эта строка включает общий релэй, независимо от перечисленных ниже вланов и портов?

Да, настройки для ipif System не требуется указывать, если у Вас уже повиланно настроено.
26-28 порты в первом случае и 10 порт во втором смотрят на нижестоящие коммутаторы, на которых также DHCP Relay настроен?
И нужно сделать: "config dhcp_relay option_82 check disable"

Они не используются на этих двух коммутаторах. Но на других - отдаём их под клиентские порты.

Насколько я понимаю, в моём случае должно быть enable, чтобы отбрасывать клиентские DHCP-запросы, содержащие option 82.

Пробежался по всем коммутаторам. Опция dhcp_relay add ipif System оказалась включена только на одном. При этом шторм исходил не всегда от него.

То есть у Вас нет, таких участков сети, где эти коммутаторы соединены цепочкой? Если же есть, то DHCP Relay нужно отключить на портах, смотрящих в сторону соседних коммутаторов.

Нет, цепочка у нас только в одном месте:
Ядро - D-Link DES-3200-28 rev.C1 - Ubiquiti - клиенты.
Цепочек из D-Link'ов нет.
Здесь оборудование Ubiquiti только тэгирует трафик от разных клиентов, релэй всё равно происходит на D-Link'е, поэтому DHCP Relay на порту, смотрящем в сторону Ubiquiti, включен.
Уточните, пожалуйста, ещё раз по поводу option_82 check. Я правильно понимаю её смысл?