[solved] Коммутатор DES-3200 не отвечает на arp?

[xcme]

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

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

 

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

Edited April 15, 2012 by xcme

[Alex/AT]

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

Edited February 25, 2012 by Alex/AT

[vurd]

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

[Alexandr Ovcharenko]

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

[xcme]

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

 

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

Edited February 25, 2012 by xcme

[Alexandr Ovcharenko]

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

[s.lobanov]

xcme

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

 

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

 

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

[xcme]

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

 

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

 

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

[s.lobanov]

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

 

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

[Alex/AT]

Пробовал. Ситуация точно такая же, т.е. в момент проблем недоступны оба

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

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

Edited February 25, 2012 by Alex/AT

[xcme]

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

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

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

Edited February 26, 2012 by xcme

[Alex/AT]

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

Edited February 26, 2012 by Alex/AT

[xcme]

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

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

Edited February 26, 2012 by xcme

[Alex/AT]

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

[xcme]

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

[Alex/AT]

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

Edited February 26, 2012 by Alex/AT

[h1vs2]

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

 

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

 

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

[s.lobanov]

xcme

А чем не понравилось предложение построить график по загрузке CPU? http://webcache.googleusercontent.com/search?q=cache:rdiJl0-CmmsJ:dlink.ru/ru/faq/59/257.html

[xcme]

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

[h1vs2]

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

 

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

[Butch3r]

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

[xcme]

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

 

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

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

 

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

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

 

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

[zi_rus]

странно это

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

[h1vs2]

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

 

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

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

 

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

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

 

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

 

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

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

 

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

 

странно это

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

 

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

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

 

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

[zi_rus]

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

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

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

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