Перейти к содержимому
Калькуляторы

странный вис коммутаторов

Завелся пару месяцев назад в одном из домов барабашка...

Проявляется это в виде странных глюков у коммутаторов. Изначально стоял компекс 2216, затем multico 16 портовый и в настоящий момент -16 портовый SNR-S1916-1S с оптический выходом

 

Вешаются свитчики эпизодически, могут на несколько часов по нескольку дней подряд зависать, могут пару недель отработать без сбоев. Подключался напрямую к коммутатору и смотрел Ethereal'ом бегают только арпы, причем с нормальной частотой, долбежки ни с одного из маков нет, всего около 6-10 пакетов в секунду... но... этот вешающийся свитч подключен к длинку des-3228F и на его мониторилке порта вырисовывается следующая картинка - 256 пакетов в секунду (сканер их почему то не показал) и поток в 16500 в среднем, плюс минус 5 пакетов.

 

передергивание абонентских линий к разумным результатам не привело, в первый раз вылечилось отключением порта 3, второй раз порта 7, в третий раз порта 1... поход к абонентам на этих портах ничего не дал, сканер подключенный напрямую к компам опять ничего не показал, точнее ничего необычного, антивирусы у всех стоят, у двух дрвэб, у одного каспер, все с актуальными базами.

куда копать, может кто сталкивался, напрягает расхождения в показаниях сканера и монитора на длинке, что за пакеты или фрагменты которые не отображает этериал и видит длинк..

еще момент.. когда коммутатор на проблемном доме был подключен к длинку des-1024dg у последнего тоже вешалась часть портов, аналогично вел себя des-3026.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Глупый вопрос. А с питанием там точно все как надо?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Глупый вопрос. А с питанием там точно все как надо?

 

с самого начала полтергейста проверил питание.., поменял блоки, поменял 4 коммутатора разных производителей, все одинаково, с 220 видимых проблем нет, в той же розетке воткнут вайфай, он работает без проблем.

да, если бы проблемы с питанием были, то глюки исчезали бы после передергивания питания, собственно они и исчезают, после автодиагностики портов всё работает ровно 5 секунд, потом проблема снова проявляется... и проблема исчезеает спонтанно, без передёргиваний питания.

Изменено пользователем sheft

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Так и хочется сказать што броудкаст шторм, но трафика и пакетов нету. Аль мож спанингтри блокирует там уплинк?

А подключившись к свитчу можете клиентов пропинговать?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Так и хочется сказать што броудкаст шторм, но трафика и пакетов нету. Аль мож спанингтри блокирует там уплинк?

А подключившись к свитчу можете клиентов пропинговать?

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

 

 

управление в отдельном влане ?

вланы не используются

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

управление в отдельном влане ?

вланы не используются

 

Очень зря. Отсутствие отдельного management vlan может приводить к значительной нагрузке на cpu, что в свою очередь запросто может приводить к зависаниям.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

вланы не используются

тут ничего нет кроме арпов

...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

управление в отдельном влане ?

вланы не используются

 

Очень зря. Отсутствие отдельного management vlan может приводить к значительной нагрузке на cpu, что в свою очередь запросто может приводить к зависаниям.

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Статика или вч с кабелей.

нет, иначе как объяснить зависание следующего в линии коммутатора des-1024 и des-3026 и не зависание des-2328f

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Вешаются свитчики эпизодически, могут на несколько часов по нескольку дней подряд зависать,

Как то было, физически абонентские порты (светодиоды) горят, даже подмаргивают, а логика не идет (свитч полностью недоступен). На SFP порту, светодиод горит, и не моргает.

Рестарт, помогает. Может на 2 часа, может на неделю.

Выяснилось, влияет температура. Причиной оказался SFP. Может не снес "чердачной" температуры, и в нем че то поплыло.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Если Management-VLAN отсутствует на проблемном участке - участок будет проблемным всегда, как бы вы не извращались с электропитанием и заменой свичей.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Вешаются свитчики эпизодически, могут на несколько часов по нескольку дней подряд зависать,

Как то было, физически абонентские порты (светодиоды) горят, даже подмаргивают, а логика не идет (свитч полностью недоступен). На SFP порту, светодиод горит, и не моргает.

Рестарт, помогает. Может на 2 часа, может на неделю.

Выяснилось, влияет температура. Причиной оказался SFP. Может не снес "чердачной" температуры, и в нем че то поплыло.

 

да, sfpшки греются, но проблема не в нем, иначе по медным портам бы всё бегало в пределах коммутатора.. да собственно и предыдущие виснувшие компекс и мультик без sfp были, только медные порты.

 

Если Management-VLAN отсутствует на проблемном участке - участок будет проблемным всегда, как бы вы не извращались с электропитанием и заменой свичей.

не понимаю причем тут это... свитчи неуправляемые

да и управляющий влан насколько я знаю предназначен для исключения проблем с доступом на коммутатор при перегрузке последнего флудом и прочим

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

не понимаю причем тут это... свитчи неуправляемые

Вы можете на проблемном участке заменить все тупари на управляемые свичи (используя management vlan)? Или проще сидеть и гадать, почему-же виснут тупари?

да и управляющий влан насколько я знаю предназначен для исключения проблем с доступом на коммутатор при перегрузке последнего флудом и прочим

сделайте то, что я советую, и всё сразу прояснится.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Вы провода случаем рядом с силовым кабелем не проложили?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Завелся пару месяцев назад в одном из домов барабашка...

Проявляется это в виде странных глюков у коммутаторов. Изначально стоял компекс 2216, затем multico 16 портовый и в настоящий момент -16 портовый SNR-S1916-1S с оптический выходом

 

Вешаются свитчики эпизодически, могут на несколько часов по нескольку дней подряд зависать, могут пару недель отработать без сбоев. Подключался напрямую к коммутатору и смотрел Ethereal'ом бегают только арпы, причем с нормальной частотой, долбежки ни с одного из маков нет, всего около 6-10 пакетов в секунду... но... этот вешающийся свитч подключен к длинку des-3228F и на его мониторилке порта вырисовывается следующая картинка - 256 пакетов в секунду (сканер их почему то не показал) и поток в 16500 в среднем, плюс минус 5 пакетов.

 

передергивание абонентских линий к разумным результатам не привело, в первый раз вылечилось отключением порта 3, второй раз порта 7, в третий раз порта 1... поход к абонентам на этих портах ничего не дал, сканер подключенный напрямую к компам опять ничего не показал, точнее ничего необычного, антивирусы у всех стоят, у двух дрвэб, у одного каспер, все с актуальными базами.

куда копать, может кто сталкивался, напрягает расхождения в показаниях сканера и монитора на длинке, что за пакеты или фрагменты которые не отображает этериал и видит длинк..

еще момент.. когда коммутатор на проблемном доме был подключен к длинку des-1024dg у последнего тоже вешалась часть портов, аналогично вел себя des-3026.

 

У Вас не в доме барабашка, а в сети в целом. Вы к свитчу подключаетесь и не видите 16,5Kpps - откуда Вы их там должны увидеть? Свитч свитчует, он не броадкастит. Рискну предположить, что 16 Kpps это предел неуправляхи (не уверен, только так думаю). Следовательно, Вам путь подсказали правильный - ставить управляемые свитчи и мониторить, у кого сколько пакетов вылетело и сколько влетело.

Вы таки не сказали, внутри одного свитча Вы видите ARP, значит попробуйте сделать arping на этой неуправляхе в момент "виса", я думаю ничего не увидите или с большими потерями. Скорее всего у нее мозги в этот момент дохнут от избытка траффика. Мб кстати петля.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

У Вас не в доме барабашка, а в сети в целом. Вы к свитчу подключаетесь и не видите 16,5Kpps - откуда Вы их там должны увидеть? Свитч свитчует, он не броадкастит. Рискну предположить, что 16 Kpps это предел неуправляхи (не уверен, только так думаю). Следовательно, Вам путь подсказали правильный - ставить управляемые свитчи и мониторить, у кого сколько пакетов вылетело и сколько влетело.

Вы таки не сказали, внутри одного свитча Вы видите ARP, значит попробуйте сделать arping на этой неуправляхе в момент "виса", я думаю ничего не увидите или с большими потерями. Скорее всего у нее мозги в этот момент дохнут от избытка траффика. Мб кстати петля.

не 16кппс а 16кбит. таки в момент виса он и не свитчует, про предел неуправляхи это домыслы, по паспорту сегодня предел сотнями тысяч ппс измеряются, арпы я смотрел как раз в момент виса.. петля тоже отменяется, с этим сталкивался и сканер это вполне явно показывает дублетами и триплетами одинаковых пакетов идущих друг за другом или с некоторым отставанием.

Изменено пользователем sheft

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Во первых, рекомендую сменить эториал на более свежую версию Wireshark (тоже самое только поновее да почувствительнее). Во вторых, не понятна технология тестирования, какие пакеты сыплються на длинке? какие маки светяться? маки с базой сверяли? где ещё такие пакеты бывают? откуда такая уверенность что нет кольца? (то что типа отсутствуют дуплеты и триплеты это не показатель). Инет как раздаете, PPPOE? или ещё как то? конечно лучше поставить Л2 на проблемный участок чтоб лучше мониторить, хотя бы временно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Во первых, рекомендую сменить эториал на более свежую версию Wireshark (тоже самое только поновее да почувствительнее). Во вторых, не понятна технология тестирования, какие пакеты сыплються на длинке? какие маки светяться? маки с базой сверяли? где ещё такие пакеты бывают? откуда такая уверенность что нет кольца? (то что типа отсутствуют дуплеты и триплеты это не показатель). Инет как раздаете, PPPOE? или ещё как то? конечно лучше поставить Л2 на проблемный участок чтоб лучше мониторить, хотя бы временно.

 

ок, wireshark попробую. Маки светятся клиентские, зарегистрированные в базе, левых маков и арп-флуда нет.. с кольцом приходилось несколько раз сталкиваться, симптомы и трафик в сканере совершенно другие. Инет раздается по голому эзернету, туннели не используются.

 

Сегодня аналогичная картина на другом доме, где раньше подобного не было.

Хм.. длинк показал что те самые 254 пакета по 64байта, бегающие в момент виса - мультикаст поток... юникасты не бегает в этот момент совсем, броадкасты в единичном количестве и без ответа запрашиваемых машин.

Что за мультикаст-поток и чем его выцепить?

Изменено пользователем sheft

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Еще кое что вспомнил.

Когда у нас сеть была на мыльницах, то был случай, что один из коммутаторов эл. питанием включен в щит, где подгорает от плохого контакта эл. проводка. И свитч в момент "искрения" в щитке, в бреду, посылал, транслировал.... какой то пакет, который вешал половину свитчей в этой гирлянде. При том вешались там, где с питанием все ок.

------------

P.S. Прав тот, кто сказал, что неуправляемые железки в домашней сети, это враг надежности и отказоустойчивости.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

если стоит контроль мультикастового шторма на длинке - он может порт обрубать который мультикастит...

А мультикастить может просто абонент какой-нибудь, из хулиганских побуждений или например торент локальных пиров ищет.

Можно попробовать поднять на длинке предел отключений по шторму .

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

если стоит контроль мультикастового шторма на длинке - он может порт обрубать который мультикастит...

А мультикастить может просто абонент какой-нибудь, из хулиганских побуждений или например торент локальных пиров ищет.

Можно попробовать поднять на длинке предел отключений по шторму .

:) проблема не в длинке, а в тупых свитчах которые от этого, врозможно мультикаста, дохнут.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

У меня тоже самое в сети. С точном такими же симптомами. На порту 254-255 пакетов размером 64 байта.

Лечится тупо перезагрузкой коммутаторов. Как быть, еще не придумал.

Изменено пользователем morf

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

У меня тоже самое в сети. Лечится тупо перезагрузкой коммутаторов. Как быть, еще не придумал.

сейчас управляемые свитчи копейки стоят) traffic_segmentation, storm_control, loopback_detect и все замечательно работает) нафиг эти тупые свитчи

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.