1. Как Вы используете PF ?

[Skylord]

Во фре pf находиться на уровне 4.1 openbsd, уже openbsd 4.6 на подходе изменений в pf выше крыши между 4.1 и 4.6.

Это да, но мы имеет то, что имеем... По факту получается, что если хочется более новый pf - надо менять ОС, но тогда возникает вопрос - является ли это оправданным, учитывая, что все что нужно и так нормально делается на ipfw? Хотя, конечно, если изначально стоит OpenBSD - то это другое дело. :-)

 

ALTQ изначально не являеться шейпером, это QoS фреймвёрк, шейпинг это лишь побочный продукт.

Если так хочеться именно ALTQ, то в NetBSD (pf/altq там тоже есть на уровне openbsd 4.2)ещё сохранился altqd изначальный, у него функционал побольше чем у pf/altq (не полноценный порт), может быть он подойдёт.

Про pf/altq, наверно мало кто знает, что когда делали этот порт в нём ещё заложили функцию ALTQ_CDNR, но в силу каких то причин его не доделали. В ядро портировали а вот сам pf, его понимать не научили. Эта опция позволяет делать простейший policing для входящего траффика, если трафик превышает заданный rate limit то он дропаеться, проше говоря будет "шейпинг входящего траффика"(хотя шейпингом там и не пахнет :))). На его основе ещё сделан трёхцветный маркер который может метить пакеты в зависимости от их rate limit'a.

Вообще кому интересно, может доделать :)

Фишка в том, что мы понимаем, что altq - не шейпер, а QoS, но тогда вопрос - чем шейпить, если используется pf? Чем вообще народ в OpenBSD шейпит? Чтобы функционал был аналогичен dummynet, который шейпит во всех направлениях и любых возможных конфигурациях, причем при использовании таблиц и tablearg это к тому же получается эстетически привлекательно. :-)

[windows_NT]

Во фре pf находиться на уровне 4.1 openbsd, уже openbsd 4.6 на подходе изменений в pf выше крыши между 4.1 и 4.6.

Это да, но мы имеет то, что имеем... По факту получается, что если хочется более новый pf - надо менять ОС, но тогда возникает вопрос - является ли это оправданным, учитывая, что все что нужно и так нормально делается на ipfw? Хотя, конечно, если изначально стоит OpenBSD - то это другое дело. :-)

 

ALTQ изначально не являеться шейпером, это QoS фреймвёрк, шейпинг это лишь побочный продукт.

Если так хочеться именно ALTQ, то в NetBSD (pf/altq там тоже есть на уровне openbsd 4.2)ещё сохранился altqd изначальный, у него функционал побольше чем у pf/altq (не полноценный порт), может быть он подойдёт.

Про pf/altq, наверно мало кто знает, что когда делали этот порт в нём ещё заложили функцию ALTQ_CDNR, но в силу каких то причин его не доделали. В ядро портировали а вот сам pf, его понимать не научили. Эта опция позволяет делать простейший policing для входящего траффика, если трафик превышает заданный rate limit то он дропаеться, проше говоря будет "шейпинг входящего траффика"(хотя шейпингом там и не пахнет :))). На его основе ещё сделан трёхцветный маркер который может метить пакеты в зависимости от их rate limit'a.

Вообще кому интересно, может доделать :)

Фишка в том, что мы понимаем, что altq - не шейпер, а QoS, но тогда вопрос - чем шейпить, если используется pf? Чем вообще народ в OpenBSD шейпит? Чтобы функционал был аналогичен dummynet, который шейпит во всех направлениях и любых возможных конфигурациях, причем при использовании таблиц и tablearg это к тому же получается эстетически привлекательно. :-)

В OpenBSD народ вообще-то почти не шейпит, это так, паграничный мушутизатор (фиревал) или BGP бордер. :)

 

Поэтому там это дело и слабо развито, но если и шейпят то только подсетями (/24, /16), а не на каждый ip.

 

Вот если бы ALTQ_CDNR доделали, то на основе трёг цветного маркера можно было бы ещё динамический шейпер организовать (ограничивать скорость в зависимости от количества скаченных гигабайт в определённый перод времени ) :)

[photon]

В OpenBSD народ вообще-то почти не шейпит, это так, паграничный мушутизатор (фиревал) или BGP бордер. :)

OpenBSD не для провайдеров, т.к. не держит больших нагрузок и не масштабируется на многопроцессорных системах. Ядро до сих пор с giant locks, прерывания обрабатываются только одним процессором. В чистую сливает аналогичным решениям на FreeBSD и Linux. В OpenBSD не только маршрутизация, а весь сетевой стек тормозной, потому что остался на уровне 4.4BSD. Думаете, на чем крутится их веб-сервер www.openbsd.org? На Solaris, т.к. OpenBSD элементарно не выдержит большого числа запросов.

Изменено 9 июля, 2009 пользователем photon

[Skylord]

Это уже пошли более философские дебаты... :-) Впрочем, я тоже считаю, что людям из OpenBSD лучше перестать тратить время на свою ОС, а заниматься разработкой того, что у них хорошо получается и чем пользуются все остальные. :-)

Так что, ИМХО, топик пришел к своему логическому завершения: pf никто не использует для шейпинга, dummynet - рулит. :-)

[Giga-Byte]

я описывал не так давно как работала у нас дисциплина hfsc:

http://forum.nag.ru/forum/index.php?showto...rt=#entry394651

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

был самописный измеритель скорости по каждой очереди и рисовал в реальном времени какой приоритет сколько отжирает

Можете более подробно описать как вы это делали на hfsc с примерами конфигов ?

есть у меня два конфига

bw=7Mb

# HFSC
altq on $if_int bandwidth 100Mb hfsc queue { def unlimit_out unlimit }
queue def bandwidth 80Mb hfsc (default)

#queue unlimit_out bandwidth $bw qlimit 5000 hfsc (upperlimit($bw 0 $bw)) { traf1 unlim1 }
#queue traf1  bandwidth 65% qlimit 2000 priority 6 hfsc ( realtime(0Kb 0 65%) linkshare(65% 0 65%) upperlimit(95% 0 95%) )
#queue unlim1 bandwidth 35% qlimit 3000 priority 3 hfsc ( realtime(0Kb 0 35%) linkshare(35% 0 35%) upperlimit(95% 0 95%) )

queue unlimit bandwidth $bw qlimit 6000 hfsc (upperlimit($bw 0 $bw)) { games traf unlim unlim_slow }

queue games bandwidth 1% qlimit 200 priority 7 hfsc ( realtime(0% 0 5%) linkshare(0% 0 1%)  upperlimit(20% 0 20%) )

queue traf  bandwidth 25% qlimit 500 priority 6 hfsc ( realtime(0Kb 0 50%) linkshare(25% 0 25%) upperlimit(98% 0 98%) )
#queue traf  bandwidth 1% qlimit 500 priority 6 hfsc ( realtime(0Kb 0 95%) linkshare(1% 0 1%) upperlimit(95% 0 95%) )

queue unlim bandwidth 69% qlimit 3000 priority 3 hfsc ( realtime(0Kb 0 40%) linkshare(69% 0 69%) upperlimit(98% 0 98%) )
#queue unlim bandwidth 1% qlimit 3000 priority 3 hfsc ( realtime(0Kb 0 95%) linkshare(1% 0 1%) upperlimit(95% 0 95%) )

queue unlim_slow bandwidth 5% qlimit 3000 priority 0 hfsc ( realtime(0Kb 0 5%) linkshare (5% 0 5%) upperlimit(98% 0 98%) )
#queue unlim_slow bandwidth 1% qlimit 3000 priority 0 hfsc ( realtime(0Kb 0 7%) linkshare (1% 0 1%) upperlimit(95% 0 95%) )
# ----
# QUEUEing
pass in quick route-to (em0 217.116.62.250) from { 74.53.215.4 74.53.215.6 64.69.36.241 85.17.154.41 206.127.153.147 } to { <tab_traf_vpn2> <tab_unlim_vpn2> <tab_sunlim_vpn2> } queue games
pass in quick route-to (em0 217.116.62.250) proto tcp from port { 8687 2106 7777 6112 3724 } to { <tab_traf_vpn2> <tab_unlim_vpn2> <tab_sunlim_vpn2> } queue games
pass in quick route-to (em0 217.116.62.250) proto udp from port { 27005:27050 } to { <tab_traf_vpn2> <tab_unlim_vpn2> <tab_sunlim_vpn2> } queue games
pass in quick route-to (em0 217.116.62.250) to <tab_traf_vpn2> queue traf
pass in quick route-to (em0 217.116.62.250) to <tab_unlim_vpn2> queue unlim
pass in quick route-to (em0 217.116.62.250) to <tab_sunlim_vpn2> queue unlim_slow

 

bw=7Mb

# HFSC
altq on $if_int bandwidth 100Mb hfsc queue { def unlimit_out unlimit }
queue def bandwidth 80Mb hfsc (default)

#queue unlimit_out bandwidth $bw qlimit 5000 hfsc (upperlimit($bw 0 $bw)) { traf1 unlim1 }
#queue traf1  bandwidth 65% qlimit 2000 priority 6 hfsc ( realtime(0Kb 0 65%) linkshare(65% 0 65%) upperlimit(95% 0 95%) )
#queue unlim1 bandwidth 35% qlimit 3000 priority 3 hfsc ( realtime(0Kb 0 35%) linkshare(35% 0 35%) upperlimit(95% 0 95%) )

queue unlimit bandwidth $bw qlimit 6000 hfsc (upperlimit($bw 0 $bw)) { games traf unlim unlim_slow }

queue games bandwidth 1% qlimit 200 priority 7 hfsc ( realtime(0% 0 5%) linkshare(0% 0 1%)  upperlimit(20% 0 20%) )
queue traf  bandwidth 25% qlimit 500 priority 6 hfsc ( realtime(0Kb 0 50%) linkshare(25% 0 25%) upperlimit(98% 0 98%) )
#queue traf  bandwidth 1% qlimit 500 priority 6 hfsc ( realtime(0Kb 0 95%) linkshare(1% 0 1%) upperlimit(95% 0 95%) )

queue unlim bandwidth 69% qlimit 3000 priority 3 hfsc ( realtime(0Kb 0 40%) linkshare(69% 0 69%) upperlimit(98% 0 98%) )
#queue unlim bandwidth 1% qlimit 3000 priority 3 hfsc ( realtime(0Kb 0 95%) linkshare(1% 0 1%) upperlimit(95% 0 95%) )

queue unlim_slow bandwidth 5% qlimit 3000 priority 0 hfsc ( realtime(0Kb 0 5%) linkshare (5% 0 5%) upperlimit(98% 0 98%) )
#queue unlim_slow bandwidth 1% qlimit 3000 priority 0 hfsc ( realtime(0Kb 0 7%) linkshare (1% 0 1%) upperlimit(95% 0 95%) )
# ----


pass in quick from { 74.53.215.4 74.53.215.6 64.69.36.241 85.17.154.41 206.127.153.147 } to { <tab_traf_vpn2> <tab_unlim_vpn2> <tab_sunlim_vpn2> } queue games
pass in quick proto tcp from port { 8687 2106 7777 6112 3724 } to { <tab_traf_vpn2> <tab_unlim_vpn2> <tab_sunlim_vpn2> } queue games
pass in quick proto udp from port { 27005:27050 } to { <tab_traf_vpn2> <tab_unlim_vpn2> <tab_sunlim_vpn2> } queue games
pass in quick proto icmp to { <tab_traf_vpn2> <tab_unlim_vpn2> <tab_sunlim_vpn2> } queue games
pass in quick to <tab_traf_vpn2> queue traf
pass in quick to <tab_unlim_vpn2> queue unlim
pass in quick to <tab_sunlim_vpn2> queue unlim_slow

 

эти два конфига датированы 3-им и 4-ым ноябрём 2007 года. почему их два и в чем различия - не помню.

 

 

могу ещё софтинку выкинуть на всеобщее обозрение.

как она строила график нагрузки в реальном времени. она собственно и сейчас работает, только канал уже не 7Мбит а 90

(написана на Си с использованием libpcap и gd, отдаёт картинку по http в формате png)

Изменено 9 июля, 2009 пользователем Giga-Byte

[windows_NT]

Это уже пошли более философские дебаты... :-) Впрочем, я тоже считаю, что людям из OpenBSD лучше перестать тратить время на свою ОС, а заниматься разработкой того, что у них хорошо получается и чем пользуются все остальные. :-)

Так что, ИМХО, топик пришел к своему логическому завершения: pf никто не использует для шейпинга, dummynet - рулит. :-)

Хорошо, вы правы. Не буду вас переубеждать :)

 

Это уже пошли более философские дебаты... :-) Впрочем, я тоже считаю, что людям из OpenBSD лучше перестать тратить время на свою ОС, а заниматься разработкой того, что у них хорошо получается и чем пользуются все остальные. :-)

Ну собственно ОС у них очень хорошо получаеться. А пишут они "свой" софт не из любви к исскуству, а из-за необходимости :)

 

Вон уже свой smtpd написали :)

 

Да, есть определённые недостатки. Но на двух бгп бордерах и трёх пограничных фиревалах у меня, зарекомендовала себя очень хорошо.

 

Так что, ИМХО, топик пришел к своему логическому завершения: pf никто не использует для шейпинга, dummynet - рулит. :-)

Ну соственно дурнойнэт не рулит и заканчиваеться там где нужно "чучуть гибкости", просто в настройке - да, возможность настройки - нет.

Там где нужно хитрожопа или как угодно делать шапинг с qos , даёт джазу линукс. Как угодно - да, просто в настройке - не всегда.

 

Собственно вывод темы такой.

 

1) "Можно ли использовать pf/altq для провайдерского шейпинга ?" - Да, но с некоторыми оговорками. Производить шейпинг и QoS не per ip, а per subnet. Per ip получается сильно громоздко и не удобно.

 

2) "Что подойдёт для "самого примитивного" шейпинга per ip ?" - Для этого лучше всего подходит dummynet. Но если нужно больше чем "примитивный шейпинг", он уже не подходит.

 

3) "Что подойдёт для чуть больше чем "примитивный шейпинг", например с добавлением к шейпингу ещё и частичного QoS в рамках Per ip ?" - Для этого лучше всего на данный момент подойдёт линукс. Да, там не так всё просто и линейно как в dummynet, но там можно описать практически любую интерсующую вас конструкцию по управлению трафиком.

Изменено 9 июля, 2009 пользователем windows_NT

[Skylord]

Это уже пошли более философские дебаты... :-) Впрочем, я тоже считаю, что людям из OpenBSD лучше перестать тратить время на свою ОС, а заниматься разработкой того, что у них хорошо получается и чем пользуются все остальные. :-)

Ну собственно ОС у них очень хорошо получаеться. А пишут они "свой" софт не из любви к исскуству, а из-за необходимости :)

Вон уже свой smtpd написали :)

Так я о том и говорю! :-) Их бы энтузиазм не распылять на ОС, а направить в верное русло. Жалко только, что этот самый энтузиазм растет у них оттуда же, откуда и желание писать свою ОС, так что вряд ли что-то получится конструктивное... С Тео, по-моему, ни у кого ничего конструктивного не получается.... :-)

 

Да, есть определённые недостатки. Но на двух бгп бордерах и трёх пограничных фиревалах у меня, зарекомендовала себя очень хорошо.

Это гуд, никто не спорит. Но тут же обсуждается конкретная задача - шейпинг. Вот у меня на бордере еще и НАТ с шейпером per-ip стоял (ну и стоит сейчас, только он уже не мой ;-) ). На OpenBSD это сделать ведь не получилось бы...

 

Ну соственно дурнойнэт не рулит и заканчиваеться там где нужно "чучуть гибкости", просто в настройке - да, возможность настройки - нет.

Там где нужно хитрожопа или как угодно делать шапинг с qos , даёт джазу линукс. Как угодно - да, просто в настройке - не всегда.

Мммм.... Это как-то слишком общО. То есть, я соглашаюсь с тем, что возможности по приоретизации трафика в dummynet ограничены и всегда вообще подчеркивалось, что это не вполне QoS, однако многих это на практике вполне устраивает: ну нельзя назначить разному трафику разные приоритеты, зато можно выделить минимально-гарантированную полосу. Для решения конкретных юзерских задач (из серии - гарантировать выпуск VoIP и при необходимости притормаживать FTP) - этого вполне хватает. Приведи, пожалуйста, пример конкретной задачи, которая нерешаема адекватно на dummynet, но решаема на pf/altq (желательно - только последней его версии, чтобы был резон переходить на OpenBSD :-) ). И про линукс было бы интересно тоже.... Я не флейма для, а исключительно повышения уровня своего образования ради. :-)

 

Собственно вывод темы такой.

1) "Можно ли использовать pf/altq для провайдерского шейпинга ?" - Да, но с некоторыми оговорками. Производить шейпинг и QoS не per ip, а per subnet. Per ip получается сильно громоздко и не удобно.

Так. Давай определимся с терминами. Под шейпингом, например, лично я понимаю именно per-ip, т.к. некий абстрактный шейпинг никому не нужен, а нужно решать конкретную задачу - нарезать разные скорости пользователям с разными тарифами. Адекватного способа (не сильно громоздкого и удобного) сделать это на pf/altq нет. Сделать QoS - пожалуйста. Приоретизировать трафик одной группы пользователей перед другой или выдать каждой свою полосу - пожалуйста. Но осуществить задачу нарезки пользователям скоростей в соответствии с тарифами - нет.

 

2) "Что подойдёт для "самого примитивного" шейпинга per ip ?" - Для этого лучше всего подходит dummynet. Но если нужно больше чем "примитивный шейпинг", он уже не подходит.

3) "Что подойдёт для чуть больше чем "примитивный шейпинг", например с добавлением к шейпингу ещё и частичного QoS в рамках Per ip ?" - Для этого лучше всего на данный момент подойдёт линукс. Да, там не так всё просто и линейно как в dummynet, но там можно описать практически любую интерсующую вас конструкцию по управлению трафиком.

Ну, как раз с этим не соглашусь. dummynet'овские queue могут быть точно также динамическими, как и pipe. Никто не мешает нарезать каждому полосу скорости, а потом внутри эту полосу через queue еще распределить на минимально гарантированные доли и загнать в каждую соответствующий трафик. Чем не QoS в рамках per-ip?

А при желании и вообще наворотить можно чего угодно. Например, еще до шейпинга отделить часть трафика (тот же VoIP), сделать глобальную queue, в которой ему отдать 99 процентов, соответственно у него всегда будет гарантия доставки, а вся остальная полоса будет отдаваться для простой нарезки. И делается это, кстати, совсем не сложно и не заморочено - в несколько строчек...

Так что я соглашусь с тем, что в ipfw/dummynet все, возможно, делается не настолько прозрачно с поверхности и немного не в тех понятиях, к которым большинство привыкло (и кстати, хотелось бы отметить ну просто мизерное, если оно вообще есть, количество примеров по работе с queue). Но это издержки "низкоуровневости" файрволла как такового. Всегда же ipfw сравнивают с языком низкого уровня, а тот же pf - соответственно, с языком высокого. И это так. А уж кому что ближе к работе - дело личное... :-)

[photon]

Ну, как раз с этим не соглашусь. dummynet'овские queue могут быть точно также динамическими, как и pipe. Никто не мешает нарезать каждому полосу скорости, а потом внутри эту полосу через queue еще распределить на минимально гарантированные доли и загнать в каждую соответствующий трафик. Чем не QoS в рамках per-ip?

dummynet более примитивен в том смысле, что он не реализует классовые дисциплины очереди. Следовательно, он не умеет строить произвольные деревья из дочерних классов (к pipe можно присоединить только queue, а строить иерархию из pipe нельзя) и не имеет возможности заема свободной полосы пропускания (параметры ceil или borrow). Такая возможность есть только у классовых дисциплин: HTB, CBQ, HFSC. В Linux реализованы почти все известные науке дисциплины очереди, поскольку его активно используют в академической среде. С одной стороны, это хорошо, но с другой -- довольно трудно разобраться.

[windows_NT]

Ну, как раз с этим не соглашусь. dummynet'овские queue могут быть точно также динамическими, как и pipe. Никто не мешает нарезать каждому полосу скорости, а потом внутри эту полосу через queue еще распределить на минимально гарантированные доли и загнать в каждую соответствующий трафик. Чем не QoS в рамках per-ip?

dummynet более примитивен в том смысле, что он не реализует классовые дисциплины очереди. Следовательно, он не умеет строить произвольные деревья из дочерних классов (к pipe можно присоединить только queue, а строить иерархию из pipe нельзя) и не имеет возможности заема свободной полосы пропускания (параметры ceil или borrow). Такая возможность есть только у классовых дисциплин: HTB, CBQ, HFSC. В Linux реализованы почти все известные науке дисциплины очереди, поскольку его активно используют в академической среде. С одной стороны, это хорошо, но с другой -- довольно трудно разобраться.

Там нету ничего трудного. Главное понять. Ну и в Linux JoBS дисциплины например нету, так что там далеко не всё, там куча хлама помимо всего прочего, половину тамошних шедулеров можно спокойно удалять :)

[windows_NT]

Это уже пошли более философские дебаты... :-) Впрочем, я тоже считаю, что людям из OpenBSD лучше перестать тратить время на свою ОС, а заниматься разработкой того, что у них хорошо получается и чем пользуются все остальные. :-)

Ну собственно ОС у них очень хорошо получаеться. А пишут они "свой" софт не из любви к исскуству, а из-за необходимости :)

Вон уже свой smtpd написали :)

Так я о том и говорю! :-) Их бы энтузиазм не распылять на ОС, а направить в верное русло. Жалко только, что этот самый энтузиазм растет у них оттуда же, откуда и желание писать свою ОС, так что вряд ли что-то получится конструктивное... С Тео, по-моему, ни у кого ничего конструктивного не получается.... :-)

Да на Тео, там всем, уже давно положить.

 

 

Да, есть определённые недостатки. Но на двух бгп бордерах и трёх пограничных фиревалах у меня, зарекомендовала себя очень хорошо.

Это гуд, никто не спорит. Но тут же обсуждается конкретная задача - шейпинг. Вот у меня на бордере еще и НАТ с шейпером per-ip стоял (ну и стоит сейчас, только он уже не мой ;-) ). На OpenBSD это сделать ведь не получилось бы...

Получилось бы прекрасно, только вносить изменения неудобно. И читать сложно.

 

Ну соственно дурнойнэт не рулит и заканчиваеться там где нужно "чучуть гибкости", просто в настройке - да, возможность настройки - нет.

Там где нужно хитрожопа или как угодно делать шапинг с qos , даёт джазу линукс. Как угодно - да, просто в настройке - не всегда.

Мммм.... Это как-то слишком общО. То есть, я соглашаюсь с тем, что возможности по приоретизации трафика в dummynet ограничены и всегда вообще подчеркивалось, что это не вполне QoS, однако многих это на практике вполне устраивает: ну нельзя назначить разному трафику разные приоритеты, зато можно выделить минимально-гарантированную полосу. Для решения конкретных юзерских задач (из серии - гарантировать выпуск VoIP и при необходимости притормаживать FTP) - этого вполне хватает. Приведи, пожалуйста, пример конкретной задачи, которая нерешаема адекватно на dummynet, но решаема на pf/altq (желательно - только последней его версии, чтобы был резон переходить на OpenBSD :-) ). И про линукс было бы интересно тоже.... Я не флейма для, а исключительно повышения уровня своего образования ради. :-)

Выделить пользователю на первые 4 секунды всю доступную полосу чтобы он быстро открывал странички месом до 3 мегабайт скажем, а потом скорость его урезалась до прописанной. При этом гарантируя что ack пакеты всегда будут уходить первыми и для них будет гарантирована полоса скажем в 64 килобита.

 

Собственно вывод темы такой.

1) "Можно ли использовать pf/altq для провайдерского шейпинга ?" - Да, но с некоторыми оговорками. Производить шейпинг и QoS не per ip, а per subnet. Per ip получается сильно громоздко и не удобно.

Так. Давай определимся с терминами. Под шейпингом, например, лично я понимаю именно per-ip, т.к. некий абстрактный шейпинг никому не нужен, а нужно решать конкретную задачу - нарезать разные скорости пользователям с разными тарифами. Адекватного способа (не сильно громоздкого и удобного) сделать это на pf/altq нет. Сделать QoS - пожалуйста. Приоретизировать трафик одной группы пользователей перед другой или выдать каждой свою полосу - пожалуйста. Но осуществить задачу нарезки пользователям скоростей в соответствии с тарифами - нет.

Не нет, а да. Всё это можно сделать на pf/altq только вот нужные правила в конфиге скажем на пару мегабайт вам врядли быстро удастся найти, если нужно будет внести изменения. Придётся полностью перегенерировать весь конфиг с нужными сам изменениями. Поэтому я говорю что "неудобно", но можно.

 

То что вы "понимаете под шейпингом" меня не касается, есть документ, который является стандартом и там написано что такое шейпинг.

 

Всё что касаеться темы "А Я это понимаю так....., а это вот так ......", меня не касаются. Есть документ стандарта, в котором чётко написано "что, есть что".

 

2) "Что подойдёт для "самого примитивного" шейпинга per ip ?" - Для этого лучше всего подходит dummynet. Но если нужно больше чем "примитивный шейпинг", он уже не подходит.

3) "Что подойдёт для чуть больше чем "примитивный шейпинг", например с добавлением к шейпингу ещё и частичного QoS в рамках Per ip ?" - Для этого лучше всего на данный момент подойдёт линукс. Да, там не так всё просто и линейно как в dummynet, но там можно описать практически любую интерсующую вас конструкцию по управлению трафиком.

Ну, как раз с этим не соглашусь. dummynet'овские queue могут быть точно также динамическими, как и pipe. Никто не мешает нарезать каждому полосу скорости, а потом внутри эту полосу через queue еще распределить на минимально гарантированные доли и загнать в каждую соответствующий трафик. Чем не QoS в рамках per-ip?

А при желании и вообще наворотить можно чего угодно. Например, еще до шейпинга отделить часть трафика (тот же VoIP), сделать глобальную queue, в которой ему отдать 99 процентов, соответственно у него всегда будет гарантия доставки, а вся остальная полоса будет отдаваться для простой нарезки. И делается это, кстати, совсем не сложно и не заморочено - в несколько строчек...

Так что я соглашусь с тем, что в ipfw/dummynet все, возможно, делается не настолько прозрачно с поверхности и немного не в тех понятиях, к которым большинство привыкло (и кстати, хотелось бы отметить ну просто мизерное, если оно вообще есть, количество примеров по работе с queue). Но это издержки "низкоуровневости" файрволла как такового. Всегда же ipfw сравнивают с языком низкого уровня, а тот же pf - соответственно, с языком высокого. И это так. А уж кому что ближе к работе - дело личное... :-)

Это больше похоже уже на "за упокойную".

 

Тут вы пытаетесь представить dummynet, чем он не являеться. Как бы вам этого не хотелось этим он не станет. Смиритесь.

 

Автор dummynet вложил функционал - и чётко написал может это, это и это. Всё остальное не может. Всё.

 

Сравнивать ipfw и pf, глупое бессмысленное занятие. Отложим.

[drurus]

Во-вторых, правила нельзя редактировать из командной строки по одному, они все загружаются из файла pf.conf.

Ну да, прям нельзя:

echo 'deny on tun0 from 10.20.30.2 to 192.168.1.129' | pfctl -mf -

[Skylord]

Да на Тео, там всем, уже давно положить.

Оставлю это без комментариев. :-) Ну положить - и положить... Тем лучше. Глядишь, и забьют действительно на все это...

 

Да, есть определённые недостатки. Но на двух бгп бордерах и трёх пограничных фиревалах у меня, зарекомендовала себя очень хорошо.

Это гуд, никто не спорит. Но тут же обсуждается конкретная задача - шейпинг. Вот у меня на бордере еще и НАТ с шейпером per-ip стоял (ну и стоит сейчас, только он уже не мой ;-) ). На OpenBSD это сделать ведь не получилось бы...

Получилось бы прекрасно, только вносить изменения неудобно. И читать сложно.

Это мне кажется, или вторая часть фразы вступает в противоречие с первой? :-)

 

Выделить пользователю на первые 4 секунды всю доступную полосу чтобы он быстро открывал странички месом до 3 мегабайт скажем, а потом скорость его урезалась до прописанной. При этом гарантируя что ack пакеты всегда будут уходить первыми и для них будет гарантирована полоса скажем в 64 килобита.

Да, убедил. Соглашусь. Это на pf/altq или уже только на Линуксе?

 

Так. Давай определимся с терминами. Под шейпингом, например, лично я понимаю именно per-ip, т.к. некий абстрактный шейпинг никому не нужен, а нужно решать конкретную задачу - нарезать разные скорости пользователям с разными тарифами. Адекватного способа (не сильно громоздкого и удобного) сделать это на pf/altq нет. Сделать QoS - пожалуйста. Приоретизировать трафик одной группы пользователей перед другой или выдать каждой свою полосу - пожалуйста. Но осуществить задачу нарезки пользователям скоростей в соответствии с тарифами - нет.

Не нет, а да. Всё это можно сделать на pf/altq только вот нужные правила в конфиге скажем на пару мегабайт вам врядли быстро удастся найти, если нужно будет внести изменения. Придётся полностью перегенерировать весь конфиг с нужными сам изменениями. Поэтому я говорю что "неудобно", но можно.

Не надо маньячить! Или понятия "удобство и практичность" неотъемлимыми частями админства один я считаю? Естесственно, если на сервере уже стоит OpenBSD, где нет выбора файрволла, то только и остается, что городить многомегабайтные конфиги. Но если религия все-таки позволяет подбирать инструмент под задачи, а не наоборот - то к чему это все?

Я же не встаю в позу и не пытаюсь вышепредложенную задачу по шейпингу/QoS решить на dummynet - я соглашаюсь, что для этого есть более другие средства. :-)

 

То что вы "понимаете под шейпингом" меня не касается, есть документ, который является стандартом и там написано что такое шейпинг.

Всё что касаеться темы "А Я это понимаю так....., а это вот так ......", меня не касаются. Есть документ стандарта, в котором чётко написано "что, есть что".

Ох, как-то вы грубо... :-) И извиняюсь, что до этого опрометчиво на "ты" обращался. :-) Говоря о "шейпинге" я подходил исключительно с позиции данного топика и ничего ни в коем случае не придумывал. Если забыли - посмотрите первый пост, там все сказано - о каком именно "шейпинге" мы говорим. :-)

 

Это больше похоже уже на "за упокойную".

Тут вы пытаетесь представить dummynet, чем он не являеться. Как бы вам этого не хотелось этим он не станет. Смиритесь.

Автор dummynet вложил функционал - и чётко написал может это, это и это. Всё остальное не может. Всё.

Бэзусловно! Именно поэтому я не пытаюсь ничего представить, а говорю о конкретном функционале, который легко реализуется несколькими строчками. Главное, не ориентироваться лишь на наборы примеров в инете и разные умные статьи, а читать маны. :-)

Я же не утверждаю, что на dummynet можно сделать все на свете. Я лишь предлагаю не городить сущности без надобности: если у человека уже стоит freebsd и работает ipfw, то с большой долей вероятности он сможет решить свою задачу по шейпингу/QoS трафика посредством dummynet - чтобы не было лишнего оверхеда и трудностей, связанных с переползанием. А если уж нет (или это будет слишком геморройно) - то можно и pf/altq смотреть, и на Линукс переходить. Главное - поменьше фанатизма.

 

Сравнивать ipfw и pf, глупое бессмысленное занятие. Отложим.

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

 

[HEDG]

3) "Что подойдёт для чуть больше чем "примитивный шейпинг", например с добавлением к шейпингу ещё и частичного QoS в рамках Per ip ?" - Для этого лучше всего на данный момент подойдёт линукс. Да, там не так всё просто и линейно как в dummynet, но там можно описать практически любую интерсующую вас конструкцию по управлению трафиком.

Можно примеры удачных связок (Linux ...+...) ?

Какое кол-во pps успевает нормально обрабатывать такая связка (+ краткое описане железа на которм это все крутится)?

Какие возможны "подводные камни" ?

[windows_NT]

3) "Что подойдёт для чуть больше чем "примитивный шейпинг", например с добавлением к шейпингу ещё и частичного QoS в рамках Per ip ?" - Для этого лучше всего на данный момент подойдёт линукс. Да, там не так всё просто и линейно как в dummynet, но там можно описать практически любую интерсующую вас конструкцию по управлению трафиком.

Можно примеры удачных связок (Linux ...+...) ?

Какое кол-во pps успевает нормально обрабатывать такая связка (+ краткое описане железа на которм это все крутится)?

Какие возможны "подводные камни" ?

Поставьте и посмотрите.

[HEDG]

Поставьте и посмотрите.

1. Не очень то хочется ставить эксперименты на работающих абонентах.

2. Хочу узнать , какие проверенные связки уже работают стабильно (нет никакого желания бегать самому по всем граблям)

Изменено 16 июля, 2009 пользователем HEDG

[jab]

offtopic ( давно обещал выложить, но темы подходящей нет ):

 

шейпер

 

core i7 920 2.9Ghz, intel 1000/PT dual, FreeBSD 7.2-STABLE, yandex driver 6.9.6, dummynet io_fast=1, MSI interrupts

 

88 processes:  11 running, 65 sleeping, 12 waiting
CPU:  0.0% user,  0.0% nice, 27.2% system,  0.0% interrupt, 72.8% idle
Mem: 11M Active, 7376K Inact, 113M Wired, 60K Cache, 7440K Buf, 2833M Free
Swap:

  PID USERNAME  THR PRI NICE   SIZE    RES STATE   C   TIME   WCPU COMMAND
   15 root        1 171 ki31     0K    16K CPU3    3  28.4H 86.96% idle: cpu3
   17 root        1 171 ki31     0K    16K CPU1    1  27.2H 86.18% idle: cpu1
   13 root        1 171 ki31     0K    16K CPU5    5  27.6H 83.06% idle: cpu5
   12 root        1 171 ki31     0K    16K CPU6    6  25.0H 78.17% idle: cpu6
   11 root        1 171 ki31     0K    16K RUN     7  25.6H 77.15% idle: cpu7
   16 root        1 171 ki31     0K    16K CPU2    2  22.9H 70.65% idle: cpu2
   18 root        1 171 ki31     0K    16K CPU0    0  22.7H 69.97% idle: cpu0
   14 root        1 171 ki31     0K    16K RUN     4  23.9H 69.19% idle: cpu4
  144 root        1  43    -     0K    16K WAIT    6 238:13 23.78% em0_rx_kthre
  149 root        1  43    -     0K    16K WAIT    0 225:53 22.95% em1_rx_kthre
  145 root        1  43    -     0K    16K WAIT    7 238:32 22.51% em0_rx_kthre
   32 root        1  43    -     0K    16K CPU2    2 238:16 22.02% em0_rx_kthre
  148 root        1  43    -     0K    16K WAIT    0 225:40 22.02% em1_rx_kthre
   36 root        1  43    -     0K    16K WAIT    0 226:36 21.97% em1_rx_kthre
   35 root        1  43    -     0K    16K WAIT    6 225:49 21.63% em1_rx_kthre
   31 root        1  43    -     0K    16K CPU5    5 238:58 21.58% em0_rx_kthre

 

            input      (bridge0)           output
   packets  errs      bytes    packets  errs      bytes colls
    257981     0  184200281     256426     0  182641591     0
    260153     0  184394013     258808     0  183183729     0
    253341     0  180538455     251949     0  179338995     0
    259438     0  184790921     258384     0  183840961     0
    256248     0  181942013     255015     0  180830574     0
    259958     0  185267974     258807     0  184250460     0

 

первая колонка == суммарно in+out

 

# ipfw pipe show | wc -l

3911

 

трубы динамические, src/dst mask 0xffffffff, без tablearg

[Alexandr Ovcharenko]

"А вот за что я люблю ковбоя - за то что все есть у него"

(с) песенка из к-фильма "Человек с бульвара Капуцинов"

Бздя рулит :)

[windows_NT]

offtopic ( давно обещал выложить, но темы подходящей нет ):

 

шейпер

 

core i7 920 2.9Ghz, intel 1000/PT dual, FreeBSD 7.2-STABLE, yandex driver 6.9.6, dummynet io_fast=1, MSI interrupts

 

88 processes:  11 running, 65 sleeping, 12 waiting
CPU:  0.0% user,  0.0% nice, 27.2% system,  0.0% interrupt, 72.8% idle
Mem: 11M Active, 7376K Inact, 113M Wired, 60K Cache, 7440K Buf, 2833M Free
Swap:

  PID USERNAME  THR PRI NICE   SIZE    RES STATE   C   TIME   WCPU COMMAND
   15 root        1 171 ki31     0K    16K CPU3    3  28.4H 86.96% idle: cpu3
   17 root        1 171 ki31     0K    16K CPU1    1  27.2H 86.18% idle: cpu1
   13 root        1 171 ki31     0K    16K CPU5    5  27.6H 83.06% idle: cpu5
   12 root        1 171 ki31     0K    16K CPU6    6  25.0H 78.17% idle: cpu6
   11 root        1 171 ki31     0K    16K RUN     7  25.6H 77.15% idle: cpu7
   16 root        1 171 ki31     0K    16K CPU2    2  22.9H 70.65% idle: cpu2
   18 root        1 171 ki31     0K    16K CPU0    0  22.7H 69.97% idle: cpu0
   14 root        1 171 ki31     0K    16K RUN     4  23.9H 69.19% idle: cpu4
  144 root        1  43    -     0K    16K WAIT    6 238:13 23.78% em0_rx_kthre
  149 root        1  43    -     0K    16K WAIT    0 225:53 22.95% em1_rx_kthre
  145 root        1  43    -     0K    16K WAIT    7 238:32 22.51% em0_rx_kthre
   32 root        1  43    -     0K    16K CPU2    2 238:16 22.02% em0_rx_kthre
  148 root        1  43    -     0K    16K WAIT    0 225:40 22.02% em1_rx_kthre
   36 root        1  43    -     0K    16K WAIT    0 226:36 21.97% em1_rx_kthre
   35 root        1  43    -     0K    16K WAIT    6 225:49 21.63% em1_rx_kthre
   31 root        1  43    -     0K    16K CPU5    5 238:58 21.58% em0_rx_kthre

 

            input      (bridge0)           output
   packets  errs      bytes    packets  errs      bytes colls
    257981     0  184200281     256426     0  182641591     0
    260153     0  184394013     258808     0  183183729     0
    253341     0  180538455     251949     0  179338995     0
    259438     0  184790921     258384     0  183840961     0
    256248     0  181942013     255015     0  180830574     0
    259958     0  185267974     258807     0  184250460     0

 

первая колонка == суммарно in+out

 

# ipfw pipe show | wc -l

3911

 

трубы динамические, src/dst mask 0xffffffff, без tablearg

Ну, выложил. И что дальше ?

 

[jab]

Ну, выложил. И что дальше ?

Дальше накрываюсь простыней и ползу на кладбище, чтобы не создавать паники.

 

Кто просил, тот прочтет. :-)

[Skylord]

2jab: Гм. Мне казалось, ты это уже где-то выкладывал... По крайней мере, числа в районе 250 kpps я уже где-то тут на форуме видел... :-) Вопрос: это, как я понимаю, чистый шейпер L2 без файрволла и т.п.?

[HEDG]

трубы динамические, src/dst mask 0xffffffff, без tablearg

250k это уже серёзно!

А почму не использовали tablearg или это просто особености реализации ?

[jab]

2jab: Гм. Мне казалось, ты это уже где-то выкладывал... По крайней мере, числа в районе 250 kpps я уже где-то тут на форуме видел... :-) Вопрос: это, как я понимаю, чистый шейпер L2 без файрволла и т.п.?

Числа те же, cpu idle разный. Это продакшин, а не стресс-тест.

 

Что такое "чистый шейпер без файрволла" ?

 

А почму не использовали tablearg или это просто особености реализации ?

Оно и 700kpps потянет, а tablearg нету потому что этой конфигурации ipfw пять лет, не было тогда никаких tablearg'ов. :-)

[Giga-Byte]

offtopic ( давно обещал выложить, но темы подходящей нет ):

 

# ipfw pipe show | wc -l

3911

 

трубы динамические, src/dst mask 0xffffffff, без tablearg

ты как-то говорил, мол mpd с ng_car используют только идиоты, ввиду того что "имеются косяки с нодами"

вот меня интересует, какие это косяки? в чем оно выражается.

и что будет когда ID ноды доползёт до 0xffffffff?

 

я доработал mpd5.3 для отдачи аттрибутов и применения их на RAD_ACCT,

по крайней мере ситуация с rate-limit-ом больших локальных (и теперь уже глобальных) скоростей улучшилась

[Skylord]

2jab: Гм. Мне казалось, ты это уже где-то выкладывал... По крайней мере, числа в районе 250 kpps я уже где-то тут на форуме видел... :-) Вопрос: это, как я понимаю, чистый шейпер L2 без файрволла и т.п.?

Числа те же, cpu idle разный. Это продакшин, а не стресс-тест.

Ага, ОК...

 

Что такое "чистый шейпер без файрволла" ?

Ну, в смысле, есть еще что-нибудь в ipfw или только pipe'ы? Я так понял, что только пайпы...

[jab]

ты как-то говорил, мол mpd с ng_car используют только идиоты, ввиду того что "имеются косяки с нодами"

вот меня интересует, какие это косяки? в чем оно выражается.

Тогда был целый поток жалоб на кучу глюков в 7.1 (? или в 7.2?) при mpd5 с ng_car. ( В dummynet кстати тоже тогда накосячили ) Подозрения были на сбой нумерации и потерю orphans. Конкретику сейчас вспомнить трудно, уже несколько месяцев прошло, а ng_car и mpd5 я в продакшине не держу.

 

и что будет когда ID ноды доползёт до 0xffffffff?

Обнулится и дальше поползет скорее всего.

 

 

Ну, в смысле, есть еще что-нибудь в ipfw или только pipe'ы? Я так понял, что только пайпы...

#ipfw show | wc -l

58

 

ветвлений нет, пакеты идут сквозняком