Почему коммутатор периодически перестает отвечать?
Всем привет! Есть одна сеть на ~1500 MAC-ов. Больше чем на половину состоит из коммутаторов GS2210-24. Я пришел на эту сеть, то есть ее не строил, так что не прокомментирую ничего на этот счет. Сеть одна большая, практически не сегментирована, много броадкаста, но 1500 устройств не могут завалить даже такую сеть броадскастом. Периодически на всех коммутаторах Zyxel GS2210-24 одни и те же симптомы - коммутатор перестает отвечать по IP управления, а порой и нормально пропускать через себя траффик. Ошибок на портах нет, утилизация портов меньше 5 процентов. Все прочие проблемы были исключены (опитческие уровни, прошивки), никаких алгоритмов не настроено от слова совсем, они из коробки кроме IP. Если к "заболевшему" коммутатору подключиться консолью, то утилизация CPU достигает 20 процентов, что довольно много для такого количества устройств и сам он работает не то чтобы очень охотно. После сброса конфигурации и перезагрузки ему становится легче, утилизация падает до 5 процентов и какое-то время он работает, пока не отвалится вновь.
Пробовал прикинуть, что может иметь такой накопительный эффект. 1500 записей в FDB это не так много, количество броадкаста не критическое. У меня остается только косяк прошивки, переполняются какие-то буферы, кеши, или он захлебывается (в сети присутствует некоторое количество (немало) видеокамер, которые кроме того что льют видеопоток, еще активно шлют "непрошенные ARP" с пока неизвестной мне целью. Но коммутаторы умирают независимо от наличия на них или рядом видеокамер.
Подскажите, в каком направлении смотреть? Думаю в сторону cpu-protection или ограничения броадскаста на портах которые сильнее всего его генерируют, но может пострадать что-то критическое.
А нет ли в сети таких мест, где коммутаторы соединены по меди по клиентским портам? если есть - избавляйтесь от таких соединений, они вполне могут быть причиной тормозов.
Сколько всего коммутаторов в сети? Настроен ли STP, если да, то какой именно и как именно, кто-то настроен чтобы быть мастером, или как получится?
Какая максимальная длина сегмента от мастера в хопах? Какой вообще диаметр сети?
Используете ли VLAN, или все полторы тыщи узлов в дефолтном сегменте?
Думаю, тут надо проверять
- STP/RSTP (эти протоколы призваны устранять избыточные линки в сети, но могут и создавать проблемы, и их надо фильтровать на клиентских портах)
- loopback detection (если такой функционал есть в явном виде)
- конфликты mac- и ip-адресов
- возможную проблему с коллизиями мак-адресов, которой подвержены недорогие коммутаторы (https://habr.com/ru/articles/155265/)
В логах коммутаторов что-то есть в момент возникновения проблем?
Ну и на сети такого размера очень желательно вынести управление коммутаторами в отдельный влан.
Akina, есть места где коммутаторы уровня доступа соединены с распределением медью. Всего коммутаторов около 120. Никакие протоколы контроля топологии, лупбэков и тп не настроены. Топология звезда - в ядре один коммутатор. Максимальная длина сегмента в хопах - 6, но в среднем 3-4. Повторюсь, можно считать, что VLAN-ов нет, всё находится в одном 1 влане, вынесены отдельные устройства (станки) в VLAN, но это не больше 20 устройств. Сегментирования сети нет как явления. Остальное, включая камеры, в том же влане. Сейчас потихоньку выношу телефонию в отдельный влан. Опять же, никаких явных признаков, почему коммутаторы могут так себя вести не наблюдаю - нагрузка везде низкая, образование петель маловероятно, но всё же вероятно. Но ни в логах ни в повадках петли не проявляются.
Я знаю что это ужас, там еще много чего страшного, но пока добро на переработку не дали, надо как-то жить
Дмитрий, STP/RSTP отсутствуют, порты дергаются самостоятельно без них, loopback ничего не показал, да и маловероятно, но вероятно. Конфликты.... Везде есть DHCP, в целом сложно поймать конфликт, но я понаблюдаю отдельно. В логах все 10к записей забиты строками типа Link N UP/Link N Down. Системы нет, номера портов рандомны. Больше всего смущает подверженность проблеме одной конкретной модели... Сейчас потихоньку настраиваю SNMP traps, поднимаю Zabbix для этого (использовался ранее другой софт), но пока неясно, а решать надо прям вчера
Аналогичная трабла была и на других коммутаторах Zyxel и IP_DSLAM.
3. Проверьте как там состояние IGMP, мультикаст может преподнести горку сурпАЙзов.
2. В своё время для борьбы с похожими проблемами был написан скрипт, который тупо раз в неделю ребутил проблемные железяки -- как рукой сняло.
1. На многих зюхах конденсаторы (с которыми приходилось сталкиваться) стояли "не айс", как результат - через несколько лет эксплуатации труднообъяснимый фонтан капризов поведения, лечилось перепайкой кондеев.
asmelnik, 3 почти отсутствует. 2 как оперативное решение мной было предложено решение по ребуту раз в ночь, например, но пока серьезно не рассматривалось. 1 я в электронике совсем не совсем, поэтому тут что-то даже сложно сказать
Выбираем самый проблемный (субъективно).
Открываем и смотрим чисто визуально на конденсаторы (цилиндрики такие).
Если донышко (крышка? собственно лишь вопрос терминологии) выпуклая- писец котёночку (т.е. кондею)...
А не дай бог с трещинкой- счастье, что оно ещё хоть как-то фунциклирует.
asmelnik, да вот выделить "особо проблемный" не получится - они все проблемные попеременно, так что как будто имеет место быть действительно коллизии.... Но какой-нибудь осмотрю, конечно, на всякий. Спасибо)
есть места где коммутаторы уровня доступа соединены с распределением медью.
Просто медь - похрен. А вот транк или магистраль через клиентский порт - это натуральная засада. В отличие от транковых портов, клиентские шарятся на модуле с другими клиентами.
Сейчас потихоньку выношу телефонию в отдельный влан.
А что, коммутаторы Voice VLAN не поддерживают, что ли?
В логах все 10к записей забиты строками типа Link N UP/Link N Down.
Это включение-выключение клиентских компьютеров.
хорошая теория про коллизии, надо изучить и найти способ проверить свои коммутаторы на подверженность болячке
Раз в минуту скрипт, который пингает все коммутаторы (-w 100 -n 2), после чего сливает в файл arp -a. Накопить такой хрени за недельку, а потом обработать на предмет коллизий.
Akina, voice vlan делать запретили, а так как op телефоны умеют работать с тегом, то особой разницы между voice clan и бросанием тега в телефон не вижу. Приоритезацией траффика VV все равно не занимается (вроде).
Про включение выключение клиентов - это не так. Порты дергаются десятки раз в минуту
особой разницы между voice clan и бросанием тега в телефон не вижу.
Это хорошо, если у тебя народ не бродит.
Порты дергаются десятки раз в минуту
А если идёт мерцание порта, то это почти наверняка коммуникация говно. Причём в любом месте - от ламелек на сетевухе и до ламелек в разъёме коммутатора. Окислившиеся или окривевшие контакты, передавленный патч, крутой перегиб на кабеле и пр. Реже - длинные сегменты. И уж совсем редко - проблема за пределами СКС.
Mors Clamor,
Если порты часто дергаются-
Смотрите в сторону качества самого кабеля и уровня помех в нем.
Найдите контору с нормальным диагностическим железом.
Чтоб именно меряло соответствие кабеля категории 5е и 6.
С уровнями шумов и т.д.
Очень похоже на дикое количество наводок меди.
На одной фабрике сеть проложена была рядом с силовыми для технологического оборудования.
Всего 10 метров на расстоянии 10см от силовых.(За гипсокартонной перегородкой)
Пуск каждой установки клал сеть.
Akina, hint000, asmelnik, Дмитрий, хм, слишком массовая проблема для простых перегибов и окислений, а вот наводки.... Аналоговая телефония, которой здесь подавляющее большинство проходит ровненько параллельно с силовыми 220 и 340), однако, никогда не испытывала от это этого проблем. А так как кабель каналы одни, то и сети (до абонентов во всяком случае) проходят там же.... И когда я трассировал UTP то я слышал то самое "рычание". Однако на стороне абонентов никто еще не жаловался. Выясню, как именно проходят коммуникации в проблемных случаях, спасибо за наводку (хд). Вчера посмотрел при повторении такого поведения, на порт летят около 10к за несколько секунд. Смотрел магистральный порт оконечного коммутатора (аплинк), подозрительно большое количество,
Mors Clamor, ты сам ответил на вопросы: любые 1500 хостов (особенно камеры) легко завалят сеть в одном броадкасте, тем более при внешних помехах, даже не нужно всю сеть - достаточно аплинков в сторону ядра или процы на свичах.
Если добро не дали на всю сеть, сделай минимум для себя: выдели отдельный влан только под управление свичами, многие модели почему то не делают приоритет на свой трафик управления в общем потоке.
Соседи (но настраивать пришлось мне) купили несколько Zyxel, в том числе пару XGS2210-28 и более старые модели, они на мой взгляд все глючные, XGS4700-48F пролежав без работы года три - вообще просто помер, после двух лет не интенсивной работы. Аналоговая телефония, там частоты много меньше, поэтому не показатель.
В телефонии используется полоса частот от 300 Гц до 3400 Гц
Так что наводка 50 Гц может гулять по телефонным кабелям, но если в телефонных аппаратах встроены фильтры, пропускающие 300..3400 Гц, то 50 Гц в телефонную трубку "¡No pasarán!".
Наблюдал сеть, в которой виндовый админ мудро отключил STP. Отключил он этот протокол потому, что у него из-за STP машины не успевали получать адреса по DHCP. Так вот, в той сети после каждого шторма коммутаторы тоже уходили в себя и переставали откликаться на телнет, а штормы с отключенным STP, само собой, происходили регулярно.
Лично наблюдал, как пользователь обнаружил свободно лежащий на полу сетевой патчкорд и, недолго думая, тут же воткнул его в ближайшую свободную розетку, организовав петлю и устроив, тем самым, шторм. Коммутаторы в той сети, правда, были нортелы, а не зухели.
Средний
