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

[NiTr0]

Заметил весьма странное поведение шейпера на 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.

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

[Minkevich]

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

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

[NiTr0]

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

[nuclearcat]

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

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

[NiTr0]

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

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

 

[Max P]

а может знает кто как сделать в 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 первое правило пришло

[Max P]

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

 

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 по порядку, но что то как то это неаккуратненько, контроля нет

[nuclearcat]

Почитайте http://ace-host.stuart.id.au/russell/files...doc/cls_u32.txt

Может поможет

[Max P]

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

 

*ушел курить

[Max P]

ну короче понятно, все хэндлы всё равно будут >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: так что наверно просто оставлю то что сделал раньше

[nuclearcat]

Неправда

Посмотрите пример у меня в 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 )

 

[Max P]

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

 

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

[nuclearcat]

Смысл есть

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

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

[Max P]

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

 

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

[Max P]

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

# Расшариваемый поток
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

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

[nuclearcat]

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

...

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

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

 

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