Re: Ограничение макси мальной скорости по I P

2008-01-17 Пенетрантность Stanislav Kruchinin

Покотиленко Костик wrote:


Про разницу массового фильтрования в iptables и посредством tc filter
попробую объяснить на пальцах.

  - tc filter использует линейный список фильтров, в iptables можно
построить в виде дерева;


Наоборот. Деревья фильтров можно (с трудом) строить в u32. IPCLASSIFY 
просто вычисляет номер класса из IP-адреса, т.е. фактически строит хэш 
вида IP = class. IPMARK таким же образом маркирует пакеты.



  - tc filter имеет ограниченное число критериев сравнения по сравнению
с iptables;

То есть, если сегодня Вам нужно фильтровать только по IP, tc filter
подойдёт. А завтра понадобится фильтровать в зависимости от фазы луны и
придётся слезать на iptables :)



Фильтр u32 работает с любыми полям пакета, в отличие от 
IPMARK/IPCLASSIFY, которые читают только IP источника или назначения.



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Ограничение макси мальной скорости по I P

2008-01-17 Пенетрантность Nicholas

Eugene Berdnikov wrote:


 Каким образом это решит задачу ограничить поток для конкретного ip?


Предположим у меня 3 правила TC на каждый IP :
(это как раз решает задачу ограничить поток на IP)

Сначала шапка - дефолтный поток и т.д
tc qdisc add dev tap4 root handle 4: htb default  9944 

tc class add dev tap4 parent 4: classid 4:9994  htb rate 1mbps burst 
150k
tc class add dev tap4 parent 4:9994  classid 4:9944 htb rate 64kbps ceil 
128kbps burst 150k
tc qdisc add dev tap4 parent 4:9944 handle 9944: sfq perturb 10 


#..И для каждого IP вот такие 3 строки.:
tc class add dev tap4 parent 4:9994  classid 4:41 htb rate 64kbps ceil 
128kbps burst 150k

tc qdisc add dev tap4 parent 4:41 handle 41: sfq perturb 10
tc filter add dev tap4 parent 4: protocol ip prio 1 u32 match ip src 
192.168.4.1 flowid 4:41


Работает, не жалуюсь, но интересно знать при каком числе IP такая 
конструкция начнет тормозить и может ли использование IPMARK/IPCLASSIFY 
снизить нагрузку в этом случае ?


Заодно - раньше было четвертое правило-фильтр (dst вместо src, но на tap 
ничего не ловило)
tc filter add dev tap4 parent 4: protocol ip prio 1 u32 match ip dst 
192.168.11.1 flowid 4:41

так и не понял как его правильно для tap написать и нужно ли.

--
Sincerely,
Nicholas


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Ограничение макси мальной скорости по I P

2008-01-17 Пенетрантность Stanislav Kruchinin

Покотиленко Костик wrote:


Вы про какие IPMARK/IPCLASSIFY говорите? Если про те, что в iptables
-j CLASSIFY --set-class MAJOR:MINOR и -j MARK --set-mark value,
то что значит которые читают только...? Они ничего не читают,
читает iptables посредством разных модулей, у которых есть
возможность фильтровать не только IP источника или назначения, а
так же по MAC адресам, оригинальным адресам (до/после работы
SNAT/DNAT), протоколам, портам, портам моста, PID'у локальной
программы, состоянию conntrack и многим другим критериям.



Я говорю о модулях IPMARK и IPCLASSIFY, которые заменяют кучу правил с
-j MARK и -j CLASSIFY, соответственно, и работают только для IP
источника и назначения.
http://www.netfilter.org/projects/patch-o-matic/pom-external.html
http://ipclassify.relef.net/docs.html


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Ограничение макси мальной скорости по I P

2008-01-17 Пенетрантность Nicholas

Покотиленко Костик wrote:


Мало того HANDLE не может быть больше ::999 :(( ППЦ.


, и это на каждый parent, umho.

--
Sincerely,
Nicholas


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Ограничение макси мальной скорости по I P

2008-01-16 Пенетрантность Stanislav Kruchinin

Покотиленко Костик wrote:


есть роутер на котором настроено разделение канала по группам клиентов
(HTB). Сейчас в одной группе нужно сделать подгруппу для клиентов и
безлимитными пакетами. Для этого им нужно ограничить максимальную
скорость.

Вопрос: есть ли дисциплина позволяющая ограничивать максимальную
скорость до указанного значения для каждого IP отдельно, так чтобы не
нужно было для каждого следующего безлимитчика добавлять класс
ограничения?


Классы обслуживания должны создаваться в любом случае, иначе как тогда 
будет работать планировщик. Динамическое создание классов по приходу 
пакета с указанного IP не реализовано.


Много классов -- это не проблема, их можно нагенерировать скриптами 
сколько угодно. Проблема в том, что для классификации трафика нужно 
много фильтров, что приводит к расходу процессорного времени, т.к. их 
нужно обходить при каждом получении пакета. Если будет по одному IP на 
класс, то лучше всего воспользоваться фильтром fw и модулем IPMARK, либо 
модулем IPCLASSIFY, который работает напрямую без фильтров tc. Примеры 
легко ищутся в документациях к модулям. Также в u32 реализованы т.н. 
хэширующие фильтры (см. lartc.org), но с ними наборы правил будут 
намного сложнее.



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Ограничение макси мальной скорости по I P

2008-01-16 Пенетрантность Stanislav Kruchinin

Покотиленко Костик wrote:


В iptables есть такой модуль limit, классификатор которого срабатывает,
например, раз в 5 секунд. А есть модуль hashlimit, который делает то же
самое, только, например, для каждого IP отправителя отдельный счётчик.



Это очень красивое решение, оно позволяет одним правилом выставить
честно ограничения, а не так что один пользователь пингует сайт 10 раз в
секунду, а другие не могут вообще.


Просто сделайте то, о чем я уже говорил: скрипт, создающий классы для 
всех IP и правила iptables, которые будут делать маркировку пакетов с 
помощью IPMARK или классификацию с IPCLASSIFY. Здесь просто слово хэш 
явно не употребляется, но суть такая же: одним правилом можно 
маркировать/классифицировать пакеты сразу со всех IP из нужной подсети. 
А ipset для этих целей не нужен.




По аналогии, мне бы TBF, только чтобы hashTBF. Такое есть?


Такое есть во FreeBSDшном dummynet. В Linux массовый шейпинг делается 
более грамотно -- классовыми дисциплинами (HTB, CBQ) и классификацией на 
основе полей заголовков пакетов, а не какими-то хаками в виде кучи 
независимых token buckets.



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Ограничение макси мальной скорости по I P

2008-01-16 Пенетрантность Nicholas

Stanislav Kruchinin wrote:
Если будет по одному IP на 
класс, то лучше всего воспользоваться фильтром fw и модулем IPMARK, либо 
модулем IPCLASSIFY, который работает напрямую без фильтров tc. Примеры 
легко ищутся в документациях к модулям. Также в u32 реализованы т.н. 
хэширующие фильтры (см. lartc.org), но с ними наборы правил будут 
намного сложнее.


Вы могли бы подсказать, есть ли преимущества IPMARK либо IPCLASSIFY 
перед u32 ?
При каком количестве фильтров это может начать проявляться на практике и 
как это можно посчитать теоретически ?



--
Sincerely,
Nicholas


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]