на DGS-3612G роблема скорее всего осталась, не смотря на то, что
Boot Prom 1.10-B09
FW 2.50-B25
Harware Version: 1A1G

Пинги с потерями, 1-2%
При ping -l 65500 -t почти все 100% потерь

На FW 2.40.B77 такого нет.
Может проблема в чем-то другом?

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

To CHeRTeNok:

У Вас квота в почте закончилась.

Отправьте еще раз BootPROM
Заранее спасибо)

Повторил.

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

Аналогичная проблема на 3612G

Boot PROM Version Build 1.10-B09
Firmware Version Build 2.40.B77

Пропадает связь со всеми свитчами и с самим коммутатором раз в 20 мин примерно на 1 мин.

Полечилось увеличением ARP-aging time до максимума. Возможно что это только удлиняет срок работы и перерывы связи становятся не заметины для абонентов. Так что нужно нормальное решение конечно.

У меня другая проблема, каджые несколько секунд (видимо равное ARP Ad Time=20 sec) коммутатор посылает в сегмент ARP запросы для всех адресов, соответствнно нижестоящие 3526 срабатывают на Broadcast storm установленный на 100 пакетов в секунду. И соответственно на полсекунды тушится порт, Вопрос зачем он пытается обновить все ARP записи, вместо того чтобы обновлять те которые устаревшие? ну не могут же они все одновременно устареть?

1. А в чем смысл ставить столь малое время жизни ARP'а? Оно должно быть явно не менее времени жизни MAC'а в FDB (imho), которое по умолчанию 300 секунд.

2. DES отрабатывает шторм-контроль только на входящие пакеты. Просто отключите его для uplink-портов и оставьте лишь для абонентов. У нас так сделано. Такой проблемы нет. Опять же, можно делать не shutdown, а drop, но это включается для группы портов (во всяком случае длл 3550/3526).

3. В DGS действительно есть какая-то проблема с ARP'м для сегментов, которые на нем терминируются. Но отловить ее и четко диагностировать не получается. Скажу только, что вероятность ее проявления прямо пропорционально количеству клиентов на свитче, а также чаще она проявляется для Windows 7.

После age time 14400 проблема проявляется с большим интервалом (около 4 часов) а иногда даже и через 4 часа не проявляется, видимо в зависимости от того сочтет ли свитч нужен обновить Mac адрес.

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

Народ!

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

Полное впечатление, что вылезает исключительно под нагрузкой!-( Может собрать стенд и arp-запросами его?

Чтобы от ARP флуда поменьше страдать, не менял дефолтное значение.

2. DES отрабатывает шторм-контроль только на входящие пакеты. Просто отключите его для uplink-портов и оставьте лишь для абонентов. У нас так сделано. Такой проблемы нет. Опять же, можно делать не shutdown, а drop, но это включается для группы портов (во всяком случае длл 3550/3526).

Это стоит, я в общих чертах обрисовал поведение. Проблема в том что 3627 неадекватно часто и много шлет ARP запросов.

Вот например лог снифера:

Продолжаю эскперименты:
из другого сегмента пингую отсутствующий на данный момент в сети 10.1.14.5

И получаю вопрос на который хочу услышать ответ:
1) Зачем коммутатор дополнительно начал искать 10.1.14.113?



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

Продолжаем эксперименты:

Задал ровно 20 пингов с другого сегмента в сторону отсутствующего в данный момент 10.1.14.6



Если принять за аксиому, то что 3627G на каждый запрос в сторону отсутствующей в его ARP таблице записи, шлет ARP бродкаст, то возникает вопрос:
1) Почему при 20 пингах коммутатор послал всего 12 ARP бродкастов в сегмент.
2) Почему собственно во время пинга коммутатор послал собственно 10, причем 1-2 и 7-8 после очередного пинга(это видно по дельте времени) и после того как удаленный комп отпинговался коммутатор послал еще два контрольных (собственно 11 и 12)

Вот этой логики я не понимаю, давайте все таки определимся по какому RFC мы живем.

PS Перед тестами ARP и FDB таблица чистилась.

Пришлите пожалуйста схему теста с указанием портов подключения и конфиг устройства.

Все у Руслана и порты и конфиги.