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

Странное поведение сегмента сети ПД, "Зависает" активка, помогает только ребут.

Коллеги, приветствую!

 

Ситуация следующая:

С августа-сентября прошлого года подключен новый район к сегменту нашей сети. Дома - новостройки.

Размещено все оборудование в подвале, где круглогодично присутствует вода - от просто влажно до без сапог не пройти (специально обращаю на это внимание, возможно важность данного момента мной недооценена).

Оборудование размещено в антивандальных шкафах Е-29.

Для аггрегации используется D-Link DGS-3120-24SC, на доступе - Edge-Core ECS3510-28T.

До каждого коммутатора - отдельное волокно от агрегации, т.е. топология - классическая "звезда".

Трансиверы используем Opticin WDM 3-х километровые.

ИБП присутствует только на агрегации.

Оптику растаскивала в этом месте какая-то подрядная организация. Силами этой же организации и электричество было разведено. На каждый шкаф отдельно установлен автомат + счетчик.

 

Крайний месяц-два (т.е. почти через год работы установленных коммутаторов, к которым, кстати, были уже добавлены для расширения портов еще по 1-му Edge-Core аналогичному) наблюдаем периодические отвалы в работоспособности коммутаторов. Причем, все это происходит как рандомно, так и, например, после отключения электропитания и/или скачках напряжения в сети (со слов жильцов домов) часть коммутаторов автоматически не загружается корректно.

 

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

Просто на D-link'e в аггрегации нет приходящих MAC-ов с соответствующих коммутаторов. Если же с консоли смотреть MAC-и на магистральных портах коммтуаторов доступа - тоже тишина.

Помогает исключительно перезагрузка коммутаторов.

Shutdown / no shutdown интерфейсов не помогает.

Варианты media-type на коммутаторах доступа тоже пробовал разные - и sfp-forced с указанной явно скорость в 1G и sfp-preffered-auto.

 

Различные сочетания firmware коммутаторов доступа - не помогает (да и не в этом дело, в сети > 500 коммутаторов Edge-Core, но вот эта вот чертовщина только в данном месте).

На D-link также за крайние 2 месяца, как начались бессистемные падения - менял прошивки, результата видимого не принесло.

 

Причем. Могут работать 2-3 недели все коммутаторы без проблем.

Потом в какой-то момент - то ли скачок напряжения (по крайней мере, когда сам добирался до коммутаторов - uptime у них был равен времени "недоступности" в нашем Nagios. Т.е. электропитание на них точно пропадало). Но утверждать, что это случается только лишь с явным пропадаем электропитания - некорректно. Судя по логам на коммутаторе агрегации - не всегда падает линк перед тем, как коммутатор перестает работать корректно. Следовательно, делаю вывод, что скачок напряжения лишь служит иногда каким-то дополнительным импульсом, например.

 

Если в момент недоступности коммутаторов "пнуть" аггрегацию - результата положительно не наступает. Помогает ТОЛЬКО перезагрузка коммутаторов доступа.

Как уже выше писал - к установленным осенью прошлого года коммутаторам уже доставлены Edge-Core из других, более свежих партий - с ними такие же проблемы.

 

Не производилась замена только SFP-модулей. :) Но... Не могут же начать сбоить +/- единомоментно > 2х десятков пар sfp-модулей?!

 

Подскажите, могут ли подобные сбои, например, быть следствием проблем с энергетикой? Можно ли как-то их отловить, чтобы понимать наверняка, что в этом проблема?

Планируем расставить в наиболее часто отваливающихся местах по ИБП, посмотреть, поможет ли. Но...

 

Камрады, есть какие мысли, что еще может быть или как отловить эти моменты?

Share this post


Link to post
Share on other sites

Логи читали ? Даже у длинков они вполне вменяемы, а если и время по ntp засинхронить, то вообще хорошо.

Share this post


Link to post
Share on other sites

1. Управление коммутаторами в отдельном vlan?

2. Уровень влажности попробуйте замерить. Есть ли конденсат на стенках бокса? Абсорбирующие гранулы можно разместить в боксе и посмотреть.

Edited by xcme

Share this post


Link to post
Share on other sites

Логи читали ? Даже у длинков они вполне вменяемы, а если и время по ntp засинхронить, то вообще хорошо.

В логах D-linkа ничего интересного (или же еще что интересное по какому выводу можно посмотреть?):

DGS-3120-24SC:admin#show log
Command: show log

Index Date       Time     Level   Log Text
----- ---------- -------- ------- ----------------------------------------------
152   2015-03-02 10:30:28 INFO(6) Successful login through Telnet (Username: 
                                 admin, IP: 10.87.230.2)
151   2015-03-02 08:30:40 INFO(6) Port 1:15 link up, 1000Mbps FULL duplex
150   2015-03-02 08:29:34 INFO(6) Port 1:15 link down
149   2015-03-02 08:29:33 INFO(6) Port 1:15 link up, 1000Mbps FULL duplex
148   2015-03-02 08:29:31 INFO(6) Port 1:15 link down
147   2015-03-02 08:29:24 INFO(6) Port 1:15 link up, 1000Mbps FULL duplex
146   2015-03-02 08:28:50 INFO(6) Port 1:15 link down
145   2015-03-02 00:59:35 INFO(6) Logout through Telnet (Username: admin, IP
                                 : 10.87.230.2)

 

Месяц-дата не те, время совпадает (уже пофиксил все :)

Крайняя снизу запись - я логинился на Д-линк аггрегации, когда писал пост.

Линк даун - линк ап - это уже наши монтажники сегодня утром пинали "потерявшийся" коммутатор.

Сейчас - снова коммутатор отвалился, по логам, соответственно, доп. записей после того, как он утром поднялся - нет.

 

1. Управление коммутаторами в отдельном vlan?

2. Уровень влажности попробуйте замерить. Есть ли конденсат на стенках бокса? Абсорбирующие гранулы можно разместить в боксе и посмотреть.

1. Да, управление в отдельном vlan.

2. Конденсата на стенках нет это точно.

Edited by eepive

Share this post


Link to post
Share on other sites

Лупдетект на аггрегации включен? На магистральных портах эджкоров?

Замониторьте инпут брудкаст на портах аггрегации - нет ли скачков перед "отвалом" доступа?

 

Купите/возьмите на тест один длинк, например, DES-3200-* и замените один из регулярно-проблемных ёжиков; будут ли с длинком аналогичные проблемы?

Share this post


Link to post
Share on other sites

Лупдетект на аггрегации включен? На магистральных портах эджкоров?

Нигде не включал.

Замониторьте инпут брудкаст на портах аггрегации - нет ли скачков перед "отвалом" доступа?

Можете дать удочку подсказать, куда подглядеть, как это сделать? :)

 

Купите/возьмите на тест один длинк, например, DES-3200-* и замените один из регулярно-проблемных ёжиков; будут ли с длинком аналогичные проблемы?

Данный вариант продумываем.

Но, нюанс в том, что практически во всех шкафах на доступе уже доставили к первоначальным ежам - еще по ежику. Уже где-то и из других партий, а где-то и другие модели вовсе. Поначалу показалось, что действительно данная процедура помогла. Однако, сейчас снова все случайным образом ломается.

Share this post


Link to post
Share on other sites

Пальцем в небо: А прошивки обновлены до топовых?

Share this post


Link to post
Share on other sites

Лупдетект на аггрегации включен? На магистральных портах эджкоров?

Нигде не включал.

0_о и на клиентских портах тоже? Жесть, как у вас сеть-то ещё жива :)

 

Замониторьте инпут брудкаст на портах аггрегации - нет ли скачков перед "отвалом" доступа?

Можете дать удочку подсказать, куда подглядеть, как это сделать? :)

Cacti/Zabbix/Любая система мониторинга, ключ ifHCInBroadcastPkts.*

Share this post


Link to post
Share on other sites

Пальцем в небо: А прошивки обновлены до топовых?

И да и нет. На каких-то ежах сделал откат до "стоковой" (да, древняя), но как-то обновив все ежи до актуального состояния - свистопляска такая началась, что мама не горюй. При том, опять же, в других сегментах сети аналогичные Edge-Core у меня стоят с крайними или пред-крайними версиями и работают как часы.

D-link в агрегации в "топовой" прошивке, да.

 

0_о и на клиентских портах тоже? Жесть, как у вас сеть-то ещё жива :)

Читал всякие разные противоречивые вещи про лупдетекты. Ну и потому как все и без этого работала - не трогал. Как говорится - работает - не трогай. :)

Только что включил на всех интерфейсах D-link в агрегации.

На ежах доступа тоже по всем портам пройти и сделать enable?

 

Cacti/Zabbix/Любая система мониторинга, ключ ifHCInBroadcastPkts.*

Благодарю, понял.

В Cacti заправлю сейчас.

Share this post


Link to post
Share on other sites

Читал всякие разные противоречивые вещи про лупдетекты. Ну и потому как все и без этого работала - не трогал. Как говорится - работает - не трогай. :)

 

Ну вот просто ради интереса - интересно, как вы себе ситуацию представляете? :) Сгорел порт на свитче, или сетевуха у юзера. Петля во всём сегменте. Все свитчи недоступны, у l3-аггрегации рвёт крышу и CPU под 100%.

Лупдетект выключен, логов нет, ничего нет.

Ваши действия? :)

 

 

Только что включил на всех интерфейсах D-link в агрегации.

На ежах доступа тоже по всем портам пройти и сделать enable?

На доступе -- это вообще в первую очередь. Кроме того, желательно логи сливать куда-нибуть на syslog-сервер, парсить их чем-нибуть, и как-то уведомлять персонал о наличии петли.

У нас примерно так выглядит:

ao6Cej8.png

 

И так:

W1iRpFd.png

 

А вот на аггрегации - это обсуждаемо. У нас, например, магистральные порты не блокируются (лупдетект выключен), но мониторится брудкаст. При какой-нибуть мегапетле, которую не получается заблокировать акцесс-свитчу (да, и такое бывает ;( ) петлю можно найти по дикому количеству валящегося брудкаста.

 

 

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

Share this post


Link to post
Share on other sites

Ну вот просто ради интереса - интересно, как вы себе ситуацию представляете? :) Сгорел порт на свитче, или сетевуха у юзера. Петля во всём сегменте. Все свитчи недоступны, у l3-аггрегации рвёт крышу и CPU под 100%.

Лупдетект выключен, логов нет, ничего нет.

Ваши действия? :)

Не сталкивался. :)

 

Кроме того, желательно логи сливать куда-нибуть на syslog-сервер, парсить их чем-нибуть, и как-то уведомлять персонал о наличии петли.

Syslog-сервер настроен, логи сливаются, в логах ничего интересного по "падаемым" хостам не обнаружил.

 

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

Допускаю, но... черт побери. Во всем районе такой мистики нет, как в этом свежесданном ЖК. :) Безусловно, локальные проблемы есть и бывают всюду. Но не такая вереница не объясняемых вещей, как здесь. :)

Share this post


Link to post
Share on other sites

Немного не пойму, у вас и ежи и длинк зависают или только ежи?

Edited by xcme

Share this post


Link to post
Share on other sites

Немного не пойму, у вас и ежи и длинк зависают или только ежи?

Только ежи. Только в этом месте. Зависают - не совсем корректно, т.к. если консолью воткнуться в "зависший" еж, то проблем никаких "внешне" нет. Только не бегает трафик. Если воткнуться в транк медью, поднять IP в управляющем vlan, то на ICMP коммутатор не отвечает.

Если смотреть с консоли ежа, то на магистральных портах мак-адресов нет. В логах тоже ничего сверхъестественного.

Share this post


Link to post
Share on other sites
И да и нет. На каких-то ежах сделал откат до "стоковой" (да, древняя), но как-то обновив все ежи до актуального состояния - свистопляска такая началась, что мама не горюй.

А как выражалась эта самая "свистопляска" ? Что "плясало" то?

Share this post


Link to post
Share on other sites

Если до обновления сыпались периодически 1-2 коммутатора из 2-х десятков, то с актуальным ПО начали валиться все подряд. После пинка по питанию - через 40-60 минут снова все начинали сыпаться. Пришлось откатиться на стоковую, с ними кхм... Постабильней на столько, на сколько это уместно. Ежи - 3510-28, сток там 1.2.0.0 зашит.

обновлял, если что, как положено - через промежуточную прошивку бутлоадер, а после уже саму прошивку.

Share this post


Link to post
Share on other sites

Какой-нибуть "умный" функционал используется? dhcp-relay, igmp access authentication, etc.?

 

Я просто к тому, что можно попробовать по максимуму всё это поотключать. На одной из последних прошивок длинков, например, тоже были массовые зависания из-за igmp access_authentication

Share this post


Link to post
Share on other sites

пока не включите хотя бы loopdetect на агрегации - разговор не о чем.

Не удивлюсь, если на каком-нибуть порту под тысячу маков будет, самых разных...

Edited by m4a12345

Share this post


Link to post
Share on other sites

Какой-нибуть "умный" функционал используется? dhcp-relay, igmp access authentication, etc.?

 

Я просто к тому, что можно попробовать по максимуму всё это поотключать. На одной из последних прошивок длинков, например, тоже были массовые зависания из-за igmp access_authentication

 

Нет. Vlan на пользователя, мультикаст с igmp_snooping. Ничего более не испоьзуется в данном ЖК у клиентов.

 

пока не включите хотя бы loopdetect на агрегации - разговор не о чем.

Не удивлюсь, если на каком-нибуть порту под тысячу маков будет, самых разных...

 

Вот по рекомендации коллеги выше - сегодня включил на агрегации. Пока полет нормальный.

Share this post


Link to post
Share on other sites

Только что удалось кое-что "зацепить".

Один коммутатор лег, когда приехал, включился в него консолью, - увидел следующее в логах:

 

 

[490] 19:32:37 2015-07-11  "STA become new root bridge notification."  level : 6, module : 5, function : 1, and event no. : 1[489] 19:32:37 2015-07-11  "STA root bridge is changed to 32768.0.7072CFB21799."  level : 6, module : 5, function : 1, and event no. : 1

 

 

Время записи соответствует времени аларма в Nagios.

 

Подскажите, чем лечить?

 

Прописать bpdu-filter на всех клиентских портах? А что с магистральными?

Со стороны D-link'а что-то сделать можно? Избыточных петель в сети нет и быть не может, топология - классическая звезда.

Edited by eepive

Share this post


Link to post
Share on other sites

Отключайте везде STP, если у вас звезда

Share this post


Link to post
Share on other sites

Коллеги, может кто сталкивался с Edge-Core'ами,

достаточно ли в моем случае глобально сказать

no spanning-tree

?

Share this post


Link to post
Share on other sites

Только что удалось кое-что "зацепить".

Один коммутатор лег, когда приехал, включился в него консолью, - увидел следующее в логах:

 

 

[490] 19:32:37 2015-07-11  "STA become new root bridge notification."  level : 6, module : 5, function : 1, and event no. : 1[489] 19:32:37 2015-07-11  "STA root bridge is changed to 32768.0.7072CFB21799."  level : 6, module : 5, function : 1, and event no. : 1

 

 

Время записи соответствует времени аларма в Nagios.

 

Подскажите, чем лечить?

 

Прописать bpdu-filter на всех клиентских портах? А что с магистральными?

Со стороны D-link'а что-то сделать можно? Избыточных петель в сети нет и быть не может, топология - классическая звезда.

 

 

Вы STP используете? Если нет, то нахрен он вообще включен?

 

update: возможно, тут ваша история, особенно, если прошивки древние: http://www.vimcom.ru/support/index.php?showtopic=718

Edited by Wingman

Share this post


Link to post
Share on other sites

Вы STP используете? Если нет, то нахрен он вообще включен?

 

update: возможно, тут ваша история, особенно, если прошивки древние: http://www.vimcom.ru/support/index.php?showtopic=718

 

Глобально выпилил командой no spanning-tree на всех коммутаторах этот самый STP.

По ссылке - читал, со слов ТС у него проблема была в ином - "вообщем дело не в стп, а в связке dhcp-snooping +ipsg".

У нас подобное не используется.

 

Буду смотреть, помогло ли no spanning-tree.

Share this post


Link to post
Share on other sites

И лупдетект на доступе обязательно включите

Share this post


Link to post
Share on other sites

Нет. Vlan на пользователя, мультикаст с igmp_snooping. Ничего более не испоьзуется в данном ЖК у клиентов.

Кажется, это был огромный кабель камень в огород тех, кто вещает что vlan-per-customer решает многие проблемы by design. :)

 

p.s. Loopdetect на абонентских портах надо обязательно включать, только вот кольца в абонентских вланах к недоступности самого устройства привести не могут. Тут что-то другое, видимо.

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