На порту у клиента не виден МАС адрес, появляется после ребута коммутатора
На порту
Port Admin State Max. Learning Addr. Lock Address Mode
---- ----------- ------------------ -----------------

5 Enabled 1 DeleteOnTimeout

Boot PROM Version : Build 1.00.B06
Firmware Version : Build 2.50.B08
Hardware Version : A1

Проблема не наблюдалась со старами прошивками

"sh flo" что показывает в этот момент?..

_________________
Это текст, который можно добавлять к размещаемым вами сообщениям. Длина его ограничена 255 символами.

ena flood
conf flood log ena
cl flood
cl fdb
save

ну и после этого ждём волшебных сообщений

sh flo показваывает

Flooding FDB State : Enabled
Log State : Enabled
Trap State : Disabled

Value VLAN ID MAC Address Time Stamp
------ ------- ------------------- ----------
6944 115 00-1E-F7-41-70-00 * 5430135
6944 3090 00-15-17-C7-DB-18 5430135
8022 115 00-21-91-53-37-0F 5430129
8022 3092 00-04-61-6E-50-9B 5430129

Какой MAC адрес у клиента?

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

Проблема в колизиях хешей мак-адресов.

Как временная мера - чистите колизии (cl flood) при их появлении.
Как нормальная мера - дробите влан на более мелкие куски.

Прошу комментариев сотрудников D-Link по этому поводу. Помогает ли (хотя бы временно) команда cl flood от флуда? Или она просто чистит мониторинг и успокаивает глаз?

На сколько мелко дробить?
Может есть максимальное количество маков для одной влан, при катором не происходят коллизии?

Чем меньше, тем лучше.

Нет и не может быть такой цифры. Коллизии происходят из-за совпадения хэшей мак-адресов. Какие будут хэши зависит от самих маков. Теоретически возможны коллизии даже если на свиче будет всего-то 2 мака. Но, конечно же, вероятность этого значительно ниже, чем в случае с 200 маками.

Мне помогает (отслеживаю через SNMP мониторинг), тупо меньше колбасит сетку + стабилизация работы PPPoE.

Теория вероятности, м да...
Но почему вероятность совпадений увеличилось с новой прошивкой Firmware Version : Build 2.50.B08 ?

terrible, реально помогает? Или может вам просто кажется? Не понимаю, как очистка мониторинга может влиять на ситуацию. Плохо, что ответа по поводу того что делает clear flood от D-Link видимо не последует.

У меня биллинг отслеживает онлайн свичей по SNMP протоколу. В случае, если хост 2 раза не отвечает за запрос, он переводится в статус down (+сообщение всему персоналу), из этого статуст потом выводится в случае 2-х положительных ответов(+сообщение всему персоналу).

До чистки flood FDB в даун у меня уходило половина коммутаторов, за ночь сообщений подобного рода набиралось порядка 150, после запуска чистки, уходят, но гораздо реже (за ночь около 50). После дробления управляющего влана - перестали уходить.

+ клиенты прекратили жаловаться на нестабильность PPP соединений.

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

Ну и по поводу функции cl flood у меня мнение такое:
что она не только вычищает мониторинг, но и саму таблицу FDB от маков, попавших в черный список.

А само отображение sh flood является отображением ошибок в таблице хешей (один цикл по таблице), а не какой-то дополнительный нависон на ПО.

наверное всё же нависон - ведь сам свитч вроде как не может запомнить записи с одинаковым хэшем...

_________________
Это текст, который можно добавлять к размещаемым вами сообщениям. Длина его ограничена 255 символами.