Добрый день.
Сначала опишу сеть:
1-Оборудование -3526 на конечных домах, 3326GSR на узлах. Узлы сводятся в циску для маршрутизации локального трафика. Туда же воткнуты несколько PPPOE серверов для интернета.
Сеть поделена на вланы с подсетями /24 в них
Итого -доступ в локалку -DHCP option 82, в интернет PPPOE

2-На коммутаторах на клиентских портах стоят настройки Broadcast storm control:


Далее проблема.
Насколько я понял современные клиенты торрента (в основном utorrent) активно ищут пиров внутри сети из за чего срабатывает broadcasct storm control, что приводит к кратковременному отключению трафика на порту и естественно к разрыву PPPOE соединения.
Соответсвенно клиенты жалуются на разрывы.

(WARN: Broadcast storm is occurring (port: 20)

Посмотрел пару проблемных клиентов - с среднем в секунду 30-50 броадкастов идет. Естественно broadcast storm control срабатывает.
При отключении торрента у абонента -проблема исчезает полностью.

Совершенно ясно что такое поведение компьютера в сети не считается нормальным, но с разработчиками торрента не поспоришь.


Далее вопросы:
1-Как будет себя вести опция drop в traffic control? (во первых нет лога срабатывания, что плохо). Не порубит ли она в случае ее включения нужные броадкасты (DHCP и PPPOE броадкасты)?
2-Что вообще считается ненормальным "флудом"?

20 пакектов в секунду? 50? 100?

3-Есть какие то рекомендации по настройке данной функции? Какой порого срабатывания устанавливать в текущих условиях.
С одной стороны хочется недопустить шторма который "положит" сеть.
С другой стороны "разрывы" клиентов не радуют.

20 в секунду с одно клиента это уже ненормально.

как вариант pcf на доступе - зпаретить бродкаст пакеты по протоколу торрент.

И что это за протокол такой?
правила напишете для 3526?



Знаю что ненормально. Но вот критично ли?
Просто начали звонить и жаловаться -мол вы нам торрент блокируете.
Но заставлять каждого абонента сменить торрент клиента - тоже не есть правильно, абоненты не обрадуются такому провайдеру.
Вот если бы как нибудь блочить подобные пакеты?

речь об аксесс-листах
Packet Content Filtering
точного правила я вам не могу сказать, т.к. надо включать сниффер смотреть формат пакета и делать индивидуальное правило.

Тему по проблеме с torrenоt-ом и udp мы уже обсуждали:
viewtopic.php?t=119048&highlight=PCF
Вы же инициатор этой темы.

_________________
С уважением,
Бигаров Руслан.

Я не про пакеты данных, utp и прочее.
Данные торрента не распространяются броадкастом внутри сети.


Этот броадкаст всего лишь арп броадкаст который делает поиск локальных пиров и прочее. То есть просто сканит сеть и ищет пиров
и именно большое их кол-во вызывает броадкаст шторм.
Короче обычный сканер сети (netview или lanscope)вызовет похожее количество броадкастов на абонентском порту и тоже будет заблочено Broadcast storm control.
Только сканер сети не запускают вообще или запускают иногда
Торрент же включен всегда и постоянно сканит сеть на наличие пиров.

пакеты даннных или служебные пакеты в данном случае неважно и фильтрация будет осуществляться аналогично,"захватываем" пакет, смотрим структуру, делаем лист доступа....

Сомневаюсь, что большое кол-во броадкаста - это поиск локальных пиров. Может быть это наоборот, клиент нашел лок. пиров ну и ему соответственно нужно узнать их маки (если у вас большие вланы на сети).
Мне кажется не плохим вариантом будет поставить траффик контроль в режиме дроп.

торрент ищет локальных пиров мультикастом

_________________
с уважением, БП

Да, похоже именно на это
вланы стандартные по /24, но клиентов в влане не более 150

Я тут подумал вот что: несмотря на размер влан -арп броадкаста по поиску маков все равно будет много.
Попробую закрыть мультикаст с юзерских портов и перевести политику в режим drop

Добрый день!
Настройки traffic control на 3200-28F с параметрами Broadcast Threshold на всех портах 1-28 со значением 64 кбит/с могут резать видео звонки по Scype?
Или, - в противном случае, что ещё может резать сессии Scype?