Странное поведение сегмента сети ПД,

[eepive]

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

 

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

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

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

Оборудование размещено в антивандальных шкафах Е-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-модулей?!

 

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

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

 

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

[YuryD]

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

[xcme]

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

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

Edited July 11, 2015 by xcme

[eepive]

Логи читали ? Даже у длинков они вполне вменяемы, а если и время по 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 July 11, 2015 by eepive

[Wingman]

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

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

 

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

[eepive]

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

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

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

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

 

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

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

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

[sol]

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

[Wingman]

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

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

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

 

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

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

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

[eepive]

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

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

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

 

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

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

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

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

 

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

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

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

[Wingman]

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

 

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

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

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

 

 

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

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

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

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

 

И так:

 

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

 

 

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

[eepive]

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

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

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

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

 

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

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

 

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

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

[xcme]

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

Edited July 11, 2015 by xcme

[eepive]

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

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

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

[sol]

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

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

[eepive]

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

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

[Wingman]

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

 

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

[m4a12345]

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

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

Edited July 11, 2015 by m4a12345

[eepive]

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

 

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

 

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

 

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

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

 

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

[eepive]

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

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

 

 

[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 July 11, 2015 by eepive

[EShirokiy]

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

[eepive]

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

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

no spanning-tree

?

[Wingman]

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

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

 

 

[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 July 11, 2015 by Wingman

[eepive]

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

 

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

 

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

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

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

 

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

[EShirokiy]

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

[xcme]

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

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

 

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