Доброго времени!

с некоторый пор у некоторых пользователей наблюдается проблема, линк есть, но пропадает сеть, "подвисает инет". Некторые говорят, что раз в 10мин и чаще. На указанных коммутаторах включен ip-mac binding, однако в логах ничего на момент проблем нет. Зато есть следующее (взято с syslog-сервера для конкретного порта)

Mar 4 21:17:58 router 192.168.88.5 INFO: Port 19 link down
Mar 4 21:18:05 router 192.168.88.5 INFO: Port 19 link up, 100Mbps FULL duplex
Mar 4 21:24:25 router 192.168.88.5 INFO: Port 19 link down
Mar 4 21:24:26 router 192.168.88.5 INFO: Port 19 link up, 100Mbps FULL duplex
Mar 4 21:30:41 router 192.168.88.5 INFO: Port 19 link down
Mar 4 21:30:43 router 192.168.88.5 INFO: Port 19 link up, 100Mbps FULL duplex
Mar 4 21:54:25 router 192.168.88.5 INFO: Port 19 link down
Mar 4 21:54:31 router 192.168.88.5 INFO: Port 19 link up, 100Mbps FULL duplex
Mar 4 21:54:39 router 192.168.88.5 INFO: Port 19 link down
Mar 4 21:54:41 router 192.168.88.5 INFO: Port 19 link up, 100Mbps FULL duplex
Mar 4 21:54:43 router 192.168.88.5 INFO: Port 19 link down
Mar 4 21:54:49 router 192.168.88.5 INFO: Port 19 link up, 100Mbps FULL duplex
Mar 4 21:54:54 router 192.168.88.5 INFO: Port 19 link down
Mar 4 21:54:55 router 192.168.88.5 INFO: Port 19 link up, 100Mbps FULL duplex
Mar 4 21:55:00 router 192.168.88.5 INFO: Port 19 link down
Mar 4 21:55:03 router 192.168.88.5 INFO: Port 19 link up, 100Mbps FULL duplex
Mar 4 21:55:20 router 192.168.88.5 INFO: Port 19 link down
Mar 4 21:55:22 router 192.168.88.5 INFO: Port 19 link up, 100Mbps FULL duplex
Mar 4 21:55:39 router 192.168.88.5 INFO: Port 19 link down
Mar 4 21:55:43 router 192.168.88.5 INFO: Port 19 link up, 100Mbps FULL duplex
Mar 4 21:57:01 router 192.168.88.5 INFO: Port 19 link down
Mar 4 21:57:02 router 192.168.88.5 INFO: Port 19 link up, 100Mbps FULL duplex
Mar 4 21:57:10 router 192.168.88.5 INFO: Port 19 link down
Mar 4 21:57:12 router 192.168.88.5 INFO: Port 19 link up, 100Mbps FULL duplex

у 3536 прошивка *5.01-B05
у 3026 прошивка Build 4.01.016
что делать?

скорее всего у вас петля в сети на этом порту. отлавливайте и убивайте её скорее.

_________________
LiveComm

Хватит людей пугать!! Вы хоть видели, что происходит, когда петля? сделайте и посмотрите!!!
жду еще ответов

и не раз видел. особенно веселились когда в нашем филиале на 40% стояли мыльницы DES-1008D. А уж про то что творилось во всей сети я промолчу. Невероятные вещи просто от постоянных дисконнектов VPN, 60% потерь пакетов при прохождении пингов и т.п.

P.S. запросите у сотрудников D-Link новую прошивку (5.01-В19 для 3526). На сколько я помню на форуме упоминали, что идет кривое логирование функции loopdetect.

_________________
LiveComm

спасибо конечно, но нет там петли на этом порту, смотрел физически...
и про loop в логах ни строчки, странно((( и когда пеля, вообще не работает, все ложится, а тут временами....
где Иван Демин))))

да не ложиться в том то и дело. а логи кстати действительно часто пустые когда срабатывает loopdetect. есть прошивка в которой это исправлено?

хм...тогда можно подробнее, что понимается под петлей....
в данном случае - на одном конце - порт 3526, на другом - сетевая карта....

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

Ну а на 3026 прошивка Build 4.01.020 уже давно...

Я Вам прошивки выслал.

всем спасибо, ночью перепрошьем, о результатах доложу

похожая беда.
Сразу скажу, у нас в сети используется md5-авторизация. Появилась такая проблема, что пользователи либо вообще могут подключиться только 5-10 раза, появляются и сразу трапаются, либо, если и подключились, то через минут 7-15 снова наступает трап. Причём такое может быть как у одного-двух, так и на всём коммутаторе. Коммутаторы стоят 3026, прошивка 4.01.009. При этом в логе на нём примерно такое:

После перепрошивки на 4.20.003 таких скачков линка уже нет, вроде как, на первый взгляд, ситуация исправляется. Но во многих случаях проблема остаётся. Логи вот такие:

Но вот этот скачок down/up делает вот что. Человек трапается и отлетает, инет у него исчезает. В то же самое время приходит новый запрос, получается ip-шник, иногда не получается (иногда после такого он может даже надолго зависнуть в сети, но ip-шник так и не получить), у него подключение идёт, локалка соответственно летает, однако внешки нет. Мы грешили на сетевушки, ставили на них новые драйвера, убирали автоопределение скорости на 100/10-full. Иногда даже это не помогает.
Если поможет могу добавить, что кроме этих дилинков в сети присутствуют ещё Zyxel2108/2024, агрегирующие узлы - DES-3627 или Zyxel4012.

Up

Хочу сказать, что тема поднятая learner, весьма актуальна и для меня.

Попробуйте пожалуйста прошивку которую я вам выслал.

Вы с какой авторизацией работаете? если 802.1х - стукнете в асю 171790606. Есть ряд мыслей по поводу трапов.

Точнее - если вы обрабатываете трапы от клиентских коммутаторов и по этим трапам закрываете доступ в инет по "link down", то есть следующие мысли.
Только что приходили с буком, тест на стенде показал следующее - при отключении сетевой - физический линк не рвется. При включении - коммутатор показывает отрыв физики на 2 сек.За это время посылается 2 трапа - link down и link up. Если после включения линка комп клиента авторизуется самомтоятельно, то он авторизуется довольно быстро. Проблема в обработке трапа link down. Если сервак на котором вы ловите трапы нагруженный, то обработка трапа в некоторые моменты может занимать несколько секунд (дольше процесса авторизации). Поэтому получается, что билинг, или что-то там, что должно отключать абона от инета получает извещение о событии "link down" уже ПОСЛЕ авторизации клиента. После чего он, естественно, отлетает от сети.

Проверить скорость обработки можно так:
с одной машины посылаем трап
"snmptrap -v 1 -c public <ip сервера слушателя> .1.3.6.1.4.1.171.10.63.3.1 <ip от имени которого посылается трап> 3 1 '' .iso.org.dod.internet.mgmt.mib-2.interfaces.ifTable.ifEntry.ifIndex.2 i 1"

ifEntry.ifIndex.2 - здесь 2 - номер порта коммутатора
.1.3.6.1.4.1.171.10.63.3.1 <ip от имени которого посылается трап> 3
тут 3 - link up
2- link down
1- worm start

это для freebsd.
ну и посмотреть - когда обработалось snmptarpd - это на той машине, куда посылаем.
tail -f /var/log/snmptrapd.log | grep <ip источника>

Я вижу отсюда 2 выхода.
1- увеличение можности сервера
2- снижение нагрузки на snmptrapd
a) по snmp слать не все подряд, а только события связанные с изменением статуса портов. Сотрудники длинка - просьба подсказать как правильно это сделать применительно применительно к коммутаторам des-3026 и des-3028.