Есть средних размеров городская сеть. Схема: узел агрегации L3 на квартал. В качестве абонентских используются L2 3026 (прошивка 4.01.B19, поднят Storm Control на broadcast). Переодически (от суток до 5 дней) виснут коммутаторы на фиксированных адресах, по данным мониторинга. При этом они продолжают пропускать через себя пакеты. Попытки подцепиться консолью успехом не увенчались (интересно, что свич XP определяет как трекбол для com-порта), syslog ничего необычного перед зависанием не дает. Замена на гарантированно рабочий свитч и установка бесперебойника эффекта не дала.
А потому задаю здесь вопрос: это чем-нибудь лечится или, по крайней мере, известна ли причина подобного поведения свичей?

_________________
Сеть огромна, друг мой Бато.

У Вас управление в отдельном VLAN-е?

Нет, до узла агрегации есть единый для коммутаторов и абонентов vlan, за интерфейсом узла агрегации для магистральных каналов идут уже свои vlan'ы и диапазон адресов. На коммутаторах поднят trusted host и авторизация на порту (802.1x) для абонентских портов, а потому угрозы для безопасноти нет.

_________________
Сеть огромна, друг мой Бато.

Угроза всё равно есть. Желательно всё таки вынести управление в отдельный VLAN хотя бы в одном сегменте для проверки. Перезвоните пожалуйста в понедельник в офис по телефону +7(495)744-00-99 доб.390 или укажите Ваш телефон. Прошивка у вас скорее всего 4.01.09.

Попробуем. Но исключительно для справки, подобные симптомы встречаются впервые или уже были прецеденты (удивило меня то, что он продолжает пропускать пакеты, по сути превращаясь в хаб).

_________________
Сеть огромна, друг мой Бато.

Нет такого не было. По сути он может стать как хаб только в случае переполнения таблицы FDB. Может быть Вы имели ввиду неуправляемый свитч?

Да, именно. Извиняюсь за неточность.

_________________
Сеть огромна, друг мой Бато.

Когда DES-3026 зависает, то логика перестает работать (ни IPMACBINDING не работает ни CLI), но голые пакеты L2 при этом ходят без проблем. У меня такое было на старых прошивках, а в сериях 4.00.005 и 4.01.016 такого не встричаеться вообще. Большенство давно поставленных свичей находиться в одном же с пользователями вилане (так сложилось исторически), но проблем нет.

Ипользуеться LBD, TrustedHost, Traffic Control, IMB, QoS (редко), Port Sequrety (редко), управление через SNMP.

_________________
WBR. Sp!ZER

Проблема с зависанием des-3026 есть на самом деле. У нас на сети установлено их более 200 штук. Проблема связано с инженерным просчётом в реализации подвода провода заземления (относительно высокое сопротивление участка "коммутатор-общая шина заземления" при использовании бытового шнура с третьим проводом заземления). Поэтому заземление на узле и металлосвязь мкжду всеми устройствами узла должны быть очень хорошего качества. На тех де узлах ставим cisco 29xx, 35xx, 37xx -- никаких проблем. После проведения работ по улучшению показателей металлосвязи и заземления зависания прекратились. Должны быть оптимизированны ОБА параметра! Как показала практика, что-то лепить к корпусу коммутатора -- бесполезно.

Мне интересно а какая аппартаная версия коммутатора? И какие функции этого девайса вы используете? У нас таких коммутаторов намного больше чем у Вас, и никогда именно с этой моделью проблем небыло. В большенстве случаев DES-3026 подключены от UPS-BACK фирмы APC и имеют версию прошивки 4.01.016.

ИМХО все коммутационное оборудование должно бытьподключено от UPS.

_________________
WBR. Sp!ZER

Аппаратная версия -- A3. Версия f/w не имеет никакого значения (пробовались 3.00.26, 3.00.36, 3.00.53, 4.xx.xx). Корелляция 100%качеством заземления и металлосвязи с остальным оборудованием узла. Все устроства имеют единообразный конфиг, на всех устройствах занято от 4 до 7 портов, все устройства подключенные к des'ам 100% идентичны. Используется как L2 клммутатор уровня доступа (собственно коммутация, использование vlan'ов, ну и мониторинг по snmp).

На всех узлах, где привели к нормам заземление (то есть, не более 3 ом для контура) и металлосвязь (то есть, третий провод заземления des'а сразу на общую шину заземления выведен, все подключенные устройства -- аналогично, но там проблемы нет -- у всех есть внешний винт для земли), проблема с зависанием исчезла как класс. В качестве приборов заземления (там где возникли проблемы) используем системы глубинного и протяжённого заземления Galmar серии "GL".

По питанию: на всех узлах используются промышленные системы питания компании Efore (Epos Compact, 5 кВт, время автонмной работы от батарей -- 48 часов, гальваническая развязка с первичной сетью питания, промышленные инверторы -- Power Innovation INVx в режиме инвертора, bypass НЕ ИСПОЛЬЗУЕТСЯ). То есть устройство des всегда работает от вторичного источника тока.

У меня встречнй вопрос: "проблем не было" -- за какой промежуток времени? Если устройство начинает виснуть хотя бы раз в пол-года -- это уже проблема, не говоря про меньшие сроки.

P.S. У нас почти все узлы -- необслуживаемые, а там где стоят des'ы -- 100% (так как это очень маленькие узлы). Администрятся и настраиваются все узлы только удалённо. Поэтому ездить раз в квартал и перезагружать коммутатор -- очень накладно.

Третий релиз не помню какая точно прошивка и 4.00.08 у меня зависали. Свичи DES-3026 с 3.00.53 и 4.01.016 вобще работают годами.

Я использую Traffic Control, Looopback, Vlan, Агрегацию портов, IMB управление по SNMP, STP, Мультикаст, другими словами 80% функционала коммутатора. Все коммутаторы на уровне доступа имеют одну версию прошивки, управление в отделном вилане (хотя и это не обязательно. по опыту этот коммутатор ни каким флудом не завалить).

Аппаратные версии A1,A2,А3. Нареканий нет.

_________________
WBR. Sp!ZER

Разумеется, что управление у нас тоже в отдельном VLAN'е, равно как и какждый пользователь в своём vlan'e. Поскольку это уровень доступа, то остальные функции нам не нужны. Если посмотреть на графики щагрузки cpu за весь промежуток времени работы этих коммутаторов у нас на сети, то загрузка CPU равна нулю, то есть зависают они не "под нагрузкой непомерной".

Но это всё детали. Главное, что проблема очевидна и нам не пришлось долго выяснять, в чём же дело. Да и решается она очевидным способом. Жаль, что такую мелочь разработчики сразу не учли. Как ни странно, старые cisco 3550 и 2950 в тех же местах не виснут (пока не разобрались в чём дело, просто ставили вместо 3026 старье со склада и оно работает там и по сей день).

Есть правда плюс -- у3026 виснет похоже только nms, а swich factory продолжает работать, соответственно, если конфигурация узла не меняется, то в экстренном порядке куда то выезжать резона нет.

Перезвоните пожалуйста в офис по телефону 744-00-99 доб.390 или укажите ваш телефон.