Jump to content
Калькуляторы

Linux - парадокс с шейперами

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

Вот в один из моментов сделал tc -d class show:

class htb 1:1 root rate 256000bit ceil 256000bit burst 512Kb cburst 1632b
Sent 364162938 bytes 451587 pkt (dropped 0, overlimits 0 requeues 0)
rate 459320bit 59pps backlog 0b 0p requeues 0
lended: 0 borrowed: 0 giants: 0
tokens: -59999999 ctokens: -59999999

class htb 1:10 parent 1:1 leaf 10: prio 1 rate 256000bit ceil 256000bit burst 512Kb cburst 1632b
Sent 68378042 bytes 50855 pkt (dropped 0, overlimits 0 requeues 0)
rate 203456bit 18pps backlog 0b 0p requeues 0
lended: 50855 borrowed: 0 giants: 0
tokens: 16340250 ctokens: 7250

class htb 1:20 parent 1:1 leaf 20: prio 2 rate 256000bit ceil 256000bit burst 512Kb cburst 1632b
Sent 296048886 bytes 400799 pkt (dropped 2589, overlimits 0 requeues 0)
rate 256336bit 41pps backlog 0b 67p requeues 0
lended: 400732 borrowed: 0 giants: 0
tokens: 16245600 ctokens: -87400

Как видно, родительский класс отказывается резать скорость. Вопрос - почему?

 

Вот кусок if-up.local, отвечающий за установку шейпера:

UBURST="burst 512k"
..............
     /sbin/tc qdisc add dev $1 root handle 1: htb default 20 r2q 100
     /sbin/tc class add dev $1 parent 1: classid 1:1 htb rate ${UPSPEED}kbit $UBURST quantum 1514
     /sbin/tc class add dev $1 parent 1:1 classid 1:10 htb rate ${UPSPEED}kbit $UBURST prio 1 quantum 1514
     /sbin/tc class add dev $1 parent 1:1 classid 1:20 htb rate ${UPSPEED}kbit $UBURST prio 2 quantum 1514
     /sbin/tc qdisc add dev $1 parent 1:10 handle 10: sfq perturb 10 quantum 1514
     /sbin/tc qdisc add dev $1 parent 1:20 handle 20: sfq perturb 10 quantum 1514
     /sbin/tc filter add dev $1 parent 1:0 protocol ip prio 10 u32 match ip tos 0x10 0xff flowid 1:10
     /sbin/tc filter add dev $1 parent 1:0 protocol ip prio 10 u32 match ip protocol 1 0xff flowid 1:10

Наблюдается на CentOS 5.1 и Fedora 8 (2.6.18 и 2.6.23 ядра соответственно). Ядра - из репозитория, источник клока для шейперов - gettimeofday.

Кто-то сталкивался с таким?

Share this post


Link to post
Share on other sites

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

решили установкой микротика.

Share this post


Link to post
Share on other sites

Неохота плодить разнотипные оси по серверам, хотелось бы максимальной совместимости... Да и к "особенностям работы" конкретной оси привыкать прийдется...

Share this post


Link to post
Share on other sites

А что по вашему должен резать корневой класс?

Сумма rate дочерних классов не должна превышать rate корневого. Если вы хотите чтоб общая скорость дочерних была не выше rate корневого.

Share this post


Link to post
Share on other sites

Очевидно в LARTC по этому поводу ошиблись...

Попробую уполовинить rate и добавить ceil=лимиту скорости, посмотрю на поведение...

 

Share this post


Link to post
Share on other sites

а может знает кто как сделать в tc filter такую вот вещь:

 

filter parent 1: protocol ip pref 5 u32

filter parent 1: protocol ip pref 5 u32 fh 801: ht divisor 1

 

чтобы жестко задать руками вот это вот pref и fh, скажем pref 1 fh 800:, pref 2 fh 801: и т.д. ибо при удалении правила из фильтра нужно задавать полностью все правило, включая fh, если просто добавлять tc filter правила, то fh будет каждый раз разный, в зависимости от того с каким pref первое правило пришло

Share this post


Link to post
Share on other sites

хм... нашел вариант пока просто указывать пачку команд типа

 

tc filter add parent 1: protocol ip pref 1 dev $DEV u32

....

tc filter add parent 1: protocol ip pref 5 dev $DEV u32

 

тогда tc само проставляет fh по порядку, но что то как то это неаккуратненько, контроля нет

Share this post


Link to post
Share on other sites

спасибо, забористая трава

 

*ушел курить

Share this post


Link to post
Share on other sites

ну короче понятно, все хэндлы всё равно будут >800, пример:

 

tc filter add parent 1: protocol ip prio 1 dev $DEV u32 ht 1: divisor 1

 

добавит нечто типа

 

filter parent 1: protocol ip pref 1 u32

filter parent 1: protocol ip pref 1 u32 fh 801: ht divisor 1

filter parent 1: protocol ip pref 1 u32 fh 800: ht divisor 1

 

то есть корневой хэндл 800:: будет всегда, его tc добавляет автоматом, а указанный ht 1: будет 801: так что наверно просто оставлю то что сделал раньше

Share this post


Link to post
Share on other sites

Неправда

Посмотрите пример у меня в wiki

http://www.nuclearcat.com/mediawiki/index....U32_tips_tricks

 

Вывод от него выглядит где-то так (кусок)

ilter parent 1: protocol ip pref 9 u32 fh 801: ht divisor 1

filter parent 1: protocol ip pref 10 u32

filter parent 1: protocol ip pref 10 u32 fh 1: ht divisor 1

filter parent 1: protocol ip pref 10 u32 fh 1::800 order 2048 key ht 1 bkt 0 flowid 1:20 (rule hit 0 success 0)

match d997e01d/ffffffff at 12 (success 0 )

filter parent 1: protocol ip pref 10 u32 fh 1::801 order 2049 key ht 1 bkt 0 flowid 1:20 (rule hit 0 success 0)

match 00010000/00ff0000 at 8 (success 0 )

filter parent 1: protocol ip pref 10 u32 fh 1::802 order 2050 key ht 1 bkt 0 flowid 1:20 (rule hit 0 success 0)

match 00160000/00ff0000 at 20 (success 0 )

filter parent 1: protocol ip pref 10 u32 fh 1::803 order 2051 key ht 1 bkt 0 flowid 1:20 (rule hit 0 success 0)

match 00000016/000000ff at 20 (success 0 )

filter parent 1: protocol ip pref 10 u32 fh 1::804 order 2052 key ht 1 bkt 0 flowid 1:20 (rule hit 0 success 0)

 

бла бла бла

 

ilter parent 1: protocol ip pref 10 u32 fh 800: ht divisor 1

filter parent 1: protocol ip pref 100 u32

filter parent 1: protocol ip pref 100 u32 fh 802: ht divisor 1

filter parent 1: protocol ip pref 999 u32

filter parent 1: protocol ip pref 999 u32 fh 803: ht divisor 1

filter parent 1: protocol ip pref 999 u32 fh 803::800 order 2048 key ht 803 bkt 0 flowid 1:3 (rule hit 2030354013 success 2030354013)

match 00000000/00000000 at 16 (success 2030354013 )

filter parent 1: protocol arp pref 1000 u32

filter parent 1: protocol arp pref 1000 u32 fh 804: ht divisor 1

filter parent 1: protocol arp pref 1000 u32 fh 804::800 order 2048 key ht 804 bkt 0 flowid 1:3 (rule hit 44321 success 44321)

match 00000000/00000000 at 0 (success 44321 )

 

Share this post


Link to post
Share on other sites

хм... странно... у меня не давал такие хэндлы делать... попробую еще поэксперементировать

 

вот кстате вопросец по вашему примеру - имеет ли смысл для дефолта делать tc filter, если при этом в tc class ... default указано?

Share this post


Link to post
Share on other sites

Смысл есть

У меня были непонятные глюки(пропадание траффика), если не делать "закрывающий" фильтр.

А HFSC так вообще кажется остановит весь траффик который не классифицирован (там еще по хитрому надо ARP добавить)

Share this post


Link to post
Share on other sites

хм... у меня сейчас всё на hfsс, хоть и arp нет, но по match ip всё уже год четко работает, кстати hfsc довольно точно канал режет

 

короче распилил фильтры по пятку хэш-таблиц в соответствии с классами, думаю оставить так, ибо трава в u32 все таки забористая :)

Share this post


Link to post
Share on other sites

короче провел эксперимент, скрипт:

# Расшариваемый поток
tc class add dev ${DEV} parent 1: classid 1:1 hfsc rt rate ${ROOTRATE}kbit ls rate ${ROOTRATE}kbit ul rate ${ROOTRATE}kbit
tc filter add dev $DEV protocol ip prio 1 parent 1: handle 1: u32 divisor 1

# Direct Traffic
tc class add dev ${DEV} parent 1:1 classid 1:2 hfsc sc m1 0 d 1s m2 $[65*$ROOTRATE/100]kbit ul rate ${ROOTRATE}kbit
tc qdisc add dev ${DEV} parent 1:2 handle 2: sfq perturb 10
tc filter add dev $DEV protocol ip prio 2 parent 1: handle 2: u32 divisor 1

# Unlimits root class
tc class add dev ${DEV} parent 1:1 classid 1:3 hfsc sc m1 0 d 1s m2 $[35*$ROOTRATE/100]kbit ul rate ${ROOTRATE}kbit
tc filter add dev $DEV protocol ip prio 3 parent 1: handle 3: u32 divisor 1

# Unlimits normal class
tc class add dev ${DEV} parent 1:3 classid 1:4 hfsc sc m1 0 d 1s m2 $[25*$ROOTRATE/100]kbit ul rate ${ROOTRATE}kbit
tc filter add dev $DEV protocol ip prio 4 parent 1: handle 4: u32 divisor 1

# Unlimits restrict class
tc class add dev ${DEV} parent 1:3 classid 1:5 hfsc sc m1 0 d 1s m2 $[10*$ROOTRATE/100]kbit ul rate ${ROOTRATE}kbit
tc filter add dev $DEV protocol ip prio 5 parent 1: handle 5: u32 divisor 1

в итоге на выходе получается следующая петрушка:

root@office2:~# tc -s filter show dev eth0
filter parent 1: protocol ip pref 1 u32 
filter parent 1: protocol ip pref 1 u32 fh 1: ht divisor 1 
filter parent 1: protocol ip pref 1 u32 fh 800: ht divisor 1 
filter parent 1: protocol ip pref 2 u32 
filter parent 1: protocol ip pref 2 u32 fh 2: ht divisor 1 
filter parent 1: protocol ip pref 2 u32 fh 801: ht divisor 1 
filter parent 1: protocol ip pref 3 u32 
filter parent 1: protocol ip pref 3 u32 fh 3: ht divisor 1 
filter parent 1: protocol ip pref 3 u32 fh 802: ht divisor 1 
filter parent 1: protocol ip pref 4 u32 
filter parent 1: protocol ip pref 4 u32 fh 4: ht divisor 1 
filter parent 1: protocol ip pref 4 u32 fh 803: ht divisor 1 
filter parent 1: protocol ip pref 5 u32 
filter parent 1: protocol ip pref 5 u32 fh 5: ht divisor 1 
filter parent 1: protocol ip pref 5 u32 fh 804: ht divisor 1

вот и фиг знает как это понимать :)

Share this post


Link to post
Share on other sites
короче провел эксперимент, скрипт:

...

вот и фиг знает как это понимать :)

В моем скрипте стояла задача сделать цепочку, чтоб фильтровать сначала по маку, а потом несколько "ветвей" где фильтруем контент идущий на этот мак

 

Я просто привел это как пример, что можно контролировать различные параметры.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this