Ошибка в следующем.
После удаления порта из default vlan по нему перестают рассылаться LoopDetect сообщения, и рассылка не возобновляется после добавления порта в новый vlan.
Я сообщу об этом в ШК.

Секунду, на прошивке 6.20.B07, ситуация такая же? Перезагрузка поможет?

В общем не смог заставить перейти с рабочим конфигом на новую версию. В current_config стоит disable dhcp_relay и все... Любой save с перезагрузкой отключит dhcp_relay. И что делать?

thousandrich
Про нее сейчас и идет речь.
После перезагрузки ситуация не меняется.
mbc44
Как я уже говорил - на стенде ситуацию подтвердить не получается. Даже с вашим конфигом.
enable dhcp_relay ситуацию не исправляет? State остается в Disable и при этом не работает?

На des-3550 эта версия себя так же ведет.

mbc44
Функционал прошивок для DES-3526 и DES-3550 одинаков, так что одинаковое поведение одинаковых версий прошивок также логично.

Последние вести с полей:

- обнуляем конфигурацию, прошивка B57,
- заливаем рабочий конфиг, сохраняемся,
- переключаемся на новую прошивку, перегружаемся,
- смотрим:

State = enable и все работает. В current_config видим dhcp_relay = disable. Enable dhcp_relay никак не влияет на это состояние.

З.Ы. Ща фильм сниму.

Фикс работы loopdetect, о котором писал выше, будет в первой половине декабря

Удивительно, а почему до сих пор не убрали прошивку 6.20-B07 из общего доступа?

Залили на несколько коммутаторов. Через 1-2 дня у клиентов появились потери пакетов. Тупо пинг - 40-50% потери.
Причем проблема вылезла и на тестовой зоне, где коммутатор заземлён, включен через UPS.

Помогает перезагрузка. Либо откатываем на 6.00-B54.

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

У меня на тестовой зоне проблема появилась через 5 дней тестирования.
Симптомы те же что и у абонентов - 40-50% потери пакетов (ping хотя бы на местный dns)
Вылечилось перезагрузкой коммутатора.
Но пока не допёрло, что проблема массовая и появилась после перехода на новую прошивку - ходили на узлы, переключали клиентов в любой соседний порт.

Порекомендуете собрать снифером пакеты за 5 суток, те что летят к тестовому абоненту и отправить вам?

Мужики, извините, похоже проблема не в прошивке.

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

Смотрите загрузку cpu, навешенный функционал и трафик, идущий через коммутатор.

Смотрим, ничего необычного не видно, на всей сети конфиг одинаковый, у каждого абонента свой индивидуальный IMPB.

Но за то на порту абонента видно следующее, например:
Длина кабеля примерно 71 метр.
На порту есть CRC Err.
Если ошибки сбросить - счетчик медленно увеличивается при передаче данных.
Отключение loopdetect, stp, address bind - на потери пакетов не влияет, они стабильно 40-50%
(ping -c 1000 -i 0.2 -s 1024 94.188.xx.xx)

Ребутаем коммутатор. Ошибок на порту клиента нет. Не растут.
Пинги до клиента ходят без потерь.
За прошедшую неделю из вот так вот "вылеченных" абонентов никто повторно не обращался.
Таких волшебных клиентов немного, примерно 5 шт в сутки, но тем не менее...

Чем и как это можно отловить? Есть идеи?

ЗЫ:
Да, забыл сказать, среди вот таких проблемных абонентов ещё бывает и так, что порт не желает работать на 100Мбит.
Т.е. если на коммутаторе переключить на 10Мбит, появляется передача данных, хоть и с потерями. На 100Мбит линк есть, но передачи нет вовсе. Лечится перезагрузкой свитча.

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

Выключил вот этот фильтр:

config filter dhcp_server ports 1-24 state disable
(...был включен.)

После этого нужно порт клиента переключить из AUTO в 10/HALF, затем обратно в AUTO.
Клиентский IP начинает пинговаться без потерь, ошибки не растут.
(ну или можно сохранить и перезагрузить свитч, но тогда не так наглядно)