eepive Опубликовано 10 июля, 2015 · Жалоба Коллеги, приветствую! Ситуация следующая: С августа-сентября прошлого года подключен новый район к сегменту нашей сети. Дома - новостройки. Размещено все оборудование в подвале, где круглогодично присутствует вода - от просто влажно до без сапог не пройти (специально обращаю на это внимание, возможно важность данного момента мной недооценена). Оборудование размещено в антивандальных шкафах Е-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-модулей?! Подскажите, могут ли подобные сбои, например, быть следствием проблем с энергетикой? Можно ли как-то их отловить, чтобы понимать наверняка, что в этом проблема? Планируем расставить в наиболее часто отваливающихся местах по ИБП, посмотреть, поможет ли. Но... Камрады, есть какие мысли, что еще может быть или как отловить эти моменты? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
YuryD Опубликовано 10 июля, 2015 · Жалоба Логи читали ? Даже у длинков они вполне вменяемы, а если и время по ntp засинхронить, то вообще хорошо. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
xcme Опубликовано 11 июля, 2015 (изменено) · Жалоба 1. Управление коммутаторами в отдельном vlan? 2. Уровень влажности попробуйте замерить. Есть ли конденсат на стенках бокса? Абсорбирующие гранулы можно разместить в боксе и посмотреть. Изменено 11 июля, 2015 пользователем xcme Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
eepive Опубликовано 11 июля, 2015 (изменено) · Жалоба Логи читали ? Даже у длинков они вполне вменяемы, а если и время по 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. Конденсата на стенках нет это точно. Изменено 11 июля, 2015 пользователем eepive Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Wingman Опубликовано 11 июля, 2015 · Жалоба Лупдетект на аггрегации включен? На магистральных портах эджкоров? Замониторьте инпут брудкаст на портах аггрегации - нет ли скачков перед "отвалом" доступа? Купите/возьмите на тест один длинк, например, DES-3200-* и замените один из регулярно-проблемных ёжиков; будут ли с длинком аналогичные проблемы? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
eepive Опубликовано 11 июля, 2015 · Жалоба Лупдетект на аггрегации включен? На магистральных портах эджкоров? Нигде не включал. Замониторьте инпут брудкаст на портах аггрегации - нет ли скачков перед "отвалом" доступа? Можете дать удочку подсказать, куда подглядеть, как это сделать? :) Купите/возьмите на тест один длинк, например, DES-3200-* и замените один из регулярно-проблемных ёжиков; будут ли с длинком аналогичные проблемы? Данный вариант продумываем. Но, нюанс в том, что практически во всех шкафах на доступе уже доставили к первоначальным ежам - еще по ежику. Уже где-то и из других партий, а где-то и другие модели вовсе. Поначалу показалось, что действительно данная процедура помогла. Однако, сейчас снова все случайным образом ломается. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sol Опубликовано 11 июля, 2015 · Жалоба Пальцем в небо: А прошивки обновлены до топовых? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Wingman Опубликовано 11 июля, 2015 · Жалоба Лупдетект на аггрегации включен? На магистральных портах эджкоров? Нигде не включал. 0_о и на клиентских портах тоже? Жесть, как у вас сеть-то ещё жива :) Замониторьте инпут брудкаст на портах аггрегации - нет ли скачков перед "отвалом" доступа? Можете дать удочку подсказать, куда подглядеть, как это сделать? :) Cacti/Zabbix/Любая система мониторинга, ключ ifHCInBroadcastPkts.* Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
eepive Опубликовано 11 июля, 2015 · Жалоба Пальцем в небо: А прошивки обновлены до топовых? И да и нет. На каких-то ежах сделал откат до "стоковой" (да, древняя), но как-то обновив все ежи до актуального состояния - свистопляска такая началась, что мама не горюй. При том, опять же, в других сегментах сети аналогичные Edge-Core у меня стоят с крайними или пред-крайними версиями и работают как часы. D-link в агрегации в "топовой" прошивке, да. 0_о и на клиентских портах тоже? Жесть, как у вас сеть-то ещё жива :) Читал всякие разные противоречивые вещи про лупдетекты. Ну и потому как все и без этого работала - не трогал. Как говорится - работает - не трогай. :) Только что включил на всех интерфейсах D-link в агрегации. На ежах доступа тоже по всем портам пройти и сделать enable? Cacti/Zabbix/Любая система мониторинга, ключ ifHCInBroadcastPkts.* Благодарю, понял. В Cacti заправлю сейчас. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Wingman Опубликовано 11 июля, 2015 · Жалоба Читал всякие разные противоречивые вещи про лупдетекты. Ну и потому как все и без этого работала - не трогал. Как говорится - работает - не трогай. :) Ну вот просто ради интереса - интересно, как вы себе ситуацию представляете? :) Сгорел порт на свитче, или сетевуха у юзера. Петля во всём сегменте. Все свитчи недоступны, у l3-аггрегации рвёт крышу и CPU под 100%. Лупдетект выключен, логов нет, ничего нет. Ваши действия? :) Только что включил на всех интерфейсах D-link в агрегации. На ежах доступа тоже по всем портам пройти и сделать enable? На доступе -- это вообще в первую очередь. Кроме того, желательно логи сливать куда-нибуть на syslog-сервер, парсить их чем-нибуть, и как-то уведомлять персонал о наличии петли. У нас примерно так выглядит: И так: А вот на аггрегации - это обсуждаемо. У нас, например, магистральные порты не блокируются (лупдетект выключен), но мониторится брудкаст. При какой-нибуть мегапетле, которую не получается заблокировать акцесс-свитчу (да, и такое бывает ;( ) петлю можно найти по дикому количеству валящегося брудкаста. У вас, кстати, не обязательно петля ведь. Могут быть брудкаст-штормы, мультикаст-штормы, dhcp-штормы, если на свитчах включен релей, например. Да любой трафик, попадающий на проц свитча в больших количествах, может его положить. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
eepive Опубликовано 11 июля, 2015 · Жалоба Ну вот просто ради интереса - интересно, как вы себе ситуацию представляете? :) Сгорел порт на свитче, или сетевуха у юзера. Петля во всём сегменте. Все свитчи недоступны, у l3-аггрегации рвёт крышу и CPU под 100%. Лупдетект выключен, логов нет, ничего нет. Ваши действия? :) Не сталкивался. :) Кроме того, желательно логи сливать куда-нибуть на syslog-сервер, парсить их чем-нибуть, и как-то уведомлять персонал о наличии петли. Syslog-сервер настроен, логи сливаются, в логах ничего интересного по "падаемым" хостам не обнаружил. У вас, кстати, не обязательно петля ведь. Могут быть брудкаст-штормы, мультикаст-штормы, dhcp-штормы, если на свитчах включен релей, например. Да любой трафик, попадающий на проц свитча в больших количествах, может его положить. Допускаю, но... черт побери. Во всем районе такой мистики нет, как в этом свежесданном ЖК. :) Безусловно, локальные проблемы есть и бывают всюду. Но не такая вереница не объясняемых вещей, как здесь. :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
xcme Опубликовано 11 июля, 2015 (изменено) · Жалоба Немного не пойму, у вас и ежи и длинк зависают или только ежи? Изменено 11 июля, 2015 пользователем xcme Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
eepive Опубликовано 11 июля, 2015 · Жалоба Немного не пойму, у вас и ежи и длинк зависают или только ежи? Только ежи. Только в этом месте. Зависают - не совсем корректно, т.к. если консолью воткнуться в "зависший" еж, то проблем никаких "внешне" нет. Только не бегает трафик. Если воткнуться в транк медью, поднять IP в управляющем vlan, то на ICMP коммутатор не отвечает. Если смотреть с консоли ежа, то на магистральных портах мак-адресов нет. В логах тоже ничего сверхъестественного. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sol Опубликовано 11 июля, 2015 · Жалоба И да и нет. На каких-то ежах сделал откат до "стоковой" (да, древняя), но как-то обновив все ежи до актуального состояния - свистопляска такая началась, что мама не горюй. А как выражалась эта самая "свистопляска" ? Что "плясало" то? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
eepive Опубликовано 11 июля, 2015 · Жалоба Если до обновления сыпались периодически 1-2 коммутатора из 2-х десятков, то с актуальным ПО начали валиться все подряд. После пинка по питанию - через 40-60 минут снова все начинали сыпаться. Пришлось откатиться на стоковую, с ними кхм... Постабильней на столько, на сколько это уместно. Ежи - 3510-28, сток там 1.2.0.0 зашит. обновлял, если что, как положено - через промежуточную прошивку бутлоадер, а после уже саму прошивку. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Wingman Опубликовано 11 июля, 2015 · Жалоба Какой-нибуть "умный" функционал используется? dhcp-relay, igmp access authentication, etc.? Я просто к тому, что можно попробовать по максимуму всё это поотключать. На одной из последних прошивок длинков, например, тоже были массовые зависания из-за igmp access_authentication Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
m4a12345 Опубликовано 11 июля, 2015 (изменено) · Жалоба пока не включите хотя бы loopdetect на агрегации - разговор не о чем. Не удивлюсь, если на каком-нибуть порту под тысячу маков будет, самых разных... Изменено 11 июля, 2015 пользователем m4a12345 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
eepive Опубликовано 11 июля, 2015 · Жалоба Какой-нибуть "умный" функционал используется? dhcp-relay, igmp access authentication, etc.? Я просто к тому, что можно попробовать по максимуму всё это поотключать. На одной из последних прошивок длинков, например, тоже были массовые зависания из-за igmp access_authentication Нет. Vlan на пользователя, мультикаст с igmp_snooping. Ничего более не испоьзуется в данном ЖК у клиентов. пока не включите хотя бы loopdetect на агрегации - разговор не о чем. Не удивлюсь, если на каком-нибуть порту под тысячу маков будет, самых разных... Вот по рекомендации коллеги выше - сегодня включил на агрегации. Пока полет нормальный. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
eepive Опубликовано 11 июля, 2015 (изменено) · Жалоба Только что удалось кое-что "зацепить". Один коммутатор лег, когда приехал, включился в него консолью, - увидел следующее в логах: [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'а что-то сделать можно? Избыточных петель в сети нет и быть не может, топология - классическая звезда. Изменено 11 июля, 2015 пользователем eepive Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
EShirokiy Опубликовано 11 июля, 2015 · Жалоба Отключайте везде STP, если у вас звезда Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
eepive Опубликовано 11 июля, 2015 · Жалоба Коллеги, может кто сталкивался с Edge-Core'ами, достаточно ли в моем случае глобально сказать no spanning-tree ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Wingman Опубликовано 11 июля, 2015 (изменено) · Жалоба Только что удалось кое-что "зацепить". Один коммутатор лег, когда приехал, включился в него консолью, - увидел следующее в логах: [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 Изменено 11 июля, 2015 пользователем Wingman Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
eepive Опубликовано 11 июля, 2015 · Жалоба Вы STP используете? Если нет, то нахрен он вообще включен? update: возможно, тут ваша история, особенно, если прошивки древние: http://www.vimcom.ru/support/index.php?showtopic=718 Глобально выпилил командой no spanning-tree на всех коммутаторах этот самый STP. По ссылке - читал, со слов ТС у него проблема была в ином - "вообщем дело не в стп, а в связке dhcp-snooping +ipsg". У нас подобное не используется. Буду смотреть, помогло ли no spanning-tree. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
EShirokiy Опубликовано 12 июля, 2015 · Жалоба И лупдетект на доступе обязательно включите Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
xcme Опубликовано 12 июля, 2015 · Жалоба Нет. Vlan на пользователя, мультикаст с igmp_snooping. Ничего более не испоьзуется в данном ЖК у клиентов. Кажется, это был огромный кабель камень в огород тех, кто вещает что vlan-per-customer решает многие проблемы by design. :) p.s. Loopdetect на абонентских портах надо обязательно включать, только вот кольца в абонентских вланах к недоступности самого устройства привести не могут. Тут что-то другое, видимо. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...