xcme Опубликовано 25 февраля, 2012 (изменено) · Жалоба Довольно давно наблюдаем такую проблему, постепенно набирающую обороты: Некоторые коммутаторы становятся не доступны на интервалы времени примерно от 5 секунд до 5 минут. Разбор ситуации показал, что после устаревания запись для интефрейса коммутатора в arp-таблице маршрутизатора обновляется не всегда. В это время коммутатор не доступен ни с маршрутизатора, ни с других устройств в том же управляющем влане. Если создать в arp-таблице другой железки статическую запись для проблемного коммутатора, то оттуда доступ к нему появляется. При этом на самом проблемном коммутаторе с arp-таблицей все хорошо. Если до начала проблемы запустить с него ping на хост, то на этом хосте снифер регистрирует пакеты как положено и после того, как коммутатор "отваливается". Коммутация тоже не страдает. Складывается впечатление, что коммутатор не может корректно ответить на arp-запрос. От наличия ACL, аптайма и версии прошивки, похоже, не зависит. Глюк "лечится" ребутом. Как временную контрмеру применяем увеличение arp aging time на маршрутизаторах. В целом ситуация улучшается, но это не выход. Может кто наблюдал такую же проблему или даже решил ее? Изменено 15 апреля, 2012 пользователем xcme Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alex/AT Опубликовано 25 февраля, 2012 (изменено) · Жалоба Колец нет у вас в сети? ARP-полисинга на проблемных железках, на которых отсутствует ARP-запись, нет? Число арп-запросов, приходящих на железки? Изменено 25 февраля, 2012 пользователем Alex/AT Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vurd Опубликовано 25 февраля, 2012 · Жалоба Самый банальный вопрос. А в flood_fdb нет мака проблемного свитча? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alexandr Ovcharenko Опубликовано 25 февраля, 2012 · Жалоба Подтверждаю проблему. В сети зоопарк из 3200/3526/3528, но "отсыхают" на короткие интервалы именно 3200. fdb_flood не подтвердилось. Я грешил на высокую загрузку ЦПУ. Включил safeguard с порогом срабатывания 80% - стало отваливаться заметно меньше. Но от чего возникают кратковременные пики в нагрузке на ЦПУ пока не понятно. На свичах задействовано dhcp_relay opt82 + IMPB + ISM. Наверное корень зла где-то тут порылся. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
xcme Опубликовано 25 февраля, 2012 (изменено) · Жалоба Колец нет, во flood_fdb пусто. SGE включал отключал - без разницы. IMPB включен был только в одном районе, через 3 дня от него отказались - сыроват. Загрузка cpu тоже в норме. Ребутнул несколько - почти всем помогло, а один свич снова за старое. Пока идеи закончились:( Вот что не отключал и что есть на всех свичах - dhcp relay + opt82. И еще ISM Изменено 25 февраля, 2012 пользователем xcme Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alexandr Ovcharenko Опубликовано 25 февраля, 2012 · Жалоба Куда, кстати, сайт длинка делся? Забыли регистратору домена проплатить продление? ДНС dlink.ru не резолвит. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 25 февраля, 2012 · Жалоба xcme Попробуйте создать ещё один L3-интерфейс(в другом влане) и в момент недоступности основного, интересно знать, будет свитч ли отвечать на арпы в другом влане. Куда, кстати, сайт длинка делся? Забыли регистратору домена проплатить продление? ДНС dlink.ru не резолвит. whois отменили? до августа у них домен проплачен Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
xcme Опубликовано 25 февраля, 2012 · Жалоба Пробовал. Ситуация точно такая же, т.е. в момент проблем недоступны оба. Если сделать для какого-либо из интерфейсов статическую запись, соответственно доступен будет только он. Вообще впечатление, что коммутатор таки пытается слать arp-ответ, вот только удается ему это не всегда. Когда свич "оживает" сразу удаляю запись в таблице - снова падает на какое то время. Потом опять оживает - снова удаляю запись, на этот раз "отключается" уже на другой период времени. В следующий раз попробую DHCP Relay выключить, может таки он виноват... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 25 февраля, 2012 · Жалоба Тогда создайте статическую arp-запись для проблемного коммутатора в точке терминирования и нарисуйте график по cpu-usage с интервалом 1 раз в минуту, может там будут видны полки по cpu. У вас arp inspection включена? Если да, то возможно, что абонентский arp, проверяемый cpu мешает arp-у в mgmt-влане, хотя могу и ошибаться, т.к. не знаю подробностей реализации конкретно этого коммутатора. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alex/AT Опубликовано 25 февраля, 2012 (изменено) · Жалоба Пробовал. Ситуация точно такая же, т.е. в момент проблем недоступны оба Это намекает, что у вас где-то летает слишком много ARP-запросов, либо просто очень много хостов в подсетях, и L3-коммутатор уже не справляется. Проверьте всё-таки arp policer'ы, если они есть, и размеры ARP-таблицы на том L3, что смотрит на управление коммутаторами. Изменено 25 февраля, 2012 пользователем Alex/AT Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
xcme Опубликовано 26 февраля, 2012 (изменено) · Жалоба Это намекает, что у вас где-то летает слишком много ARP-запросов, либо просто очень много хостов в подсетях, и L3-коммутатор уже не справляется. Проверьте всё-таки arp policer'ы, если они есть, и размеры ARP-таблицы на том L3, что смотрит на управление коммутаторами. Под L3 здесь имелся ввиду еще один интерфейс на коммутаторе, но в другом влане. DES-3200 так позволяет. А доступ пропадает не только с L3-маршрутизатора, но вообще с любого устройства в том же влане, где находится интерфейс коммутатора. Так что тут дело в самой железке. Все невалидные пользовательские ARP зарезал - толку нет. Изменено 26 февраля, 2012 пользователем xcme Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alex/AT Опубликовано 26 февраля, 2012 (изменено) · Жалоба Если я Вас правильно понял - у Вас на 3200 несколько L3 интерфейсов поднято? Изменено 26 февраля, 2012 пользователем Alex/AT Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
xcme Опубликовано 26 февраля, 2012 (изменено) · Жалоба Вообще по одному, но на одном проблемном коммутаторе сделал второй, как и предложил s.lobanov, чтобы посмотреть на поведение при возникновении проблемы. Так вот, отваливаются они оба) Абонентские арпы порезал при помощи PCF, понаблюдал - эффекта нет. Коммутатор все так же "падает". На абонентском трафике (и на arp в т.ч.) это не отражается никак. Изменено 26 февраля, 2012 пользователем xcme Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alex/AT Опубликовано 26 февраля, 2012 · Жалоба Странно это. В данном случае есть смысл, конечно, написать на форум длинка о проблеме. Ну и конфиг тоже бы видеть не помешало. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
xcme Опубликовано 26 февраля, 2012 · Жалоба Похоже виноват мультикаст влан. Убил его - почти 2.5 часа коммутатор жил без проблем. Вернул - снова валится. Попробую покрутить настройки... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alex/AT Опубликовано 26 февраля, 2012 (изменено) · Жалоба Хм. У нас в сети на всех узлах развернут ISM VLAN, коммутаторов очень много, ничего не валится. Странно. Прошивка свежая? Изменено 26 февраля, 2012 пользователем Alex/AT Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
h1vs2 Опубликовано 26 февраля, 2012 · Жалоба Подтвержаю. Аналогичная проблема. Единственная странность : есть часть сети, где зоопарк из 3200,3528,3528 - там их очень много, причем все с одном vlan. Из функционала IMB(статический), ISM VLAN - такой проблеммы нет. Есть другая часть сети, разница только в том, что на доступе только 3200-xx и из функционала: dhcp_local_relay + IMB (dhcp snooping) и mvr vlan. Проблема в точности такая! Причем коммутаторов там очень мало... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 26 февраля, 2012 · Жалоба xcme А чем не понравилось предложение построить график по загрузке CPU? http://webcache.googleusercontent.com/search?q=cache:rdiJl0-CmmsJ:dlink.ru/ru/faq/59/257.html Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
xcme Опубликовано 15 апреля, 2012 · Жалоба Нашел причину проблемы. Это мониторинг flood fdb. Если его выключить - коммутатор отвечает на ARP как положено. Глюк проявляется, видимо, при большом либо каком то специфическом трафике. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
h1vs2 Опубликовано 7 мая, 2012 · Жалоба Нашел причину проблемы. Это мониторинг flood fdb. Если его выключить - коммутатор отвечает на ARP как положено. Глюк проявляется, видимо, при большом либо каком то специфическом трафике. А длинк подтвердил данную проблему? Фикс обещают? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Butch3r Опубликовано 7 мая, 2012 · Жалоба Присоединяюсь к вопросу - а то я его только на всех свичах включить собрался) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
xcme Опубликовано 7 мая, 2012 · Жалоба Нашел причину проблемы. Это мониторинг flood fdb. Если его выключить - коммутатор отвечает на ARP как положено. Глюк проявляется, видимо, при большом либо каком то специфическом трафике. А длинк подтвердил данную проблему? Фикс обещают? Д-Линк проигнорировал, как обычно. Как воспроизвести проблему неизвестно, потому молчат. Присоединяюсь к вопросу - а то я его только на всех свичах включить собрался) Можно попробовать включить и посмотреть что будет. Возможно в проблеме виноват какой то специфичный трафик, который получится вычленить и заблокировать. Если мультикаст не гоняете по сети - включайте. Мне кажется с ним связано много проблем. p.s. 3028 тоже подвержен проблеме, но выражается она там по другому - процессор грузится на 100% и коммутатор становится недоступен. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zi_rus Опубликовано 7 мая, 2012 · Жалоба странно это у нас есть 3200 и flood fdb включен, таких проблем не замечается Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
h1vs2 Опубликовано 7 мая, 2012 · Жалоба Нашел причину проблемы. Это мониторинг flood fdb. Если его выключить - коммутатор отвечает на ARP как положено. Глюк проявляется, видимо, при большом либо каком то специфическом трафике. А длинк подтвердил данную проблему? Фикс обещают? Д-Линк проигнорировал, как обычно. Как воспроизвести проблему неизвестно, потому молчат. Присоединяюсь к вопросу - а то я его только на всех свичах включить собрался) Можно попробовать включить и посмотреть что будет. Возможно в проблеме виноват какой то специфичный трафик, который получится вычленить и заблокировать. Если мультикаст не гоняете по сети - включайте. Мне кажется с ним связано много проблем. p.s. 3028 тоже подвержен проблеме, но выражается она там по другому - процессор грузится на 100% и коммутатор становится недоступен. У меня там только 3200-хх, есть мультикаст. И да, включен flood_fdb. Заметил, что как только начать обильно посылать арпы, например через arping. Коммутатор сразу оживает. Так я нагиос просто на arping переделал и убил двух зайцев ) Но собственно пофиксить ее длинку не мешало бы странно это у нас есть 3200 и flood fdb включен, таких проблем не замечается У меня в сегменте сети, где есть еще другие модели - 3526,3528 такого тоже не наблюдается... А вот где только 3200 такая борода. Отличие одно - в сегменте где только 3200, dhcp_local_relay и dhcp snooping используется. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zi_rus Опубликовано 7 мая, 2012 · Жалоба А вот где только 3200 такая борода. Отличие одно - в сегменте где только 3200, dhcp_local_relay и dhcp snooping используется. у нас только 3200 во всех сегментах dhcp_local_relay и dhcp snooping также везде включены Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
