Jump to content
Калькуляторы

[solved] Коммутатор DES-3200 не отвечает на arp? Загадка Сфинкса...

Довольно давно наблюдаем такую проблему, постепенно набирающую обороты:

Некоторые коммутаторы становятся не доступны на интервалы времени примерно от 5 секунд до 5 минут. Разбор ситуации показал, что после устаревания запись для интефрейса коммутатора в arp-таблице маршрутизатора обновляется не всегда. В это время коммутатор не доступен ни с маршрутизатора, ни с других устройств в том же управляющем влане. Если создать в arp-таблице другой железки статическую запись для проблемного коммутатора, то оттуда доступ к нему появляется. При этом на самом проблемном коммутаторе с arp-таблицей все хорошо. Если до начала проблемы запустить с него ping на хост, то на этом хосте снифер регистрирует пакеты как положено и после того, как коммутатор "отваливается". Коммутация тоже не страдает. Складывается впечатление, что коммутатор не может корректно ответить на arp-запрос. От наличия ACL, аптайма и версии прошивки, похоже, не зависит.

 

Глюк "лечится" ребутом. Как временную контрмеру применяем увеличение arp aging time на маршрутизаторах. В целом ситуация улучшается, но это не выход. Может кто наблюдал такую же проблему или даже решил ее?

Edited by xcme

Share this post


Link to post
Share on other sites

Колец нет у вас в сети? ARP-полисинга на проблемных железках, на которых отсутствует ARP-запись, нет? Число арп-запросов, приходящих на железки?

Edited by Alex/AT

Share this post


Link to post
Share on other sites

Самый банальный вопрос. А в flood_fdb нет мака проблемного свитча?

Share this post


Link to post
Share on other sites

Подтверждаю проблему. В сети зоопарк из 3200/3526/3528, но "отсыхают" на короткие интервалы именно 3200. fdb_flood не подтвердилось. Я грешил на высокую загрузку ЦПУ. Включил safeguard с порогом срабатывания 80% - стало отваливаться заметно меньше. Но от чего возникают кратковременные пики в нагрузке на ЦПУ пока не понятно. На свичах задействовано dhcp_relay opt82 + IMPB + ISM. Наверное корень зла где-то тут порылся.

Share this post


Link to post
Share on other sites

Колец нет, во flood_fdb пусто. SGE включал отключал - без разницы. IMPB включен был только в одном районе, через 3 дня от него отказались - сыроват. Загрузка cpu тоже в норме. Ребутнул несколько - почти всем помогло, а один свич снова за старое. Пока идеи закончились:(

 

Вот что не отключал и что есть на всех свичах - dhcp relay + opt82. И еще ISM

Edited by xcme

Share this post


Link to post
Share on other sites

Куда, кстати, сайт длинка делся? Забыли регистратору домена проплатить продление? ДНС dlink.ru не резолвит.

Share this post


Link to post
Share on other sites

xcme

Попробуйте создать ещё один L3-интерфейс(в другом влане) и в момент недоступности основного, интересно знать, будет свитч ли отвечать на арпы в другом влане.

 

Куда, кстати, сайт длинка делся? Забыли регистратору домена проплатить продление? ДНС dlink.ru не резолвит.

 

whois отменили? до августа у них домен проплачен

Share this post


Link to post
Share on other sites

Пробовал. Ситуация точно такая же, т.е. в момент проблем недоступны оба. Если сделать для какого-либо из интерфейсов статическую запись, соответственно доступен будет только он.

 

Вообще впечатление, что коммутатор таки пытается слать arp-ответ, вот только удается ему это не всегда. Когда свич "оживает" сразу удаляю запись в таблице - снова падает на какое то время. Потом опять оживает - снова удаляю запись, на этот раз "отключается" уже на другой период времени.

 

В следующий раз попробую DHCP Relay выключить, может таки он виноват...

Share this post


Link to post
Share on other sites

Тогда создайте статическую arp-запись для проблемного коммутатора в точке терминирования и нарисуйте график по cpu-usage с интервалом 1 раз в минуту, может там будут видны полки по cpu.

 

У вас arp inspection включена? Если да, то возможно, что абонентский arp, проверяемый cpu мешает arp-у в mgmt-влане, хотя могу и ошибаться, т.к. не знаю подробностей реализации конкретно этого коммутатора.

Share this post


Link to post
Share on other sites
Пробовал. Ситуация точно такая же, т.е. в момент проблем недоступны оба

Это намекает, что у вас где-то летает слишком много ARP-запросов, либо просто очень много хостов в подсетях, и L3-коммутатор уже не справляется.

Проверьте всё-таки arp policer'ы, если они есть, и размеры ARP-таблицы на том L3, что смотрит на управление коммутаторами.

Edited by Alex/AT

Share this post


Link to post
Share on other sites

Это намекает, что у вас где-то летает слишком много ARP-запросов, либо просто очень много хостов в подсетях, и L3-коммутатор уже не справляется.

Проверьте всё-таки arp policer'ы, если они есть, и размеры ARP-таблицы на том L3, что смотрит на управление коммутаторами.

Под L3 здесь имелся ввиду еще один интерфейс на коммутаторе, но в другом влане. DES-3200 так позволяет. А доступ пропадает не только с L3-маршрутизатора, но вообще с любого устройства в том же влане, где находится интерфейс коммутатора. Так что тут дело в самой железке. Все невалидные пользовательские ARP зарезал - толку нет.

Edited by xcme

Share this post


Link to post
Share on other sites

Если я Вас правильно понял - у Вас на 3200 несколько L3 интерфейсов поднято?

Edited by Alex/AT

Share this post


Link to post
Share on other sites

Вообще по одному, но на одном проблемном коммутаторе сделал второй, как и предложил s.lobanov, чтобы посмотреть на поведение при возникновении проблемы. Так вот, отваливаются они оба)

Абонентские арпы порезал при помощи PCF, понаблюдал - эффекта нет. Коммутатор все так же "падает". На абонентском трафике (и на arp в т.ч.) это не отражается никак.

Edited by xcme

Share this post


Link to post
Share on other sites

Странно это. В данном случае есть смысл, конечно, написать на форум длинка о проблеме. Ну и конфиг тоже бы видеть не помешало.

Share this post


Link to post
Share on other sites

Похоже виноват мультикаст влан. Убил его - почти 2.5 часа коммутатор жил без проблем. Вернул - снова валится. Попробую покрутить настройки...

Share this post


Link to post
Share on other sites

Хм. У нас в сети на всех узлах развернут ISM VLAN, коммутаторов очень много, ничего не валится. Странно. Прошивка свежая?

Edited by Alex/AT

Share this post


Link to post
Share on other sites

Подтвержаю. Аналогичная проблема.

 

Единственная странность : есть часть сети, где зоопарк из 3200,3528,3528 - там их очень много, причем все с одном vlan. Из функционала IMB(статический), ISM VLAN - такой проблеммы нет.

 

Есть другая часть сети, разница только в том, что на доступе только 3200-xx и из функционала: dhcp_local_relay + IMB (dhcp snooping) и mvr vlan. Проблема в точности такая! Причем коммутаторов там очень мало...

Share this post


Link to post
Share on other sites

Нашел причину проблемы. Это мониторинг flood fdb. Если его выключить - коммутатор отвечает на ARP как положено. Глюк проявляется, видимо, при большом либо каком то специфическом трафике.

Share this post


Link to post
Share on other sites

Нашел причину проблемы. Это мониторинг flood fdb. Если его выключить - коммутатор отвечает на ARP как положено. Глюк проявляется, видимо, при большом либо каком то специфическом трафике.

 

А длинк подтвердил данную проблему? Фикс обещают?

Share this post


Link to post
Share on other sites

Присоединяюсь к вопросу - а то я его только на всех свичах включить собрался)

Share this post


Link to post
Share on other sites

Нашел причину проблемы. Это мониторинг flood fdb. Если его выключить - коммутатор отвечает на ARP как положено. Глюк проявляется, видимо, при большом либо каком то специфическом трафике.

 

А длинк подтвердил данную проблему? Фикс обещают?

Д-Линк проигнорировал, как обычно. Как воспроизвести проблему неизвестно, потому молчат.

 

Присоединяюсь к вопросу - а то я его только на всех свичах включить собрался)

Можно попробовать включить и посмотреть что будет. Возможно в проблеме виноват какой то специфичный трафик, который получится вычленить и заблокировать. Если мультикаст не гоняете по сети - включайте. Мне кажется с ним связано много проблем.

 

p.s. 3028 тоже подвержен проблеме, но выражается она там по другому - процессор грузится на 100% и коммутатор становится недоступен.

Share this post


Link to post
Share on other sites

странно это

у нас есть 3200 и flood fdb включен, таких проблем не замечается

Share this post


Link to post
Share on other sites

Нашел причину проблемы. Это мониторинг flood fdb. Если его выключить - коммутатор отвечает на ARP как положено. Глюк проявляется, видимо, при большом либо каком то специфическом трафике.

 

А длинк подтвердил данную проблему? Фикс обещают?

Д-Линк проигнорировал, как обычно. Как воспроизвести проблему неизвестно, потому молчат.

 

Присоединяюсь к вопросу - а то я его только на всех свичах включить собрался)

Можно попробовать включить и посмотреть что будет. Возможно в проблеме виноват какой то специфичный трафик, который получится вычленить и заблокировать. Если мультикаст не гоняете по сети - включайте. Мне кажется с ним связано много проблем.

 

p.s. 3028 тоже подвержен проблеме, но выражается она там по другому - процессор грузится на 100% и коммутатор становится недоступен.

 

У меня там только 3200-хх, есть мультикаст. И да, включен flood_fdb.

Заметил, что как только начать обильно посылать арпы, например через arping. Коммутатор сразу оживает. Так я нагиос просто на arping переделал и убил двух зайцев )

 

Но собственно пофиксить ее длинку не мешало бы

 

странно это

у нас есть 3200 и flood fdb включен, таких проблем не замечается

 

У меня в сегменте сети, где есть еще другие модели - 3526,3528 такого тоже не наблюдается...

А вот где только 3200 такая борода.

 

Отличие одно - в сегменте где только 3200, dhcp_local_relay и dhcp snooping используется.

Share this post


Link to post
Share on other sites

А вот где только 3200 такая борода.

Отличие одно - в сегменте где только 3200, dhcp_local_relay и dhcp snooping используется.

у нас только 3200 во всех сегментах

dhcp_local_relay и dhcp snooping также везде включены

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this