pf

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

pf

irix
Интересно когда в pf добавят возможность созлавать одним статическим
правилом 254 динамических.
Примером являеться возможность ipfw
ipfw pipe 10 config mask dst-ip 0xFFffFFff bw 892Kb/s
Т.е по маске создавать динамические правила для подсети
Может быть есть патчик какой-нибудь
Ссылочку выложите :)


Reply | Threaded
Open this post in threaded view
|

Re: pf

Alexander Sheiko
Hello irix,

Monday, December 10, 2007, 1:20:23 AM, you wrote:

i> Интересно когда в pf добавят возможность созлавать одним статическим
i> правилом 254 динамических.
i> Примером являеться возможность ipfw
i> ipfw pipe 10 config mask dst-ip 0xFFffFFff bw 892Kb/s
i> Т.е по маске создавать динамические правила для подсети

Да - этой штуки там действительно не хватает. Только не обязательно
254, всё зависит от маски...

Очень не хватает аналога вот такого:

pipe 100 config bw 5Mbit/s

queue 100 config weight 20 pipe 100 queue 60 mask dst-ip 0xffffffff gred 0.002/10/30/0.1
queue 300 config weight 80 pipe 100 queue 60 mask dst-ip 0xffffffff gred 0.002/10/30/0.1

add queue 100 tcp from 193.41.88.18 to not 10.28.0.0/22 via fxp0 out
add queue 300 tcp from 193.41.88.18 to 10.28.0.0/22 via fxp0 out


--
Best regards,
 Alexander                            mailto:[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: pf

Stanislav Kruchinin
Alexander Sheiko wrote:
> Hello irix,
>
> Monday, December 10, 2007, 1:20:23 AM, you wrote:
>
> i> Интересно когда в pf добавят возможность созлавать одним статическим
> i> правилом 254 динамических.
> i> Примером являеться возможность ipfw
> i> ipfw pipe 10 config mask dst-ip 0xFFffFFff bw 892Kb/s
> i> Т.е по маске создавать динамические правила для подсети

А чем FreeBSD для этой цели не устраивает? Или Linux с классификацией
трафика по IP-адресам (фильтр u32 с хэшированием или fw с IPMARK или
IPCLASSIFY)? Следует просто использовать те системы, в которых нужный
функционал уже реализован. В этом состоит одна из свобод open source.


Reply | Threaded
Open this post in threaded view
|

Re[2]: pf

irix
Hello Stanislav,

Monday, December 10, 2007, 10:34:12 AM, you wrote:

SK> Alexander Sheiko wrote:
>> Hello irix,
>>
>> Monday, December 10, 2007, 1:20:23 AM, you wrote:
>>
>> i> Интересно когда в pf добавят возможность созлавать одним статическим
>> i> правилом 254 динамических.
>> i> Примером являеться возможность ipfw
>> i> ipfw pipe 10 config mask dst-ip 0xFFffFFff bw 892Kb/s
>> i> Т.е по маске создавать динамические правила для подсети

SK> А чем FreeBSD для этой цели не устраивает? Или Linux с классификацией
SK> трафика по IP-адресам (фильтр u32 с хэшированием или fw с IPMARK или
SK> IPCLASSIFY)? Следует просто использовать те системы, в которых нужный
SK> функционал уже реализован. В этом состоит одна из свобод open source.




Рассылка вроде посвящена OpenBSD :)


--
Best regards,
 irix                            mailto:[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: pf

Alexander Sheiko
In reply to this post by Stanislav Kruchinin

----- Original Message -----
From: "Stanislav Kruchinin" <[hidden email]>
To: <[hidden email]>
Sent: Monday, December 10, 2007 10:34 AM
Subject: Re: pf


> А чем FreeBSD для этой цели не устраивает? Или Linux с классификацией
> трафика по IP-адресам (фильтр u32 с хэшированием или fw с IPMARK или
> IPCLASSIFY)? Следует просто использовать те системы, в которых нужный
> функционал уже реализован. В этом состоит одна из свобод open source.

Дело в том, что во FreeBSD dummynet нет средств предоставления
гарантированной полосы при шейпинге, с возможностью динамического
заимствования пустующего канала. Как и средств предотвращения голодания
отдельных классов.  В этом смысле altq намного гибче. Можно, конечно, юзать
последовательную связку ipfw + dummynet + altq (ipfw умеет загонять трафик в
altq каналы), но это немного изврат.

P.S. Линукс - не наша религия (BSD-шников) :)...


Reply | Threaded
Open this post in threaded view
|

Re[2]: pf

Dinar Talypov
In reply to this post by Stanislav Kruchinin
Добрый день Stanislav,

Monday, December 10, 2007, 11:34:12 AM, you wrote:

SK> Alexander Sheiko wrote:
>> Hello irix,
>>
>> Monday, December 10, 2007, 1:20:23 AM, you wrote:
>>
>> i> Интересно когда в pf добавят возможность созлавать одним статическим
>> i> правилом 254 динамических.
>> i> Примером являеться возможность ipfw
>> i> ipfw pipe 10 config mask dst-ip 0xFFffFFff bw 892Kb/s
>> i> Т.е по маске создавать динамические правила для подсети

SK> А чем FreeBSD для этой цели не устраивает? Или Linux с классификацией
SK> трафика по IP-адресам (фильтр u32 с хэшированием или fw с IPMARK или
SK> IPCLASSIFY)? Следует просто использовать те системы, в которых нужный
SK> функционал уже реализован. В этом состоит одна из свобод open source.



А зачем вообще создавать правила?
Чем больше правил, тем больше времени требуется для прохождения этих
правил.

--
С уважением,
Динар Талыпов
ООО "Камател-Янтел"
т.(8555)45-17-45                      


Reply | Threaded
Open this post in threaded view
|

Re: pf

Stanislav Kruchinin
In reply to this post by Alexander Sheiko
Alexander Sheiko wrote:
> Дело в том, что во FreeBSD dummynet нет средств предоставления
> гарантированной полосы при шейпинге, с возможностью динамического
> заимствования пустующего канала. Как и средств предотвращения голодания
> отдельных классов.  В этом смысле altq намного гибче. Можно, конечно, юзать
> последовательную связку ipfw + dummynet + altq (ipfw умеет загонять трафик в
> altq каналы), но это немного изврат.

Тогда из opensource-решений ничего толком не остается, кроме
использования tc с дисциплиной htb и теми фильтрами, о которых я писал.

> P.S. Линукс - не наша религия (BSD-шников) :)...

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


Reply | Threaded
Open this post in threaded view
|

Re: pf

Stanislav Kruchinin
In reply to this post by Dinar Talypov
Dinar Talipov wrote:
>
> А зачем вообще создавать правила?
> Чем больше правил, тем больше времени требуется для прохождения этих
> правил.
>

Если каким-то образом хэшировать классы обслуживания по IP-адресам,
тогда время прохождения правил всегда будет постоянным.


Reply | Threaded
Open this post in threaded view
|

Re[2]: pf

irix
In reply to this post by Alexander Sheiko
Hello Alexander,

Monday, December 10, 2007, 11:43:53 AM, you wrote:

AS> ----- Original Message -----
AS> From: "Stanislav Kruchinin" <[hidden email]>
AS> To: <[hidden email]>
AS> Sent: Monday, December 10, 2007 10:34 AM
AS> Subject: Re: pf


>> А чем FreeBSD для этой цели не устраивает? Или Linux с классификацией
>> трафика по IP-адресам (фильтр u32 с хэшированием или fw с IPMARK или
>> IPCLASSIFY)? Следует просто использовать те системы, в которых нужный
>> функционал уже реализован. В этом состоит одна из свобод open source.

AS> Дело в том, что во FreeBSD dummynet нет средств предоставления
AS> гарантированной полосы при шейпинге, с возможностью динамического
AS> заимствования пустующего канала. Как и средств предотвращения голодания
AS> отдельных классов.  В этом смысле altq намного гибче. Можно, конечно, юзать
AS> последовательную связку ipfw + dummynet + altq (ipfw умеет загонять трафик в
AS> altq каналы), но это немного изврат.

AS> P.S. Линукс - не наша религия (BSD-шников) :)...

По делу что-то будет ?


--
Best regards,
 irix                            mailto:[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re[2]: pf

Dinar Talypov
In reply to this post by Stanislav Kruchinin
Добрый день Stanislav,

Monday, December 10, 2007, 1:10:55 PM, you wrote:

SK> Dinar Talipov wrote:
>>
>> А зачем вообще создавать правила?
>> Чем больше правил, тем больше времени требуется для прохождения этих
>> правил.
>>

SK> Если каким-то образом хэшировать классы обслуживания по IP-адресам,
SK> тогда время прохождения правил всегда будет постоянным.

Вот каким это образом можно хешировать?
Все равно для сравнения 10 правил будет выигрывать по скорости 1000 правил.
Все зависит от того как правила писать.
Далее это уже флейм, можно тему закрывать :)


--
С уважением,
Динар Талыпов
ООО "Камател-Янтел"
т.(8555)45-17-45                      


Reply | Threaded
Open this post in threaded view
|

Re: pf

Mike Belopuhov
In reply to this post by irix
irix wrote:
> Интересно когда в pf добавят возможность созлавать одним статическим
> правилом 254 динамических.

я полагаю, что никогда, по крайней мере пока что-то коренным
образом не поменяется.

> Примером являеться возможность ipfw

это, имхо, маразм.
я когда-то давно, ожидал, что правило вида

   pass out from <table> ... queue q_lak

будет создавать динамическую очередь вида q_lak для каждой
записи из <table>.

однако, насколько я понимаю (я не очень вдавался в подробности),
для этого нужно решить ряд вопросов:

1. как аттачить эти очереди к родительской очереди;

2. как бороться с тем что суммарная пропускная способность
    этих динамических очередей будет больше пропускной
    способности родительской очереди;

3. возможно что-то еще;

насчет пункта 2 есть сомнения ибо cbq (hfsc?) считает что мы
делим канал на очереди честно и их пропускная способность никак
не должна превышать bw родительской очереди, в то время как
во freebsd реализация этого не предполагает (можно определять
пайпы с любым bw без родителей вообще).

с одной стороны реализация во фряхе не соответствует моему
представлению о полноценном QoS, с другой стороны это соответсвует
ожиданиям ISP с кучей пользователей, которые нагружают parent queue
на 30% в среднем но имеют пики в пределах своей полосы пропускания,
не изменяя результирующего соотношения.

таким образом, я всегда рассматриваю altq/cbq как возможность
управления трафиком в масштабах сетей, а не отдельных пользователей,
где важно не превышать bw родительской очереди и т.д.
в таком контексте вышеуказаное правило выглядит вполне уместно.

не претендую на 100% корректность изложения и буду рад если
кто поправит :-)

--
you're never too old to rock'n'roll if you're too young to die.


Reply | Threaded
Open this post in threaded view
|

Re: pf

Stanislav Kruchinin
In reply to this post by Dinar Talypov
Dinar Talipov wrote:
>
> Вот каким это образом можно хешировать?

Это когда ID класса обслуживания вычисляется из IP-адреса, взятого из
заголовка пакета. При этом пакет не нужно прогонять через все правила
классификации трафика до первого совпадения.

> Все равно для сравнения 10 правил будет выигрывать по скорости 1000 правил.

Среднее время поиска для хэша -- O(1), т.е. не зависит от количества
записей.

> Все зависит от того как правила писать.
> Далее это уже флейм, можно тему закрывать :)

Да.


Reply | Threaded
Open this post in threaded view
|

Re: pf

Mike Belopuhov
Stanislav Kruchinin wrote:
> Dinar Talipov wrote:
>> Вот каким это образом можно хешировать?
>
> Это когда ID класса обслуживания вычисляется из IP-адреса, взятого из
> заголовка пакета. При этом пакет не нужно прогонять через все правила
> классификации трафика до первого совпадения.
>

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

>> Все равно для сравнения 10 правил будет выигрывать по скорости 1000 правил.
>
> Среднее время поиска для хэша -- O(1), т.е. не зависит от количества
> записей.
>

часто (а может и там про то, что ты говоришь) используются хэши, одним
элементом которых является ссылка на другой хэш и так далее. тут время
поиска уже не O(1). это раз.  а два это то, что сложность алгоритма O(1)
совсем не означает его абслютную быстроту. он может быть O(1) для всех
наборов входных данных, но очень медленным.  это тоже надо учитывать,
а не преподносить хэш как решение всех проблем.  + хэши кушают память.

>> Все зависит от того как правила писать.
>> Далее это уже флейм, можно тему закрывать :)
>
> Да.
>
>

--
you're never too old to rock'n'roll if you're too young to die.


Reply | Threaded
Open this post in threaded view
|

Re[2]: pf

irix
In reply to this post by Mike Belopuhov
Hello Mike,

Monday, December 10, 2007, 4:39:42 PM, you wrote:

MB> irix wrote:
>> Интересно когда в pf добавят возможность созлавать одним статическим
>> правилом 254 динамических.

MB> я полагаю, что никогда, по крайней мере пока что-то коренным
MB> образом не поменяется.

>> Примером являеться возможность ipfw

MB> это, имхо, маразм.
MB> я когда-то давно, ожидал, что правило вида

MB>    pass out from <table> ... queue q_lak

MB> будет создавать динамическую очередь вида q_lak для каждой
MB> записи из <table>.

MB> однако, насколько я понимаю (я не очень вдавался в подробности),
MB> для этого нужно решить ряд вопросов:

MB> 1. как аттачить эти очереди к родительской очереди;

MB> 2. как бороться с тем что суммарная пропускная способность
MB>     этих динамических очередей будет больше пропускной
MB>     способности родительской очереди;

MB> 3. возможно что-то еще;

MB> насчет пункта 2 есть сомнения ибо cbq (hfsc?) считает что мы
MB> делим канал на очереди честно и их пропускная способность никак
MB> не должна превышать bw родительской очереди, в то время как
MB> во freebsd реализация этого не предполагает (можно определять
MB> пайпы с любым bw без родителей вообще).

MB> с одной стороны реализация во фряхе не соответствует моему
MB> представлению о полноценном QoS, с другой стороны это соответсвует
MB> ожиданиям ISP с кучей пользователей, которые нагружают parent queue
MB> на 30% в среднем но имеют пики в пределах своей полосы пропускания,
MB> не изменяя результирующего соотношения.

MB> таким образом, я всегда рассматриваю altq/cbq как возможность
MB> управления трафиком в масштабах сетей, а не отдельных пользователей,
MB> где важно не превышать bw родительской очереди и т.д.
MB> в таком контексте вышеуказаное правило выглядит вполне уместно.

MB> не претендую на 100% корректность изложения и буду рад если
MB> кто поправит :-)


Вот коротко и по делу :)
Спасибо , вкурил :)

--
Best regards,
 irix                            mailto:[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: pf

Stanislav Kruchinin
In reply to this post by Mike Belopuhov
Mike Belopuhov wrote:
>
> часто (а может и там про то, что ты говоришь) используются хэши, одним
> элементом которых является ссылка на другой хэш и так далее. тут время
> поиска уже не O(1). это раз.  а два это то, что сложность алгоритма O(1)
> совсем не означает его абслютную быстроту. он может быть O(1) для всех
> наборов входных данных, но очень медленным.  это тоже надо учитывать,
> а не преподносить хэш как решение всех проблем.  + хэши кушают память.
>

В данном примере происходит копирование двойного слова (IP-адреса) из
памяти, и простейшие бинарные операции над ним, поэтому это быстро.
Самих хэшей вида ip => classid в памяти вообще нет, вычисление номера
класса происходит во время обработки пакета. Фильтры u32 занимают
память, но в больших количествах они нужны только в экзотических
случаях. Кроме того, память сейчас не самый дорогой ресурс.

Чехарда с двойными хэшами и усложнение правил в tc начинаются, если
нужно классифицировать трафик одновременно по нескольким признакам. Это
упростить засчет шейпинга на дополнительной машине или на псевдоустройствах.