Artem Kolpakov писал(а):
poofeg писал(а):
Цитата:
Changed traffic control behaviour
Есть дополнительная информация?
Более подробно - поведение подтянули к таковому на DES-3200.
Можно выставить countdown disable чтобы порт гасился сразу, если countdown включен - то шторм отсекается выше threshold, а не льется в сеть.
В общем, сделали, как и должно по логике вещей работать.
passer писал(а):
Текущий боевой bootprom 1.00.009 ?
да, и процедуры отдельного обновления бута нет - только через прошивку с вшитым бутпромом, например, 6.05.B009.
Над проблемой stp с перевыбором рута работают.
1) просьба привести рекомендованное значение для broadcast траффика на Uplink портах , и на абонентских портах отдельно в данной модели коммутатора.
в сети используется сервисы = PPPOE c-vlan на юзера, IPTV multicast, stp, абоненские подключения через роутер .
Command: config traffic control 25-28 threshold
Next possible completions:
<value 0-1024000> (тут указывается значение в пакетах в секунду?)
для примера в другом типе оборудования мы использовали порог от 1 до 5% от порта.
2)просьба разъяснить логику работы функции config gvrp ingress_checking в данной модели коммутатора.
при модели c-vlan на юзера - смысла в ingress_checking нет ? (тк на порт подается уникальный vlan)
3)просьба разъяснить логику работы PVID на UPLINK портах коммутатора.
ранее вы упомянули, что PVID на UPLINK должен быть обязательно указан обязательно существующий vlan который подан на порт как untagged.
и при
выключении ingress_checking имеет ли смысл это ограничение?
1й влан мы оставлять на аплинках желания нет, в случае данной необходимости, пока возможное решение - создавать "левый vlan заглушку" который подадн на uplink'и коммутатора, но на аггрегации не подан и не используется.
4)корректно ли работает функция config multicast filter 1-25 filter для фильтрации мультикаста с аб. портов?
5)ранее вы указали что необходимо использовать management_vlan чтобы весь трафик не обрабатывался процессором, а только в VLAN'е управления.
уточните логику работы функции trusted_host - не дает ли он ощутимой нагрузки на процессор?
или принимая во внимание что у данного коммутатора очень слабый CPU, лучше отказаться сразу от этой функции.
6)будет ли восстановлено корректное функционирование flood_fdb и судя по теме
viewtopic.php?f=2&t=125028&start=15 (описывают что возможно коллизии от 300+ юзеров особенно при использовании IPTV multicast)
в кольце из 10 коммутаторов лучше бы эту функцию использовать потому, что уже возможны коллизии хеша мак-адресов.
на данный момент у нас не работает стп на этих коммутаторах (выше написали что проблема "решается");
даже в луче из 6 коммутаторов с отключенным стп и базовыми параметрами , c-vlan на юзера и IPTV, на данный момент мы не получаем качественного предоставления IPTV (а судя по графикам и скорость интернета падает периодически, особенно в пик вечерних нагрузок)
7)будьте добры, укажите количество битов используемых для вычисления хеша мак-адресов в даннйо модели коммутора (dlink des1210-28/me b2)
лично я очень надеюсь что следующая прошивка которую мы получим - у неё получится чудесным образом вылечить все эти "баги" .
ps. не нашёл где почитать changelog версий прошивок (релизов)
Вход
Регистрация
FAQ
Поиск
