Да, относительно option 82 check у Вас при такой схеме все верно. Уточните, пожалуйста, один момент: именно после обновления всех прошивок на 4.34.B007 проблема уже проявлялась?

Нет, ограничение на Микротике было выставлено до накатывания этой прошивки. В ней есть исправления функции релэя? Если да, то могу попробовать снять ограничение на Микротике и помониторить сетевую активность.
Вижу, что уже появилась 4.34.B008. Будем обновляться.

В 4.33.B010 было исправление похожей проблемы с размножением трафика. Если проблем будет наблюдаться, то пришлите, пожалуйста, выводы следующих команд во время наличия проблемы с коммутатора:

Снял ограничение на Микротике. Наблюдаем. Во время проблемы подключиться к коммутаторам не представляется возможным, так как вся полоса до них занята. Поможет ли эта информация, собранная сразу же после устранения проблемы?

После проблемы, к сожалению, не поможет. Нужна информация в момент наличия проблемы, снять ее можно по консоли.

имеем на своей сети похожую проблему с 3200 ревизии С1 прошивка 4.33.B004. При включении dhcp local relay в некоторых сегментах непредсказуемо от 3200 с1 начинает лететь какой то флуд в сторону dhcp. хотя на магистральных портах он выключен. ведем переписку с длинком, но пока безуспешно. пример конфига 3200 с1.

enable dhcp_local_relay
config dhcp_local_relay option_82 remote_id default
config dhcp_local_relay option_82 circuit_id default
config dhcp_local_relay option_82 ports 1-26 policy keep

# AAA_LOCAL_ENABLE_PASSWORD

config admin local_enable




# DHCP_RELAY

enable dhcp_relay
config dhcp_relay hops 4 time 0
config dhcp_relay option_82 state enable
config dhcp_relay option_82 check disable
config dhcp_relay option_82 policy replace
config dhcp_relay option_82 remote_id default
config dhcp_relay option_82 circuit_id default
config dhcp_relay option_60 state disable
config dhcp_relay option_61 state disable
config dhcp_relay add ipif System 192.168.3.60
config dhcp_relay option_60 default mode drop
config dhcp_relay option_61 default drop
config dhcp_relay ports 1-24 state enable
config dhcp_relay ports 25-26 state disable



на 3526 и 3200 а1,b1 все нормально

evgbb, а почему не хотите обновиться? У нас на 4.34.B007 вторые сутки полёт нормальный. До восьмого билда вчера обновиться не успели, может сегодня ночью накатим. Или вы иначе решаете проблему с непотребным трафиком?

И почему у Вас одновременно используется DHCP Local Relay и DHCP Relay? Нужно что-то одно выбрать.

попробую повыключаю dhcp_local relay . А далее по ситуации обновляться буду. Сообщу

Хорошо. Ждем Ваших результатов.

Добрый день!
С прошивкой 4.35.B010 проблема с "отвалом" менджмента повторилась. DHCP_Relay не используется. Флуда и перегрузки сети не замечено. Какие данные могут Вам понадобться для прояснения ситуации?

Вы по консоли пробовали подключиться к коммутатору во время наличия проблемы?

Возвращаясь к теме - сегодня снова отвалился коммутатор, уже с 4.35.B010. Попытаемся снять tech_support, если получится - сегодня же вышлю.
Уже переписывался с Артёмом Колпаковым по этой теме как по почте, так и в соседней ветке, новые данные я обещал отправить ему по мере поступления.

В tech_support с 4.34 две аномалии:
1. Процесс 818B3B68 bcmXGS3Asy 86588208 86588040 1K/ 16K 9 10/ 10 S:xgs3 tx asy - отсутствует
2. Семафор 818E68F0 xgs3PtxPasync N 0 0x818B3B68 Invalid owner! - потерял владельца

Предположительно увидим то же самое и на 4.35, но пока что утверждать не могу.

Есть ли какие-либо отладочные команды, которые позволят снять traceback, системные логи процессов или еще что-то? Если есть - снимем и пришлем.

_________________
Regards,
Senior NOC Engineer,
Alexey Asemov.

Alexey Asemov
Дополнительные команды для дебага разработчики могут выдать только после анализа tech_support информации, сейчас каких-либо команд они не дают, потому что причин для зависания может быть множество.

При возникновении проблемы на последней прошивке по консоли пока не было возможности подключиться.
Когда проблема проявлялась на предыдущих версиях, мы подключались через консоль, при этом никаких аномалий не было замечено: загрузка CPU, пртов в пределах нормы, ошибок на портах не было, информации в логах нет.
Единственное, что бросилось в глаза - в ту же минуту, когда отваливался свитч, один из клиентов (домашний пользователь) неоднократно поднимал/опускал линк. В некоторых случаях (это было замечено на разных объектах) отключение подозрительного кабеля от свитча физически сразу "отпускало" менеджмент (не всегда). Есть подозрение, пока как догадка, что на порт действуют низкоуровневые помехи, не поподающие под сетевые уровни (комбинации битов, элекромагнитные наводки и т.п.).