[Comm] Как разделять узкую полосу пропускания для входящего трафика?

[Comm] Как разделять узкую полосу пропускания для входящего трафика?

[Денис Черносов]

С тех пор, как перешли на безлимитный, но медленный интернет, есть
задача разделить полосу пропускания по приоритетам и/или
гарантированным полосам пропускания.
Сначала настраивал в SQUID - всё понятно, всё настраивается (в т.ч. и
по mime-типам). Одна беда - часть критически важного трафика плывет
мимо него. Также за бортом остаются потенциально прожорливые протоколы
типа torrent и ftp.
Стал настраивать QoS в etcnet - немного разобрался, настроил по
примеру... и обнаружил, что это всё для исходящего трафика, который
для меня не сильно критичен (разве что веб-серверу легче будет
немного).

Поиски вывели сюда:
http://www.masters.donntu.edu.ua/2004/kita/batyr/library/message1.htm
Очень интересная статья, осилил до конца и понял, что счастье моё в
IMQ (наверное).
Остались вопросы:
1) как правильно это прикрутить к etcnet?
2) как выделить тот самый входящий, если у меня разрешающее правило
через ESTABLISH,RELATED?

Для определенности скажем я хочу, чтобы хорошо бегал трафик на 443-й
tcp и обратно + притормозить входящий ftp. Полоса интерфейса 256кбит.

Re: [Comm] Как разделять узкую полосу пропускания для входящего трафика?

[Vasyuk_Maksim]

Денис Черносов пишет:
> С тех пор, как перешли на безлимитный, но медленный интернет, есть
> задача разделить полосу пропускания по приоритетам и/или
> гарантированным полосам пропускания.
> Сначала настраивал в SQUID - всё понятно, всё настраивается (в т.ч. и
> по mime-типам). Одна беда - часть критически важного трафика плывет
> мимо него. Также за бортом остаются потенциально прожорливые протоколы
> типа torrent и ftp.
> Стал настраивать QoS в etcnet - немного разобрался, настроил по
> примеру... и обнаружил, что это всё для исходящего трафика, который
> для меня не сильно критичен (разве что веб-серверу легче будет
> немного).
>
> Поиски вывели сюда:
> http://www.masters.donntu.edu.ua/2004/kita/batyr/library/message1.htm
> Очень интересная статья, осилил до конца и понял, что счастье моё в
> IMQ (наверное).
> Остались вопросы:
> 1) как правильно это прикрутить к etcnet?
> 2) как выделить тот самый входящий, если у меня разрешающее правило
> через ESTABLISH,RELATED?
>
> Для определенности скажем я хочу, чтобы хорошо бегал трафик на 443-й
> tcp и обратно + притормозить входящий ftp. Полоса интерфейса 256кбит.

А поиски на HTB не выводили? ;)
Это мой скрипт который занимаеться разделением трафика.
Может и коряво, но работает! )

#!/bin/bash                                             

DOWNLINK=2000
UPLINK=1024 
DEV=ppp999  

# очистка входящей и исходящей qdisc
tc qdisc del dev $DEV root    2> /dev/null > /dev/null
tc qdisc del dev $DEV ingress 2> /dev/null > /dev/null

###### исходящий трафик

# установка корневой HTB, отправить трафик по-умолчанию в 1:20:

tc qdisc add dev $DEV root handle 1: htb default 20

# ограничить общую исходящую скорость величиной $UPLINK -- это предотвратит
# появление огромных очередей в DSL модеме,                               
# которые отрицательно сказываются на величине задержки:                  

tc class add dev $DEV parent 1: classid 1:1 htb rate ${UPLINK}kbit burst 1k

# высокоприоритетный (интерактивный) класс 1:10:

tc class add dev $DEV parent 1:1 classid 1:10 htb rate $[UPLINK/2]kbit \
   burst 1k prio 1                                                     
                                                                       
   # класс по-умолчанию 1:20 -- получает немного меньший объем трафика 
   # и имеет более низкий приоритет:                                   
                                                                       
#tc class add dev $DEV parent 1:1 classid 1:20 htb rate 
$[9*$UPLINK/10]kbit \
#  burst 20k prio 
2                                                         

tc class add dev $DEV parent 1:1 classid 1:20 htb rate 8kbit \
  burst 50k prio 2                                           
                                                             
#tc class add dev $DEV parent 1:1 classid 1:20 htb rate 10kbit \
#  burst 40k prio 2                                            

tc class add dev $DEV parent 1:1 classid 1:30 htb rate $[UPLINK/2/2]kbit \
  burst 1k prio 3                                                        

# оба получают дисциплину Stochastic Fairness:
#tc qdisc add dev $DEV parent 1:10 handle 10: sfq perturb 10
#tc qdisc add dev $DEV parent 1:20 handle 20: sfq perturb 10
#tc qdisc add dev $DEV parent 1:30 handle 30: sfq perturb 10

# TOS = Minimum-Delay (ssh, НО НЕ scp) -- в 1:10:
#tc filter add dev $DEV parent 1:0 protocol ip prio 10 u32 \
#  match ip tos 0x10 0xff  flowid 1:10                     
                                                           
# ICMP (ip protocol 1) -- в интерактивный класс 1:10       
# так мы сможем удивить своих друзей:                      
tc filter add dev $DEV parent 1:0 protocol ip prio 10 u32 \
  match ip protocol 1 0xff flowid 1:30                     

############

tc filter add dev $DEV parent 1:0 protocol ip prio 10 u32 \
  match ip dport 80 0xff flowid 1:10                      

tc filter add dev $DEV parent 1:0 protocol ip prio 10 u32 \
  match ip dport 8500 0xff flowid 1:10                    

tc filter add dev $DEV parent 1:0 protocol ip prio 10 u32 \
  match ip dport 8080 0xff flowid 1:10                    
                                                          
tc filter add dev $DEV parent 1:0 protocol ip prio 10 u32 \
  match ip dport 5190 0xff flowid 1:10                    
                                                          
tc filter add dev $DEV parent 1:0 protocol ip prio 10 u32 \
  match ip dport 110 0xff flowid 1:10                     
                                                          
tc filter add dev $DEV parent 1:0 protocol ip prio 10 u32 \
  match ip dport 3999 0xff flowid 1:10                    
                                                          
tc filter add dev $DEV parent 1:0 protocol ip prio 10 u32 \
  match ip dport 8000 0xff flowid 1:10                    
                                                          
tc filter add dev $DEV parent 1:0 protocol ip prio 10 u32 \
  match ip dport 25 0xff flowid 1:10                      

# Поднять скорость входящего трафика, при наличии исходящего -- передать 
ACK-пакеты
# в интерактивный 
класс:                                                          

tc filter add dev $DEV parent 1: protocol ip prio 10 u32 \
  match ip protocol 6 0xff \                             
  match u8 0x05 0x0f at 0 \                              
  match u16 0x0000 0xffc0 at 2 \                         
  match u8 0x10 0xff at 33 \                             
  flowid 1:10                                            

tc filter add dev $DEV parent 1: protocol ip prio 16 u32 \
match ip dst 217.70.119.218 flowid 1:30                  

tc filter add dev $DEV parent 1: protocol ip prio 16 u32 \
match ip dst 80.64.94.12 flowid 1:10                     

#lenege
tc filter add dev $DEV parent 1: protocol ip prio 16 u32 \
match ip dst 89.249.27.112 flowid 1:10                   

tc filter add dev $DEV parent 1: protocol ip prio 16 u32 \
match ip dst 4.69.141.74 flowid 1:10

tc filter add dev $DEV parent 1: protocol ip prio 16 u32 \
match ip dst 217.70.119.181 flowid 1:10

tc filter add dev $DEV parent 1: protocol ip prio 16 u32 \
match ip dst 90.189.192.111 flowid 1:10

tc filter add dev $DEV parent 1: protocol ip prio 16 u32 \
match ip dst 212.164.71.12 flowid 1:10

tc filter add dev $DEV parent 1: protocol ip prio 16 u32 \
match ip dst 194.228.101.195 flowid 1:10

tc filter add dev $DEV parent 1: protocol ip prio 16 u32 \
match ip src 172.19.0.17 flowid 1:10

tc filter add dev $DEV parent 1: protocol ip prio 16 u32 \
match ip src 172.19.0.2 flowid 1:10

tc filter add dev $DEV parent 1: protocol ip prio 16 u32 \
match ip dst 217.18.158.27 flowid 1:10

# остальной трафик не является интерактивным поэтому он попадает в 1:20
########## входящий трафик #############
# необходимо несколько уменьшить скорость поступления входящего трафика,
# это предотвратит задержку пакетов в очередях у поставщика услуг.
# Поставщики имеют обыкновение увеличивать размеры очередей,
# поэтому, экспериментальным путем подберите требуемые значения,
# при которых скачивание будет происходить с максимальной скоростью.
#
# присоединить входной ограничитель:
tc qdisc add dev $DEV handle ffff: ingress
# сбрасывать все подряд (0.0.0.0/0), что приходит со слишком большой 
скоростью.
tc filter add dev $DEV parent ffff: protocol ip prio 50 u32 match ip src \
  0.0.0.0/0 police rate ${DOWNLINK}kbit burst 10k drop flowid :1

Re: [Comm] Как разделять узкую полосу пропускания для входящего трафика?

[Maxim Tyurin]

Денис Черносов writes:

> С тех пор, как перешли на безлимитный, но медленный интернет, есть
> задача разделить полосу пропускания по приоритетам и/или
> гарантированным полосам пропускания.
> Сначала настраивал в SQUID - всё понятно, всё настраивается (в т.ч. и
> по mime-типам). Одна беда - часть критически важного трафика плывет
> мимо него. Также за бортом остаются потенциально прожорливые протоколы
> типа torrent и ftp.
> Стал настраивать QoS в etcnet - немного разобрался, настроил по
> примеру... и обнаружил, что это всё для исходящего трафика, который
> для меня не сильно критичен (разве что веб-серверу легче будет
> немного).

А что мешает шейпить прожерливые torrent & ftp на интерфейсе который
смотрит в локалку?

-- 

With Best Regards, Maxim Tyurin
JID:	MrKooll@jabber.pibhe.com
   ___                                 
  / _ )__ _____  ___ ____ _______ _____
 / _  / // / _ \/ _ `/ _ `/ __/ // (_-<
/____/\_,_/_//_/\_, /\_,_/_/  \_,_/___/
               /___/  

Re: [Comm] Как разделять узкую полосу пропускания для входящего трафика?

[Денис Черносов]

21 января 2009 г. 22:44 пользователь Maxim Tyurin
<mrkooll@bungarus.info> написал:
> Денис Черносов writes:
>
>> С тех пор, как перешли на безлимитный, но медленный интернет, есть
>> задача разделить полосу пропускания по приоритетам и/или
>> гарантированным полосам пропускания.
>> Сначала настраивал в SQUID - всё понятно, всё настраивается (в т.ч. и
>> по mime-типам). Одна беда - часть критически важного трафика плывет
>> мимо него. Также за бортом остаются потенциально прожорливые протоколы
>> типа torrent и ftp.
>> Стал настраивать QoS в etcnet - немного разобрался, настроил по
>> примеру... и обнаружил, что это всё для исходящего трафика, который
>> для меня не сильно критичен (разве что веб-серверу легче будет
>> немного).
>
> А что мешает шейпить прожерливые torrent & ftp на интерфейсе который
> смотрит в локалку?

Прикольная идея... Надо обдумать...


>
> --
>
> With Best Regards, Maxim Tyurin
> JID:    MrKooll@jabber.pibhe.com
>   ___
>  / _ )__ _____  ___ ____ _______ _____
>  / _  / // / _ \/ _ `/ _ `/ __/ // (_-<
> /____/\_,_/_//_/\_, /\_,_/_/  \_,_/___/
>               /___/
> _______________________________________________
> community mailing list
> community@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/community

Re: [Comm] Как разделять узкую полосу пропускания для входящего трафика?

[Maks Re]

>> А что мешает шейпить прожерливые torrent & ftp на интерфейсе который
>> смотрит в локалку?
>
> Прикольная идея... Надо обдумать...
>

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


-- 
С уважением,
  Макс.

Re: [Comm] Как разделять узкую полосу пропускания для входящего трафика?

[Dmitriy Kruglikov]

22 января 2009 г. 15:43 пользователь Maks Re написал:

> Ну наврное тот факт что тогдла мы уже получили траффик а потом ограничили...

При таком ограничении, пока не будет принять пакет N, не будет передан
запрос на N+1 ...
Ограничение работать будет, канал будет забиваться значительно меньше...
Быстро пакет приплыл, канал освободил, ждет, когда будет передан с
локального интерфейса клиенту ...
Канал (внешний) свободен до получения квитанции на пакет
и запроса клиента на следующий ...

-- 
Как правильно задавать вопросы:
http://maddog.sitengine.ru/smart-question-ru.html

Помогает:
http://search.altlinux.org

Best regards,
 Dmitriy L. Kruglikov
 Dmitriy.Kruglikov_at_gmail_dot_com
 DKR6-RIPE
 DKR6-UANIC
 XMPP: Dmitriy.Kruglikov_at_gmail_dot_com

Re: [Comm] Как разделять узкую полосу пропускания для входящего трафика?

[Vasyuk_Maksim]

Maks Re пишет:
>>> А что мешает шейпить прожерливые torrent & ftp на интерфейсе который
>>> смотрит в локалку?
>>>       
>> Прикольная идея... Надо обдумать...
>>
>>     
>
> Ну наврное тот факт что тогдла мы уже получили траффик а потом ограничили...
> в большой сети - это метод воспитания.
> а в маленькой - оплата трафика...
>   
Так по полной управлять можешь только исходящим трафиком, или я ошибаюсь?

Re: [Comm] Как разделять узкую полосу пропускания для входящего трафика?

[Maxim Tyurin]

Vasyuk Maksim writes:

> Maks Re пишет:
>>>> А что мешает шейпить прожерливые torrent & ftp на интерфейсе который
>>>> смотрит в локалку?
>>>>       
>>> Прикольная идея... Надо обдумать...
>>>
>>>     
>>
>> Ну наврное тот факт что тогдла мы уже получили траффик а потом ограничили...
>> в большой сети - это метод воспитания.
>> а в маленькой - оплата трафика...
>>   
> Так по полной управлять можешь только исходящим трафиком, или я ошибаюсь?

Не ошибаешься. Шейпят исходящий трафик. На роутере на каком-то из
интерфейсов трафик будет исходящим. Вот там его и шейпить :)
-- 

With Best Regards, Maxim Tyurin
JID:	MrKooll@jabber.pibhe.com
   ___                                 
  / _ )__ _____  ___ ____ _______ _____
 / _  / // / _ \/ _ `/ _ `/ __/ // (_-<
/____/\_,_/_//_/\_, /\_,_/_/  \_,_/___/
               /___/  

Re: [Comm] Как разделять узкую полосу пропускания для входящего трафика?

[Денис Черносов]

Рассказываю как понял и прошу поправить, если ошибся...

На примере ftp и https:
В цепочке FORWARD мне нужно отлавливать пакеты с -o $LAN_IFACE
--src-address ! $LAN_NET + src-port 443 и src-port 20,21.

А потом одним гарантировать полосу, а другие замедлять по мере надобности.

Правильно?

Re: [Comm] Как разделять узкую полосу пропускания для входящего трафика?

[Maxim Tyurin]

Денис Черносов writes:

> Рассказываю как понял и прошу поправить, если ошибся...
>
> На примере ftp и https:
> В цепочке FORWARD мне нужно отлавливать пакеты с -o $LAN_IFACE
> --src-address ! $LAN_NET + src-port 443 и src-port 20,21.

Тут неправильно. Если нужно маркировать трафик для шейпера то это
делается в таблице mangle, а в ней нет FORWARD :)

> А потом одним гарантировать полосу, а другие замедлять по мере надобности.
>
> Правильно?

Вроде того. Только ftp-data ХЗ по какому порту пойдет.

Я всегда делаю три полосы. В более приоритетные направляю явно. Все
остальное - в третью полосу. 
-- 

With Best Regards, Maxim Tyurin
JID:	MrKooll@jabber.pibhe.com
   ___                                 
  / _ )__ _____  ___ ____ _______ _____
 / _  / // / _ \/ _ `/ _ `/ __/ // (_-<
/____/\_,_/_//_/\_, /\_,_/_/  \_,_/___/
               /___/  

Re: [Comm] Как разделять узкую полосу пропускания для входящего трафика?

[Денис Черносов]

23 января 2009 г. 12:38 пользователь Maxim Tyurin
<mrkooll@bungarus.info> написал:
> Денис Черносов writes:
>
>> Рассказываю как понял и прошу поправить, если ошибся...
>>
>> На примере ftp и https:
>> В цепочке FORWARD мне нужно отлавливать пакеты с -o $LAN_IFACE
>> --src-address ! $LAN_NET + src-port 443 и src-port 20,21.
>
> Тут неправильно. Если нужно маркировать трафик для шейпера то это
> делается в таблице mangle, а в ней нет FORWARD :)

Ну да, я просто сразу в две стороны думать начал :) Сначала в iptables
маркировать пакеты или сразу в правилах HTB фильтровать. Тоже
интересно - есть ли какие-то фундаментальные аргументы за тот или
другой способ (например, скорость обработки). Или это только дело
вкуса?

>> А потом одним гарантировать полосу, а другие замедлять по мере надобности.
>>
>> Правильно?
>
> Вроде того. Только ftp-data ХЗ по какому порту пойдет.

Я как раз про это и хотел уточнить. Мысль была такая, что если
исходящий трафик будет *на* порт (dst-port 80|443|21), то входящий
будет либо *с* того же порта, либо, как в случае с ftp, *с* другого
известного (src-port 80|443|20).

>
> Я всегда делаю три полосы. В более приоритетные направляю явно. Все
> остальное - в третью полосу.

Ну я тоже склоняюсь, что для моей задачи проще приоритетному трафику
гарантировать полосу, чем остальное урезать...

Есть также мысль к более приоритетным отнести все udp-пакеты. Чтобы с
ip-телефонией проблем было меньше и с другими поточными вещами. Есть в
этом смысл или лучше не стоит?


> --
>
> With Best Regards, Maxim Tyurin
> JID:    MrKooll@jabber.pibhe.com
>   ___
>  / _ )__ _____  ___ ____ _______ _____
>  / _  / // / _ \/ _ `/ _ `/ __/ // (_-<
> /____/\_,_/_//_/\_, /\_,_/_/  \_,_/___/
>               /___/
> _______________________________________________
> community mailing list
> community@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/community

Re: [Comm] Как разделять узкую полосу пропускания для входящего трафика?

[Maxim Tyurin]

Денис Черносов writes:

> Ну да, я просто сразу в две стороны думать начал :) Сначала в iptables
> маркировать пакеты или сразу в правилах HTB фильтровать. Тоже
> интересно - есть ли какие-то фундаментальные аргументы за тот или
> другой способ (например, скорость обработки). Или это только дело
> вкуса?

Дело вкуса. Я практически всегда использую маркировку в iptables.
Потому что это способ наиболее гибок. А больший оверхед меня не
смущает - оно у меня и на домашней WL-500gP без напряга работает :)

>
>>> А потом одним гарантировать полосу, а другие замедлять по мере надобности.
>>>
>>> Правильно?
>>
>> Вроде того. Только ftp-data ХЗ по какому порту пойдет.
>
> Я как раз про это и хотел уточнить. Мысль была такая, что если
> исходящий трафик будет *на* порт (dst-port 80|443|21), то входящий
> будет либо *с* того же порта, либо, как в случае с ftp, *с* другого
> известного (src-port 80|443|20).

ftp data пойдет с порта 20 на динамический 1024-65535 только в
активном режиме, а активный режим ftp редко импользуется ибо имеет
проблемы с NAT.
В пассивном режиме ftp используются динамические порты 1024-65535 с
обоих сторон.

>> Я всегда делаю три полосы. В более приоритетные направляю явно. Все
>> остальное - в третью полосу.
>
> Ну я тоже склоняюсь, что для моей задачи проще приоритетному трафику
> гарантировать полосу, чем остальное урезать...

А так ИМХО всегда лучше делать. Разрешения и привилегии лучше всегда
явно выдавать.

> Есть также мысль к более приоритетным отнести все udp-пакеты. Чтобы с
> ip-телефонией проблем было меньше и с другими поточными вещами. Есть в
> этом смысл или лучше не стоит?

Зависит от конкретных условий. Но в случае трех полос ИМХО редко когда
мешает засунуть udp во вторую полосу.
-- 

With Best Regards, Maxim Tyurin
JID:	MrKooll@jabber.pibhe.com
   ___                                 
  / _ )__ _____  ___ ____ _______ _____
 / _  / // / _ \/ _ `/ _ `/ __/ // (_-<
/____/\_,_/_//_/\_, /\_,_/_/  \_,_/___/
               /___/  

Re: [Comm] Как разделять узкую полосу пропускания для входящего трафика?

[Денис Черносов]

Что-то я туплю...
1) Добавил маркировку пакетов в mangle/PREROUTING. Если поставить
журналирование маркированных пакетов в filter/FORWARD, то видно, что
пакеты маркируются.

# cat /etc/net/ifaces/default/fw/iptables/mangle/PREROUTING
-i wan -p tcp -m tcp -m multiport --sports 443,25,110,143 -j MARK --set-mark 11
-i wan -p tcp -m tcp --sport 80 -j MARK --set-mark 12
...

# cat /etc/net/ifaces/default/fw/iptables/filter/FORWARD
-m mark --mark 11 -j LOG
-m mark --mark 12 -j LOG
...

# tail /var/log/messages
Jan 26 17:24:33 gate kernel: IN=wan OUT=lan SRC=81.177.9.109
DST=192.168.5.148 LEN=238 TOS=0x00 PREC=0x00 TTL=120 ID=16505 DF
PROTO=TCP SPT=443 DPT=3723 WINDOW=32430 RES=0x00 ACK PSH URGP=0
Jan 26 17:24:33 gate kernel: IN=wan OUT=lan SRC=217.74.44.32
DST=192.168.5.7 LEN=280 TOS=0x00 PREC=0x00 TTL=122 ID=22799 DF
PROTO=TCP SPT=443 DPT=5774 WINDOW=64453 RES=0x00 ACK PSH URGP=0
Jan 26 17:24:33 gate kernel: IN=wan OUT=lan SRC=81.177.9.109
DST=192.168.5.148 LEN=112 TOS=0x00 PREC=0x00 TTL=120 ID=18766 DF
PROTO=TCP SPT=443 DPT=3723 WINDOW=32430 RES=0x00 ACK PSH URGP=0
...


2) сделал три очереди (дефолтная 13):

# find /etc/net/ifaces/lan/
/etc/net/ifaces/lan/
/etc/net/ifaces/lan/qos
/etc/net/ifaces/lan/qos/1
/etc/net/ifaces/lan/qos/1/1
/etc/net/ifaces/lan/qos/1/1/13
/etc/net/ifaces/lan/qos/1/1/13/class
/etc/net/ifaces/lan/qos/1/1/extra
/etc/net/ifaces/lan/qos/1/1/class
/etc/net/ifaces/lan/qos/1/1/11
/etc/net/ifaces/lan/qos/1/1/11/class
/etc/net/ifaces/lan/qos/1/1/11/filter
/etc/net/ifaces/lan/qos/1/1/12
/etc/net/ifaces/lan/qos/1/1/12/class
/etc/net/ifaces/lan/qos/1/1/12/filter
/etc/net/ifaces/lan/qos/1/qdisc
/etc/net/ifaces/lan/ipv4address
/etc/net/ifaces/lan/options

# cat /etc/net/ifaces/lan/qos/1/qdisc
htb default 13

#cat /etc/net/ifaces/lan/qos/1/1/11/filter
protocol ip prio 1 handle 11 fw

Но пакеты попадают только в дефолтную очередь:

# eqos lan stat class
Interface is "lan"
Action is "stat"

"class" statistics on device lan:
class htb 1:11 parent 1:1 prio 0 quantum 1000 rate 64000bit ceil
100000Kbit burst 1631b/8 mpu 0b overhead 0b cburst 51599b/8 mpu 0b
overhead 0b level 0
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
 lended: 0 borrowed: 0 giants: 0
 tokens: 208895 ctokens: 4227

class htb 1:1 root rate 100000Kbit ceil 100000Kbit burst 51599b/8 mpu
0b overhead 0b cburst 51599b/8 mpu 0b overhead 0b level 7
 Sent 2700907 bytes 2419 pkt (dropped 0, overlimits 0 requeues 0)
 rate 240136bit 26pps backlog 0b 0p requeues 0
 lended: 0 borrowed: 0 giants: 0
 tokens: 4217 ctokens: 4217

class htb 1:13 parent 1:1 prio 0 quantum 200000 rate 100000Kbit ceil
100000Kbit burst 51599b/8 mpu 0b overhead 0b cburst 51599b/8 mpu 0b
overhead 0b level 0
 Sent 2700907 bytes 2419 pkt (dropped 0, overlimits 0 requeues 0)
 rate 234144bit 25pps backlog 0b 0p requeues 0
 lended: 2419 borrowed: 0 giants: 0
 tokens: 4217 ctokens: 4217

class htb 1:12 parent 1:1 prio 0 quantum 1000 rate 64000bit ceil
100000Kbit burst 1631b/8 mpu 0b overhead 0b cburst 51599b/8 mpu 0b
overhead 0b level 0
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
 lended: 0 borrowed: 0 giants: 0
 tokens: 208895 ctokens: 4227


Что я не так делаю?

Re: [Comm] Как разделять узкую полосу пропускания для входящего трафика?

[Денис Черносов]

Хелп энибади! Очень нужная фича на фирме.

Re: [Comm] Как разделять узкую полосу пропускания для входящего трафика?

[Денис Черносов]

Мать-мать... Заработало!

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

В статье с altlinux.org это было, а в примерах к пакету не было
нигде... (может быть багу повесить на документацию в пакете etcnet?)
В итоге, весь трафик уходил в дефолтную трубу, не проходя по цепочке.
Блин, ни разу не очевидное поведение :(

P.S. Остался еще невыясненный для меня вопрос: параметр prio. Обычно
он равен 1 для простого трафика и >1 для приоритетного. Можно ли
опускать этот параметр?

Re: [Comm] Как разделять узкую полосу пропускания для входящего трафика?

[Maks Re]

2009/1/28 Денис Черносов <denis0.ru@gmail.com>:
> Мать-мать... Заработало!
эм...
а не моглы бы вы для наглядности поправить статейку на вики
для дальнейший разборов так сказать...



-- 
С уважением,
  Макс.

Re: [Comm] Как разделять узкую полосу пропускания для входящего трафика?

[Денис Черносов]

29 января 2009 г. 0:22 пользователь Maks Re <admaks@gmail.com> написал:
> 2009/1/28 Денис Черносов <denis0.ru@gmail.com>:
>> Мать-мать... Заработало!
> эм...
> а не моглы бы вы для наглядности поправить статейку на вики
> для дальнейший разборов так сказать...

Сегодня никак. Завтра или на выходных постараюсь.
Хотя нужно не столько статью править, сколько примеры QoS в etcnet.
Потому что именно там нужного фильтра нет (а я решил, что пакет новее
статьи и не стал эту команду включать)... Или делать так, чтобы
поведение системы соответствовало примерам :)


>
>
>
> --
> С уважением,
>  Макс.
> _______________________________________________
> community mailing list
> community@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/community

Re: [Comm] Как разделять узкую полосу пропускания для входящего трафика?

[Денис Черносов]

29 января 2009 г. 0:22 пользователь Maks Re <admaks@gmail.com> написал:

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

Поправил совсем чуть-чуть:
http://www.altlinux.org/index.php?title=Etcnet_QoS&diff=8884&oldid=7182


-- 
С уважением,
Черносов Денис

Re: [Comm] Как разделять узкую полосу пропускания для входящего трафика?

[Vasyuk_Maksim]

Maks Re пишет:
>>> А что мешает шейпить прожерливые torrent & ftp на интерфейсе который
>>> смотрит в локалку?
>>>       
>> Прикольная идея... Надо обдумать...
>>
>>     
>
> Ну наврное тот факт что тогдла мы уже получили траффик а потом ограничили...
> в большой сети - это метод воспитания.
> а в маленькой - оплата трафика...
>   
Так по полной управлять можешь только исходящим трафиком, или я ошибаюсь?

Re: [Comm] Как разделять узкую полосу пропускания для входящего трафика?

[Alexey Borovskoy]

[-- Attachment #1: Type: text/plain, Size: 415 bytes --]

* Пятница 16 января 2009 Денис Черносов

> С тех пор, как перешли на безлимитный, но медленный интернет,
> есть задача разделить полосу пропускания по приоритетам и/или
> гарантированным полосам пропускания.

А как каждому хосту внутри сети выдать определенную полосу, в 
зависимости от сети назрачения? Не городя кучу фильтров.


-- 
Алексей.
GPG key fingerprint
949B BC0E 2C44 7528 4F63  2753 E37A 9E3F 11F3 BDE1

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [Comm] Как разделять узкую полосу пропускания для входящего трафика?

[Денис Черносов]

2 февраля 2009 г. 12:38 пользователь Alexey Borovskoy
<alexey.borovskoy@gmail.com> написал:
> * Пятница 16 января 2009 Денис Черносов
>
>> С тех пор, как перешли на безлимитный, но медленный интернет,
>> есть задача разделить полосу пропускания по приоритетам и/или
>> гарантированным полосам пропускания.
>
> А как каждому хосту внутри сети выдать определенную полосу, в
> зависимости от сети назрачения? Не городя кучу фильтров.

Для веб-трафика, можно правилами squid-а. Там есть соотв -е правила.
Причём, можно не только для веб, но и для всего, что может работать
через http-прокси. Только для соотв. софта нужно будет руками
настройки на клиентах выставлять, потому что для проксирования.

В общем же случае, мне самым простым и идеологически выдержанным
видится поднятие pppoe-сервера и раздачу инета только через него.
Ширину каждого виртуального канала можно настраивать, если я ничего не
путаю...



-- 
С уважением,
Черносов Денис