altq

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

altq

irix
Hello Openbsd,

  http://kes.net.ua/softdev/advanced_firewall.html

  В этой статейке в конце есть маленький очерк насчёт altq и шейпера
  входящего трафа, кто что думает по этому поводу ?


ipfw vs pf
Недостаток ALTQ
Я бы не использовал ALTQ в качестве шейпера только по одной причине: шейпится только исходящий трафик. Это самый большой минус, который можно придумать! Этот минус сводит на нет все достоинства ALTQ. Почти везде можно увидить:
MB> потому что шейпить входящий трафик дурость =)
На самом деле дурость - это НЕ ШЕЙПИТЬ входящий трафик!!!
Простой пример. хост -- роутер -- шлюз -- инет
Если пользователь ХОСТ и РОУТЕР будут качать, то НЕВОЗМОЖНО создать правило, которое будет обрабатывать пакеты предназначенные для ХОСТ и РОУТЕР поочерёдно (roundrobin). Т.е. НЕВОЗОМЖНО разделить канал от ШЛЮЗ к РОУТЕР на равные части между пользователем ХОСТ и РОУТЕР
ПОЧЕМУ?
Потому что для РОУТЕР исхода не будет (пакет когда попадёт в ядро сразу передастся приложению) и поэтому мы не сможем пропустить этот пакет через ALTQ.
Поэтому пользователь РОУТЕР может загрузить канал в ущерб для ХОСТ.
Некоторые могут возразить что мол мы не можем контролировать входящий поток.
Я отвечу что можем! Наверное Вы просто ребята не читали работу протокола TCP/IP.
То что не получится для входящего трафика, так это приоритезировать его по типам. Например www дать меньше приоритета, чем голосовому трафику. Тут уж как пришли к нам пакеты, так уж пришли.
То что можно сделать, так это перенаправлять входящий трафик клиентам по очереди, таким образом разделив канал поровну между ними. Также можно ограничить потребление некоторым клиентом не более K% трафика. Что касается тупого флуда на Ваш интерфейс, то тут действительно кроме удара в голову флудеру ничего не поможет,
Но это частный случай!
--
Best regards,
 irix                          mailto:[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: altq

irix

  Забыл добавить, что в оригинальном altqd до его кастрации в pf
возможность шейпинг входящего потока была. condition вроде называлась
и до сих пор осталась в NetBSD вместе с altqd :)
Saturday, June 28, 2008, 6:23:55 PM, you wrote:

i> Hello Openbsd,

i>   http://kes.net.ua/softdev/advanced_firewall.html

i>   В этой статейке в конце есть маленький очерк насчёт altq и шейпера
i>   входящего трафа, кто что думает по этому поводу ?


i> ipfw vs pf
i> Недостаток ALTQ
i> Я бы не использовал ALTQ в качестве шейпера только по одной
i> причине: шейпится только исходящий трафик. Это самый большой минус,
i> который можно придумать! Этот минус сводит на нет все достоинства ALTQ. Почти везде можно увидить:
MB>> потому что шейпить входящий трафик дурость =)
i> На самом деле дурость - это НЕ ШЕЙПИТЬ входящий трафик!!!
i> Простой пример. хост -- роутер -- шлюз -- инет
i> Если пользователь ХОСТ и РОУТЕР будут качать, то НЕВОЗМОЖНО
i> создать правило, которое будет обрабатывать пакеты предназначенные
i> для ХОСТ и РОУТЕР поочерёдно (roundrobin). Т.е. НЕВОЗОМЖНО
i> разделить канал от ШЛЮЗ к РОУТЕР на равные части между пользователем ХОСТ и РОУТЕР
i> ПОЧЕМУ?
i> Потому что для РОУТЕР исхода не будет (пакет когда попадёт в ядро
i> сразу передастся приложению) и поэтому мы не сможем пропустить этот пакет через ALTQ.
i> Поэтому пользователь РОУТЕР может загрузить канал в ущерб для ХОСТ.
i> Некоторые могут возразить что мол мы не можем контролировать входящий поток.
i> Я отвечу что можем! Наверное Вы просто ребята не читали работу протокола TCP/IP.
i> То что не получится для входящего трафика, так это
i> приоритезировать его по типам. Например www дать меньше приоритета,
i> чем голосовому трафику. Тут уж как пришли к нам пакеты, так уж пришли.
i> То что можно сделать, так это перенаправлять входящий трафик
i> клиентам по очереди, таким образом разделив канал поровну между
i> ними. Также можно ограничить потребление некоторым клиентом не
i> более K% трафика. Что касается тупого флуда на Ваш интерфейс, то
i> тут действительно кроме удара в голову флудеру ничего не поможет,
i> Но это частный случай!



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


Reply | Threaded
Open this post in threaded view
|

Re: altq

Stanislav Kruchinin
In reply to this post by irix
irix wrote:
> Hello Openbsd,
>
> http://kes.net.ua/softdev/advanced_firewall.html
>
> В этой статейке в конце есть маленький очерк насчёт altq и шейпера входящего
> трафа, кто что думает по этому поводу ?

Очередная попытка написать об управлении трафиком человеком, не имеющим
достаточной квалификации. Данная статья -- это совокупность довольно
бессмысленных рассуждений, основанных не на знании теоретических основ и
реализации QoS во FreeBSD, а на каких-то поверхностных наблюдениях и чтении man
ipfw.

Лишний раз убеждаюсь, что dummynet прививает извращенные представления о
принципах управления трафиком, поскольку там используются сбивающие с толку
абстракции pipe и queue.

То, что dummynet умеет делать шейпинг входящего трафика -- это иллюзия,
порожденная синтаксисом следующих правил ipfw:
ipfw add pipe 1 all from 192.168.7.0/24 to any in recv "${iface}"
ipfw add pipe 2 all from any to 192.168.7.0/24 out xmit "${iface}"

Прочитав эти правила можно подумать, что это якобы шейпинг входящего и
исходящего трафика на одном интерфейсе. В реальности эти правила классифицируют
трафик, т.е. отправляют его в две разных очереди, которые создает dummynet.
Шейпинг (управление скоростью передачи пакетов) достигается засчет отправки
пакетов через определенные временные задержки. Вносить задержки и эмулировать
медленное соединение можно только если сама машина отправляет пакеты.
По поводу "шейпинга входящего трафика". Это делается так: входящий трафик
буферизуется и отправляется через другой интерфейс с задержками. Таким образом,
чтобы шейпить трафик в двух направлениях, нужно создавать правила ALTQ на двух
разных интерфейсах.

Кроме этого, RED в статье назван алгоритмом шейпинга, хотя это алгоритм
предотвращения переполнения очереди.

Я не удивляюсь, что с пониманием QoS все так плохо, однако будет и еще хуже. Вот
к примеру скрипт для ограничения скорости на интерфейсе с помощью
новоиспеченного модуля ng_car:

ngctl -f- <<-EOF
mkpeer re0: car lower lower
name re0:lower re0_car
connect re0: re0_car: upper upper
msg re0_car: setconf { upstream={ cbs=8192 ebs=65535 cir=100000 greenAction=1
yellowAction=1 redAction=2 mode=2 } downstream={ cbs=8192 ebs=65535 cir=1000000
greenAction=1 yellowAction=1 redAction=2 mode=2 } }
EOF

FreeBSD way: три файрвола, три ната, а теперь и три реализации QoS.


Reply | Threaded
Open this post in threaded view
|

Re: altq

Eugen Konkov
Stanislav Kruchinin wrote
По поводу "шейпинга входящего трафика". Это делается так: входящий трафик
буферизуется и отправляется через другой интерфейс с задержками.
Вы сами себе противоречите. Разве вы не видите что "Входящий трафик буферизируется и отправляется через другой интерфейс с задержками" 'pipe 1'
>ipfw add pipe 1 all from 192.168.7.0/24 to any in recv "${iface}"
Прошу заметить, что этим правилом я ограничиваю исход на внешнем интерфейсе rl0, а собираю трафик на каком-то локальном интерфейсе ng*.
Разница в том, что ALTQ может шейпить пакеты только тогда, когда они уходят с интерфейса, а ipfw в любом месте!

Stanislav Kruchinin wrote
Вносить задержки и эмулировать медленное соединение можно только если сама машина отправляет пакеты.
Правильно, я собрал пакеты на входе, и "за счёт отправки пакетов через определенные временные задержки" трафик шейпится перед тем, как попадёт в ядро, попав туда "сама машина отправляет пакеты" через нужный OUT интерфейс.


Stanislav Kruchinin wrote
Таким образом, чтобы шейпить трафик в двух направлениях, нужно создавать правила ALTQ на двух
разных интерфейсах.
Два интерфейса - это две очереди. Почему же когда я создаю две очереди dummynet это неверно?
Прокоментируйте пожалуйста:
"Прочитав эти правила можно подумать, что это якобы шейпинг входящего и
исходящего трафика на одном интерфейсе. В реальности эти правила классифицируют
трафик, т.е. отправляют его в две разных очереди, которые создает dummynet."


Stanislav Kruchinin wrote
Кроме этого, RED в статье назван алгоритмом шейпинга, хотя это алгоритм
предотвращения переполнения очереди.
Опечатался. Читайте просто "алгоритм"

Да, шейпить входящий трафик на ваш интерфейс, если пункт назначения пакетов -- это сам роутер, этим правилом не получится, тк. отправку пакетов на ВАШ интерфейс контролируется Вашим провайдером. И если от него идёт флуд, то, как писалось в статье, поможет только "удар монтировкой в голову".
Тут идёт речь о том, что ALTQ не может собирать проходящий трафик для шейпинга на входе.

Stanislav Kruchinin wrote
Очередная попытка написать об управлении трафиком человеком, не имеющим
достаточной квалификации
Если Вы такой квалифицированный, то напишите пожалуйста шейпер ALTQ для следующей ситуации.
Есть одна машина за роутером (подключена к роутеру через rl2), есть роутер, есть два линка к провайдерам.
Нужно чтобы машина за роутером (LAN) не могла делать UPLOAD в Интернет больше чем 512Кбит/с.
При чем трафик может уходить или через провайдер один (rl0) или через провайдер 2 (rl1)

Сразу отвечу:
Реализовать в ALTQ такое невозможно, т.к. на rl0 и rl1 будут созданы две разные очереди. И они никак!!! с друг другом "общаться" не смогут. Поэтому если трафик с LAN хоста будет уходить через rl0 со скорость 128Кбит, то мы не как не сможем зашейпить его на rl1 на скорость 384Кбит/с. А если исходящий трафик будет распределятся между двумя провайдерами случайным образом, то я про этот случай вообще молчу.

А вот с помощью ipfw это делается элементарными двумя правилами:
ipfw pipe 1 config bw 512kbit/s
ipfw add 1 pipe 1 all from any to any in recv rl2
Как дальше будет уходить пакет -- не важно. Гарантированно out трафик будет не более 512Кбит.

Скорей всего пользователи остались недопоняты разработчиками.
разработчики ВХОДЯЩИЙ ТРАФИК понимают как трафик, который входит на интерфейс и который невозможно контролировать, тк. его нам отправляет провайдер.
пользователи ВХОДЯЩИЙ ТРАФИК понимают как трафик, который входит на интерфейс и который потом должен идти в LAN (т.е. проходящий трафик относительно роутера)

И я думаю, что вся "война" заключается в том, что админ говоря "хочу зашейпить входящий трафик" имеет ввиду, что хочет зашейпить пользователя в LAN, чтобы он не мог качать более чем ХХХКбит в секунду. Cо стороны LAN хоста -- это входящий трафик, а со стороны роутера -- это исходящий трафик на внутреннем интерфейсе и входящий трафик на внешнем.
Вся фишка dummynet в том, что он может "буферезировать проходящий трафик" как на входе в роутер, так и на выходе из роутера, ну а потом уже "отправлять пакеты через определенные временные задержки" сконфигурированные в pipe.
А ALTQ не может "буферизировать проходящий трафик" на входе в роутер, а только на выходе. Это и есть слабость ALTQ, про которую я писал.

Подведу итог: говоря "хочу шейпить вход", в 99% процентов случаев имеется ввиду, что человек хочет зашейпить проходящий трафик на входе в роутер.