[StSphinx]

Доброго времени суток, коллеги!

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

Есть многоэтажный дом, в нем стоит два свича DES-3028. Волокно приходит на первый свич(25 порт, стоит sfp модуль DEM-330T), второй свич включен через первый, медью(порт 26, гигабит).

В какой-то момент первый свич стал виснуть(отваливается управление, абоненты не работают), при этом второй свич в такой ситуации вполне себе доступен и абоненты на нем нормально продолжают работать. Грешили на первый свич - заменили его. Буквально через 5-6 дней все тоже самое. Грешили на питание - оказалось, что запитаны оба свича с одной фазы.

Решили проверить абонентские хвосты. Монтажники прошли по абонентским кабелям, проверили на предмет прохождения их параллельно силовым кабелям в пристройках(стояки у нас свои) - эффекта не дало. Долгими плясками с бубном выяснили, что как только включается некий абонент, через 10-15 минут свич виснет. Пришли к нему со своим буком, пробуем подключаться/отключаться - все ок. Включаем ПК абонента. Стоит только сетевую включить/выключить 2-3 раза - все, свич виснет. Сетевая встроенная. Порекомендовали купить обычную сетевуху. Абонент купил, не помогло. Заменили витую пару до абонента, не помогло. Вчера отправили туда инженера с Live CD(Knoppix). Человек грузит Knoppix с ПК абонента и успешно работает. Включение/выключение сетевухи ничего не дает, свич продолжает работать. Грузит винду, установленную на ПК(WinXP, сборка Zver), свич через 5 минут виснет... Теперь вот сидим и думаем что делать... Соотв. пункт в договоре есть и мы можем расторгнуть его, но не хочется. Хочется понять в чем дело. Из всех этих "танцев" получается, что виновником ситуации является винда на ПК клиента... Но это как-то не вписывается в мое представление о мироустройстве :) Будут какие-то мысли у сообщество, по поводу вышеописанного "бреда"?

[alcool]

купите у абонента компьютер и исследуйте как следует)

[littlesavage]

DES-3028 - это на форум длинка :)

 

[azhur]

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

[Vadi]

был у нас такой случай, только абонент клал тупую сеть., причем всю и сразу.

замена сетевойц не помогла.

комп был достаточно старый, клиент сказал что купит новый, так и решили.

[disappointed]

Думаю дело не в винде а в стоящем у него софте.

Edited May 14, 2010 by disappointed

[woddy]

поменять свич на другую модель. или переставить винду абоненту ;)

[StSphinx]

Комп у абонента вполне нормальный, БП стоит вполне себе ничего... Да и как я уже писал, все "веселье" начинается при загрузке установленной у него винды. Идея с "купить комп" мне не кажется интересной. Нет, трафик пока не слушали.

 

На форум Длинка, говорит? Угу... А если речь будет идти о электроэнергии, то наверное на форум межрегиональной сбытовой компании, ага....

 

поменять свич на другую модель. или переставить винду абоненту ;)

Переставить винду это просто. И тупо. Потом кто-то в другом месте сети поставит себе такое же, а мы будем просто советовать переставить винду.

 

Думаю дело не в винде а в стоящем у него софте.

На софт посмотрим подробнее. Спасибо за совет.

 

[alcool]

кстати когда выясните в чем причина, может и не стоит ее тут озвучивать))

[dIMbI4]

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

Edited May 14, 2010 by dIMbI4

[make.kernel]

Галочка flow control у клиента в настройках сетевушки? Свичи "имя которых нельзя произносить вслух" любят поставить все порты в паузу если получат pause frame на одном. Гигабитные могут обрабатываться отдельно, поэтому дальний свич виден. Это я так, пальцем в небо потыкал, тучи, гроза будет однако.

[andreyk]

Дело не в сетевушке, а скорее всего в софте, скорее всего вирусня. Нужно проверять комп на наличие бацилл.

[StSphinx]

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

Интегреная сетевуха у клиента интеловская, внешняя - Dlink 520.

 

Галочка flow control у клиента в настройках сетевушки? Свичи "имя которых нельзя произносить вслух" любят поставить все порты в паузу если получат pause frame на одном. Гигабитные могут обрабатываться отдельно, поэтому дальний свич виден. Это я так, пальцем в небо потыкал, тучи, гроза будет однако.

Flow control отключен на свиче. Да и если предположить, что свич ловит pause frame и ставит фасты на паузу, то почему отваливается управление, которое идет через гигабитный порт?

Edited May 14, 2010 by StSphinx

[dIMbI4]

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

[s.lobanov]

В чём был смысл возвращаться от абонента без дампа трафика?

[StSphinx]

В чём был смысл возвращаться от абонента без дампа трафика?

Дамп сегодня снимем. Хотя что-то подсказывает, что дамп ничего не даст. Но вдруг? :)

[s.lobanov]

Я не так давно боролся с dos-атакой на dns, снял дамп, сразу стало всё понятно, абонента отключили от сети, в итоге оказалось, что программа для рассылка спама, генерировала не только dns-запросы(IN MX), но ещё и мелкие мусорные(но не случайным образом сгенерённые) пакеты с большой частотой. Заодно на основании этого дампа составил набор правил для iptables(-m string) для защиты от подобных атак.

 

Не знаю чем можно уронить коммутатор, но кое-какое оборудование можно положить частыми snmp-запросы(с любым community), если нет access-листа для snmp и есть доступ по ip к нему

[StSphinx]

Я не так давно боролся с dos-атакой на dns, снял дамп, сразу стало всё понятно, абонента отключили от сети, в итоге оказалось, что программа для рассылка спама, генерировала не только dns-запросы(IN MX), но ещё и мелкие мусорные(но не случайным образом сгенерённые) пакеты с большой частотой. Заодно на основании этого дампа составил набор правил для iptables(-m string) для защиты от подобных атак.

 

Не знаю чем можно уронить коммутатор, но кое-какое оборудование можно положить частыми snmp-запросы(с любым community), если нет access-листа для snmp и есть доступ по ip к нему

Вот и я незнаю.. В абонентский порт ходит только Loopback detection. Управление свичами вынесено в отдельный VLAN и вообще в отдельный MPLS VPN. Трафик, по показаниям свича, перед зависанием, ходит совсем небольшой. Тем не менее, сегодня будем пробовать снимать дамп. Чем черт не шутит, может что и найдем.

[mschedrin]

Вот и я незнаю.. В абонентский порт ходит только Loopback detection. Управление свичами вынесено в отдельный VLAN и вообще в отдельный MPLS VPN. Трафик, по показаниям свича, перед зависанием, ходит совсем небольшой. Тем не менее, сегодня будем пробовать снимать дамп. Чем черт не шутит, может что и найдем.

IP-MAC-Binding используете? Ошибки на порту клиента смотрели? Какая прошивка?

 

В идеале снять несколько дампов. С копьютера клиента, с порта свитча с помощью port mirroring и с управляемого свитча включенного между абонентом и зависающим 3028. Вообще убедиться что при включении другого свитча между абонентом и 3028 последний продолжает зависать.

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

 

[StSphinx]

Вот и я незнаю.. В абонентский порт ходит только Loopback detection. Управление свичами вынесено в отдельный VLAN и вообще в отдельный MPLS VPN. Трафик, по показаниям свича, перед зависанием, ходит совсем небольшой. Тем не менее, сегодня будем пробовать снимать дамп. Чем черт не шутит, может что и найдем.

IP-MAC-Binding используете? Ошибки на порту клиента смотрели? Какая прошивка?

 

В идеале снять несколько дампов. С копьютера клиента, с порта свитча с помощью port mirroring и с управляемого свитча включенного между абонентом и зависающим 3028. Вообще убедиться что при включении другого свитча между абонентом и 3028 последний продолжает зависать.

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

IPMB используем, ошибок на порту нет, прошивка была 2.41-B02, сегодня сменил на 2.50-B08. Сейчас человек уехал снимать дамп. Ситуация усложнилась тем, что клиент бодрым кабанчиком уже переставил винду... В промежуток пока ничего не ставили, попробуем, если ситуация не изменится.

[mschedrin]

Вот и я незнаю.. В абонентский порт ходит только Loopback detection. Управление свичами вынесено в отдельный VLAN и вообще в отдельный MPLS VPN. Трафик, по показаниям свича, перед зависанием, ходит совсем небольшой. Тем не менее, сегодня будем пробовать снимать дамп. Чем черт не шутит, может что и найдем.

IP-MAC-Binding используете? Ошибки на порту клиента смотрели? Какая прошивка?

 

В идеале снять несколько дампов. С копьютера клиента, с порта свитча с помощью port mirroring и с управляемого свитча включенного между абонентом и зависающим 3028. Вообще убедиться что при включении другого свитча между абонентом и 3028 последний продолжает зависать.

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

IPMB используем, ошибок на порту нет, прошивка была 2.41-B02, сегодня сменил на 2.50-B08. Сейчас человек уехал снимать дамп. Ситуация усложнилась тем, что клиент бодрым кабанчиком уже переставил винду... В промежуток пока ничего не ставили, попробуем, если ситуация не изменится.

Если юзер подменит мак шлюза, то ipmb его заблокирует - последствия предсказуемые. К свитчу подключались через ком порт? Проверяли блокированые маки?

[StSphinx]

Вот и я незнаю.. В абонентский порт ходит только Loopback detection. Управление свичами вынесено в отдельный VLAN и вообще в отдельный MPLS VPN. Трафик, по показаниям свича, перед зависанием, ходит совсем небольшой. Тем не менее, сегодня будем пробовать снимать дамп. Чем черт не шутит, может что и найдем.

IP-MAC-Binding используете? Ошибки на порту клиента смотрели? Какая прошивка?

 

В идеале снять несколько дампов. С копьютера клиента, с порта свитча с помощью port mirroring и с управляемого свитча включенного между абонентом и зависающим 3028. Вообще убедиться что при включении другого свитча между абонентом и 3028 последний продолжает зависать.

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

IPMB используем, ошибок на порту нет, прошивка была 2.41-B02, сегодня сменил на 2.50-B08. Сейчас человек уехал снимать дамп. Ситуация усложнилась тем, что клиент бодрым кабанчиком уже переставил винду... В промежуток пока ничего не ставили, попробуем, если ситуация не изменится.

Если юзер подменит мак шлюза, то ipmb его заблокирует - последствия предсказуемые. К свитчу подключались через ком порт? Проверяли блокированые маки?

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

 

[mschedrin]

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

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

Возможность снять дамп - есть, а подключиться к свитчу нет? Странная ситуация.

[StSphinx]

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

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

Возможность снять дамп - есть, а подключиться к свитчу нет? Странная ситуация.

Вы сейчас о каком шлюзе? Мы наверное где-то не понимаем друг друга. У нас сети абонентов отдельно(vlan и L3 на свич), управление отдельно и в разных MPLS VPN, как я уже писал выше. Соответственно подменить мак шлюза сети управления, у абонента нет возможности. А подмена мака шлюза абонентской сети ни коим образом не повлияет на доступность интерфейса управления коммутатором.

 

[terrible]

DES-3028#conf traffic cont 1-24 br en uni en mult en ac drop time 5 thr 100

 

пробовали?