Доброго времени суток.

Столкнулся с проблемой на одном из коммутаторов в сети. Постоянная загрузка cpu 100%.




Трафик на портах минимален. Управление в отдельном влане. После обновления ПО на коммутаторе я не сбрасывал кофиг, но в логе не написано ни про какие синтаксические ошибки, так что думаю, что это не должно никак влиять. Как видно по sh sw почти все сервисы выключены. Вопрос: в каком направлении рыть? Как можно диагностировать проблему и решить ее? Могу выслать конфиг, если нужно.

В дополнение к проблеме. Клиенты проблем не испытывают, по крайней мере пинг 3мс. Пинг до адреса управления 2-3 секунды (это не ошибка).

Попробуйте пожалуйста прошивку которую я Вам выслал.

Не помогло. Результат работы команды sh tech и некоторые комментарии отправил Вам на почту.

Попробуйте пожалуйста прошивку которую Вам выслал Руслан и отпишитесь по результатам.

Проблема решена. Заблокировал все клиентские порты - загрузка спала. Начал разблокировать порты пачками. Разблокировав очередную пачку портов потерял управление на коммутатор. Отправили на узел монтажника, он перезагрузил коммутатор. Начал блокировать порты по одному и нашел проблемный порт. Перенос патчкорда в другой порт проблему не решает. Ввиду того что на узле бардак (нам принадлежит только коммутатор, а провода не наши) узнать откуда патч корд не представляется возможным. Судя по МАС это не наш клиент, возможно какой то сосед. На данный момент просто заблокировали порт и ждем возможного звонка клиента.

Сейчас на коммутаторе прошивка за номером 6.00.B07. Откатываться на 5.01 B62, которую прислали, не решился, так как не уверен, что не слетит конфигурация. Сегодня проверю на тестовом стенде, но на живом не хочется делать эксперименты с этим портом. Один раз уже потерял управление,больше не хочу. Проблема решена и это хорошо, но возникает вопрос: как клиентский порт на котором минимальный трафик, находящийся в клиентском влане попадает под обработку CPU и загружает его под завязку?

Я Вам отправлял sh tech во время проблемы, сейчас могу отправить в тот момент, когда проблема решена, может это поможет в диагностике?

PSS Доходит до смешного. Появился еще один коммутатор с такой же проблемой. Проблема длилась порядка 5 минут и самоутранилась. В это время я даже на коммутатор не мог попасть, так как он отваливался по таймауту от TACACS сервера. В конце концов когда предложил использовать локальную учетную запись загрузка CPU спала. Коммутатор находится в домашней сети на нем настроено много всего (stp, dhcp, acl). При этом соседние коммутаторы работали без проблем. Коммутатор испытывал проблемы только по управлению. Сейчас все отлично. В логах ничего криминального. Никакие поты не поднимались. Списали на весеннее расстройство.

Loopdetect на портах включен?

Да.

Похожая проблема.
Прошивка 6.00.B07.

Свитч отваливается, но на L2 работает, т.е. вланы через него летят нормально. Лечился лишь перезагрузкой. Loop detect включен на всех абонентских портах.

Методом перебора найден порт, который вызывал проблему.
До причин не докопался.

Подозреваю, что это связано с LLDP или STP и какой-то петлей на порту. Когда свитч получает свой пакет обратно (наверное он посылает его со своим маком?), то вполне может заблокировать его (на аб. портах включен биндинг). Авторазблокировка в этой версии с проблемами (лечится сбросом FDB, жду фикса).

Что скажет D-Link на счет такой гипотетической возможности?

Нет с этим это скорее всего не связано.

Лично у меня STP и LLDP на данном коммутаторе отключено. Так каков будет ответ D-Link? Жить с этим и периодически бегать на узлы?

Немножко другая проблема возникла с очередным коммутатором (уже на третьем узле). Симптоматика такова: коммутатор периодически пропадает по управлению. Трафик через себя пропускает. В ходе разбирательств выяснилось, что прежде чем пропасть, коммутатор успевает прислать на syslog сервер трап:

Очень интересный статус порта. Прошивка - релиз 5.1
Спустя некоторое время (примерно 5 минут) коммутатор перестает отвечать по управлению. Но самое интересное, что порт заблокирован (клиент приостановил услугу и порт был заблокирован). Поменяли коммутатор на аналогичный. Проблема осталась (как выяснилось вчера). Сейчас переключили патч корд клиента в соседний коммутатор 3526(находящийся на этом же узле). К проблемному порту подключились ноутбуком - проблем нет. Различные манипуляции ничего не меняют. Посмотрим что произойдет на новом коммутаторе с новым портом. На этом коммутаторе настроено STP и еще некоторые вещи для работы в домашней сети.

PS Что от в эту весну коммутаторы стали себя вести очень странно. Раньше ни разу ничего подобного не было. А тут за очень короткий промежуток времени уже 2ой коммутатор намертво повисает периодически...

Ток не понял, включен или отключен ?

SaveGuard Engine попробуйте включить, часто помогает в подобных ситуациях.

Вы сами себе ответили на Ваш вопрос:

SafeGuard Engine State : Enabled
SafeGuard Engine Current Status : Exhausted mode

Коммутатор ведет себя именно так как и должен.
То есть в данный момент коммутатор не отвечает на arp запросы. Для того, чтобы не бегать на узлы, нужно прописать статически arp на компе, с которого происходится управление.
Скорее всего на этот порт идет arp флуд поэтому и срабатывает SGE. Подцепитесь к этому порту буком и и попробуйте поснифить.
И попробуйте осторожненько глянуть в сторону cpu_interface_filtering.

2terrible loopdetect включено, stp выключено, fbpdu выключено. Saveguard включен.

2Alexander Minin Сомневаюсь, что проблема такова, как Вы ее описали. Клиенты живут в отдельном влане, происходит чистая коммутация L2, никакие дополнительные возможности коммутатора (dhcp, stp, lldp и т.д.), не используются. Статическое прописывание arp не выход.

Вредный совет: а что если выключить loopdetect?

2Alexander Minin Сомневаюсь, что проблема такова, как Вы ее описали. Клиенты живут в отдельном влане, происходит чистая коммутация L2, никакие дополнительные возможности коммутатора (dhcp, stp, lldp и т.д.), не используются. Статическое прописывание arp не выход.[/quote]

Неееее.... В качестве аварийного выхода - для того чтобы попасть на менеджмент коммуататора, на котором в данный момент сработал SGE необходимо прописать статикой мак на компьютере с которого вы хотите на этот коммутатор попасть. Это для того чтобы не ходить на узел ногами. А для решения проблемы - подцеплять проблемный линк в ноутбук и снифить. И разбираться что за гадость оттуда приползает.

2 ahk: - действительно вредный совет