forum.opennet.ru - "ipfw altq hfsc " (8)

форумы

помощь

поиск

регистрация

майллист

вход/выход

слежка

"ipfw altq hfsc "

Форум Открытые системы на сервере (Квоты, ограничения, QoS / FreeBSD)
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"ipfw altq hfsc "	+/–
Сообщение от creeping_death (ok) on 11-Мрт-12, 18:29
Всем привет. Столкнулся со следующей проблемой: раньше для трафик шейпинга использовал ipfw\dummynet, все работало прекрасно, но дир поставил такую задачу, если канал не занимаеться трафиком с определенных IP, то отдавать канал полностью всем остальным, если есть трафик то отдавать процентов 80 канала этим IP. Решил использовать ipfw/altq/hfsc. Создал 3 очереди, конфиг привожу ниже (pf.conf): altq on ae0 hfsc bandwidth 10Mb queue { standard, vip, management, work } queue vip bandwidth 30% priority 7 hfsc (realtime 80% linkshare 30% upperlimit 100%) queue management bandwidth 25% priority 5 hfsc ( linkshare 25% upperlimit 100%) queue work bandwidth 25% priority 3 hfsc ( linkshare 25% upperlimit 60%) queue standard bandwidth 20% hfsc ( linkshare 20% upperlimit 20% default) Пока настроил только на download, ae0 внутренний интрефейс. Пытаюсь добиться чтоб очереди vip как и положенно отдавалось 80% канала. Далее раскидал компы по очередям в ipfw.rules: $cmd 1 count altq vip all from any to $vip_ip out via $lif $cmd 2 count altq management all from any to $mgmt_ip out via $lif $cmd 3 count altq work all from any to $work_ip out via $lif $cmd 4 count altq standard all from any to any out via $lif Прописал правила первыми до динамической проверки, $lif внутренний интерфейс. Далее наблюдаю следующую картину: компы из очереди management используют канал почти на полную, далее подключаю машину из очереди vip, через некоторое время закачка примерно выравниваеться в соотношении примерно 50\50 между очередями. Команда pfctl -s queue -v показывает что все очереди работают. Манипуляции с параметрами realtime, upperlimit, linkshare ни к чему не привели... Что не так в настройках и почему не работает? Заранее спасибо.
Ответить \| Правка \| Cообщить модератору

Оглавление

ipfw altq hfsc , artemrts, 21:54 , 11-Мрт-12, (1)

ipfw altq hfsc , artemrts, 22:02 , 11-Мрт-12, (2) +1

ipfw altq hfsc , creeping_death, 10:50 , 12-Мрт-12, (3)

ipfw altq hfsc , DeadLoco, 11:51 , 12-Мрт-12, (4)

ipfw altq hfsc , Skif, 10:24 , 17-Мрт-12, (5) –1

ipfw altq hfsc , artemrts, 13:55 , 17-Мрт-12, (6)

ipfw altq hfsc , Skif, 21:25 , 17-Мрт-12, (7)

ipfw altq hfsc , artemrts, 23:53 , 17-Мрт-12, (8)

Сообщения по теме [Сортировка по времени | RSS]

1. "ipfw altq hfsc " +/–

Сообщение от artemrts (ok) on 11-Мрт-12, 21:54

>[оверквотинг удален]
> $cmd 4 count altq standard all from any to any out via
> $lif
> Прописал правила первыми до динамической проверки, $lif внутренний интерфейс. Далее наблюдаю
> следующую картину: компы из очереди management используют канал почти на полную,
> далее подключаю машину из очереди vip, через некоторое время закачка примерно
> выравниваеться в соотношении примерно 50\50 между очередями. Команда  pfctl -s
> queue -v показывает что все очереди работают. Манипуляции с параметрами realtime,
> upperlimit, linkshare ни к чему не привели...
> Что не так в настройках и почему не работает?
> Заранее спасибо.
Несколько общих рекомендаций.
Если вам не нужно "резать" канал по src-mask, то нет надобности в ipfw. Все можно реализовать с помощью pf/altq. Ставьте pftop и смотрите как распределяются очереди.
В hfsc приоритеты не исользуются, так что можете их не указывать. В вашем случае лучше использовать cbq.
Что-то типа этого:
set state-policy if-bound
altq on ae0 cbq bandwidth 10Mb queue { standard, vip, management, work }
queue down_vip bandwidth 30% priority 7 cbq (borrow)
queue down_management bandwidth 25% priority 5 cbq (borrow)
queue down_work bandwidth 25% priority 3 cbq (borrow)
queue down_standard bandwidth 20% cbq(borrow)
Аналогично для внешнего интерфейса.
Далее назначаем очереди:
block in
block out
pass in quick on $int_if inet from $vip to !(self) queue down_vip
.......................   ... from $managment to !(self) queue down_manag
pass out quick on $int_if inet from any to any
Для ограничения исходящего траффика:
pass out quick on $ext_if inet from $ext_if to any queue up_vip
........... ...................................................

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "ipfw altq hfsc " +1 +/–

Сообщение от artemrts (ok) on 11-Мрт-12, 22:02

>[оверквотинг удален]
> вашем случае лучше использовать cbq.
>  Что-то типа этого:
>  set state-policy if-bound
>  altq on ae0 cbq bandwidth 10Mb queue { standard, vip, management,
> work }
> queue down_vip bandwidth 30% priority 7 cbq (borrow)
> queue down_management bandwidth 25% priority 5 cbq (borrow)
> queue down_work bandwidth 25% priority 3 cbq (borrow)
> queue down_standard bandwidth 20% cbq(borrow)
>  Аналогично для внешнего интерфейса.
Oops. Далее я немного ошибся.
> Далее назначаем очереди:
>  block in
>  block out
pass in quick on $int_if inet from $vip to !(self) queue down_vip tag vip
.......................   ... from $managment to !(self) queue down_manager tag manager
pass out quick on $int_if inet from any to any
>  Для ограничения исходящего траффика:
pass out quick on $ext_if inet from $ext_if to any queue up_vip tagged vip
........... ...................................................

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

3. "ipfw altq hfsc " +/–

Сообщение от creeping_death (ok) on 12-Мрт-12, 10:50

>[оверквотинг удален]
>>  block in
>>  block out
> pass in quick on $int_if inet from $vip to !(self) queue down_vip
> tag vip
> .......................   ... from $managment to !(self) queue down_manager tag manager
> pass out quick on $int_if inet from any to any
>>  Для ограничения исходящего траффика:
> pass out quick on $ext_if inet from $ext_if to any queue up_vip
> tagged vip
>  ........... ...................................................
Спасибо за помощь. Сегодня попробую планировщик cbq сначало все же в ipfw, не хочеться пока переходить на pf.

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

4. "ipfw altq hfsc " +/–

Сообщение от DeadLoco (ok) on 12-Мрт-12, 11:51

> сначало все же в ipfw, не хочеться пока переходить на pf.
В ИПФВ задача решается динамическими (src/dst-mask) очередями с приоритетами (weight). Все, что нужно - создать два пайпа на вход и выход, а внутри них создавать диночереди с приоритетами, в зависимости от адресов-портов-направлений.

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

5. "ipfw altq hfsc " –1 +/–

Сообщение от Skif (ok) on 17-Мрт-12, 10:24

> Далее назначаем очереди:
>  block in
>  block out
>  pass in quick on $int_if inet from $vip to !(self) queue
> down_vip
ALTQ на fbsd не режет входящий трафик.
Второе, по умолчанию все правила идут с keep state. по этому если шейпить исход необходимо добавлять no state иначе часть трафика может не попасть под ограничение, попав под другую, не шейпированную очередь.

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

6. "ipfw altq hfsc " +/–

Сообщение от artemrts (ok) on 17-Мрт-12, 13:55

>> Далее назначаем очереди:
>>  block in
>>  block out
>>  pass in quick on $int_if inet from $vip to !(self) queue
>> down_vip
> ALTQ на fbsd не режет входящий трафик.
А где вы видели в моем примере обратное. Вы путаете сказанное с _назначением_ очереди для конкретного вида траффика с учетом специфики PF (имеется ввиду stateful filtering).
Почему не читаете доки?
Вот строчки из офф. PF User's Guide.
     pass in on fxp0 proto tcp to port 80 queue http
With this rule, packets traveling back out fxp0 that match the stateful
connection will end up in the http queue. Note that even though the queue
keyword is being used on a rule filtering incoming traffic, the goal is to
specify a queue for the corresponding outgoing traffic; the above rule does
not queue incoming packets.

> Второе, по умолчанию все правила идут с keep state. по этому если
> шейпить исход необходимо добавлять no state иначе часть трафика может не
> попасть под ограничение, попав под другую, не шейпированную очередь.

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

7. "ipfw altq hfsc " +/–

Сообщение от Skif (ok) on 17-Мрт-12, 21:25

>>> Далее назначаем очереди:
>>>  block in
>>>  block out
>>>  pass in quick on $int_if inet from $vip to !(self) queue
>>> down_vip
>> ALTQ на fbsd не режет входящий трафик.
> А где вы видели в моем примере обратное. Вы путаете сказанное с
> _назначением_ очереди для конкретного вида траффика с учетом специфики PF (имеется
> ввиду stateful filtering).
>  Почему не читаете доки?
Доки читал. Разъясните разницу - буду благодарен.

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

8. "ipfw altq hfsc " +/–

Сообщение от artemrts (ok) on 17-Мрт-12, 23:53

>[оверквотинг удален]
>>>>  block in
>>>>  block out
>>>>  pass in quick on $int_if inet from $vip to !(self) queue
>>>> down_vip
>>> ALTQ на fbsd не режет входящий трафик.
>> А где вы видели в моем примере обратное. Вы путаете сказанное с
>> _назначением_ очереди для конкретного вида траффика с учетом специфики PF (имеется
>> ввиду stateful filtering).
>>  Почему не читаете доки?
> Доки читал. Разъясните разницу - буду благодарен.
Смотрите, вся прелесть PF именно в stateful firewalling. Как с точки зрения производительности так и безопасности, поэтому лучше использовать как раз keep-state. Если вы пытаетесь ограничивать или приоритизировать трафик "в локальную сеть", то да его можно направить в нужную очередь фактически без keep-stating на внутрееннем интерфейсе (с помощью опции nostate), что не есть хорошо.
Лечше, когда у вас все keep-state и стейты привязаны к интерфейсу (set state-policy if-bound).
Допустим, клиент из локальной сети запросил www ресурс. На внутр. интерфейсе создается стейт с очередью, которая ограничивает траффик на закачку. Этот стейт будет служить как-бы обратным маршрутом для ответа от www сервера, т.е. вы можете вообще явно не разрешать трафик с внутреннего интерфейса в лок. сеть. Вот этот ответ от сервера попадает под созданный ранее стейт с назначенной очередью, поэтому такое правило будет работать:
pass in quick on $int_if inet proto tcp from $int_if:network to !(self) port {80 443} queue www_dounload
Что касается ограничения upload, то тут все просто:
pass out quick on $ext_if inet proto tcp from $ext_if to any port {80 443} queue www_upload
Допустим, вам нужно ограничить исходящий канал для разных пользователей\подсетей\etc.
pass out quick on $ext_if inet proto tcp from $computer_bossa to any port {80 443} queue www_upload_boss
но так не прокатит, потому что у нас _NAT_. Вот что бы это обойти нам и надо пометит пакеты, пришедшие на внутр. ифейс с машины босса и "отделить" его от остального.
pass in quick on $int_if inet proto tcp from $computer_bossa to !(self) port {80 443} queue www_dounload_boss tag BOSS
pass out quick on $ext_if inet from $ext_if to any queue www_upload_boss tagged BOSS
Плюс еще в том, что в исходящих правилах  на $ext_if вам не нужно дублировать протоколы и порты назначения. Это уменьщает конечное число правил.
НУ вроде все. Надеюсь понятно объяснил.)

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2025 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "ipfw altq hfsc "	+/–
Сообщение от artemrts (ok) on 11-Мрт-12, 21:54
>[оверквотинг удален] > $cmd 4 count altq standard all from any to any out via > $lif > Прописал правила первыми до динамической проверки, $lif внутренний интерфейс. Далее наблюдаю > следующую картину: компы из очереди management используют канал почти на полную, > далее подключаю машину из очереди vip, через некоторое время закачка примерно > выравниваеться в соотношении примерно 50\50 между очередями. Команда pfctl -s > queue -v показывает что все очереди работают. Манипуляции с параметрами realtime, > upperlimit, linkshare ни к чему не привели... > Что не так в настройках и почему не работает? > Заранее спасибо. Несколько общих рекомендаций. Если вам не нужно "резать" канал по src-mask, то нет надобности в ipfw. Все можно реализовать с помощью pf/altq. Ставьте pftop и смотрите как распределяются очереди. В hfsc приоритеты не исользуются, так что можете их не указывать. В вашем случае лучше использовать cbq. Что-то типа этого: set state-policy if-bound altq on ae0 cbq bandwidth 10Mb queue { standard, vip, management, work } queue down_vip bandwidth 30% priority 7 cbq (borrow) queue down_management bandwidth 25% priority 5 cbq (borrow) queue down_work bandwidth 25% priority 3 cbq (borrow) queue down_standard bandwidth 20% cbq(borrow) Аналогично для внешнего интерфейса. Далее назначаем очереди: block in block out pass in quick on $int_if inet from $vip to !(self) queue down_vip ....................... ... from $managment to !(self) queue down_manag pass out quick on $int_if inet from any to any Для ограничения исходящего траффика: pass out quick on $ext_if inet from $ext_if to any queue up_vip ........... ...................................................
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	2. "ipfw altq hfsc "	+1 +/–
	Сообщение от artemrts (ok) on 11-Мрт-12, 22:02
	>[оверквотинг удален] > вашем случае лучше использовать cbq. > Что-то типа этого: > set state-policy if-bound > altq on ae0 cbq bandwidth 10Mb queue { standard, vip, management, > work } > queue down_vip bandwidth 30% priority 7 cbq (borrow) > queue down_management bandwidth 25% priority 5 cbq (borrow) > queue down_work bandwidth 25% priority 3 cbq (borrow) > queue down_standard bandwidth 20% cbq(borrow) > Аналогично для внешнего интерфейса. Oops. Далее я немного ошибся. > Далее назначаем очереди: > block in > block out pass in quick on $int_if inet from $vip to !(self) queue down_vip tag vip ....................... ... from $managment to !(self) queue down_manager tag manager pass out quick on $int_if inet from any to any > Для ограничения исходящего траффика: pass out quick on $ext_if inet from $ext_if to any queue up_vip tagged vip ........... ...................................................
	Ответить \| Правка \| ^ к родителю #1 \| Наверх \| Cообщить модератору


	3. "ipfw altq hfsc "	+/–
	Сообщение от creeping_death (ok) on 12-Мрт-12, 10:50
	>[оверквотинг удален] >> block in >> block out > pass in quick on $int_if inet from $vip to !(self) queue down_vip > tag vip > ....................... ... from $managment to !(self) queue down_manager tag manager > pass out quick on $int_if inet from any to any >> Для ограничения исходящего траффика: > pass out quick on $ext_if inet from $ext_if to any queue up_vip > tagged vip > ........... ................................................... Спасибо за помощь. Сегодня попробую планировщик cbq сначало все же в ipfw, не хочеться пока переходить на pf.
	Ответить \| Правка \| ^ к родителю #2 \| Наверх \| Cообщить модератору


	4. "ipfw altq hfsc "	+/–
	Сообщение от DeadLoco (ok) on 12-Мрт-12, 11:51
	> сначало все же в ipfw, не хочеться пока переходить на pf. В ИПФВ задача решается динамическими (src/dst-mask) очередями с приоритетами (weight). Все, что нужно - создать два пайпа на вход и выход, а внутри них создавать диночереди с приоритетами, в зависимости от адресов-портов-направлений.
	Ответить \| Правка \| ^ к родителю #3 \| Наверх \| Cообщить модератору


	5. "ipfw altq hfsc "	–1 +/–
	Сообщение от Skif (ok) on 17-Мрт-12, 10:24
	> Далее назначаем очереди: > block in > block out > pass in quick on $int_if inet from $vip to !(self) queue > down_vip ALTQ на fbsd не режет входящий трафик. Второе, по умолчанию все правила идут с keep state. по этому если шейпить исход необходимо добавлять no state иначе часть трафика может не попасть под ограничение, попав под другую, не шейпированную очередь.
	Ответить \| Правка \| ^ к родителю #1 \| Наверх \| Cообщить модератору


	6. "ipfw altq hfsc "	+/–
	Сообщение от artemrts (ok) on 17-Мрт-12, 13:55
	>> Далее назначаем очереди: >> block in >> block out >> pass in quick on $int_if inet from $vip to !(self) queue >> down_vip > ALTQ на fbsd не режет входящий трафик. А где вы видели в моем примере обратное. Вы путаете сказанное с _назначением_ очереди для конкретного вида траффика с учетом специфики PF (имеется ввиду stateful filtering). Почему не читаете доки? Вот строчки из офф. PF User's Guide. pass in on fxp0 proto tcp to port 80 queue http With this rule, packets traveling back out fxp0 that match the stateful connection will end up in the http queue. Note that even though the queue keyword is being used on a rule filtering incoming traffic, the goal is to specify a queue for the corresponding outgoing traffic; the above rule does not queue incoming packets. > Второе, по умолчанию все правила идут с keep state. по этому если > шейпить исход необходимо добавлять no state иначе часть трафика может не > попасть под ограничение, попав под другую, не шейпированную очередь.
	Ответить \| Правка \| ^ к родителю #5 \| Наверх \| Cообщить модератору


	7. "ipfw altq hfsc "	+/–
	Сообщение от Skif (ok) on 17-Мрт-12, 21:25
	>>> Далее назначаем очереди: >>> block in >>> block out >>> pass in quick on $int_if inet from $vip to !(self) queue >>> down_vip >> ALTQ на fbsd не режет входящий трафик. > А где вы видели в моем примере обратное. Вы путаете сказанное с > _назначением_ очереди для конкретного вида траффика с учетом специфики PF (имеется > ввиду stateful filtering). > Почему не читаете доки? Доки читал. Разъясните разницу - буду благодарен.
	Ответить \| Правка \| ^ к родителю #6 \| Наверх \| Cообщить модератору


	8. "ipfw altq hfsc "	+/–
	Сообщение от artemrts (ok) on 17-Мрт-12, 23:53
	>[оверквотинг удален] >>>> block in >>>> block out >>>> pass in quick on $int_if inet from $vip to !(self) queue >>>> down_vip >>> ALTQ на fbsd не режет входящий трафик. >> А где вы видели в моем примере обратное. Вы путаете сказанное с >> _назначением_ очереди для конкретного вида траффика с учетом специфики PF (имеется >> ввиду stateful filtering). >> Почему не читаете доки? > Доки читал. Разъясните разницу - буду благодарен. Смотрите, вся прелесть PF именно в stateful firewalling. Как с точки зрения производительности так и безопасности, поэтому лучше использовать как раз keep-state. Если вы пытаетесь ограничивать или приоритизировать трафик "в локальную сеть", то да его можно направить в нужную очередь фактически без keep-stating на внутрееннем интерфейсе (с помощью опции nostate), что не есть хорошо. Лечше, когда у вас все keep-state и стейты привязаны к интерфейсу (set state-policy if-bound). Допустим, клиент из локальной сети запросил www ресурс. На внутр. интерфейсе создается стейт с очередью, которая ограничивает траффик на закачку. Этот стейт будет служить как-бы обратным маршрутом для ответа от www сервера, т.е. вы можете вообще явно не разрешать трафик с внутреннего интерфейса в лок. сеть. Вот этот ответ от сервера попадает под созданный ранее стейт с назначенной очередью, поэтому такое правило будет работать: pass in quick on $int_if inet proto tcp from $int_if:network to !(self) port {80 443} queue www_dounload Что касается ограничения upload, то тут все просто: pass out quick on $ext_if inet proto tcp from $ext_if to any port {80 443} queue www_upload Допустим, вам нужно ограничить исходящий канал для разных пользователей\подсетей\etc. pass out quick on $ext_if inet proto tcp from $computer_bossa to any port {80 443} queue www_upload_boss но так не прокатит, потому что у нас _NAT_. Вот что бы это обойти нам и надо пометит пакеты, пришедшие на внутр. ифейс с машины босса и "отделить" его от остального. pass in quick on $int_if inet proto tcp from $computer_bossa to !(self) port {80 443} queue www_dounload_boss tag BOSS pass out quick on $ext_if inet from $ext_if to any queue www_upload_boss tagged BOSS Плюс еще в том, что в исходящих правилах на $ext_if вам не нужно дублировать протоколы и порты назначения. Это уменьщает конечное число правил. НУ вроде все. Надеюсь понятно объяснил.)
	Ответить \| Правка \| ^ к родителю #7 \| Наверх \| Cообщить модератору