NiTr0 Опубликовано 23 февраля, 2009 · Жалоба Заметил весьма странное поведение шейпера на 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. Кто-то сталкивался с таким? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Minkevich Опубликовано 23 февраля, 2009 · Жалоба да постоянно на чистом линуксе подручными средставми когда делался шейпинг - были проблемы. решили установкой микротика. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 23 февраля, 2009 · Жалоба Неохота плодить разнотипные оси по серверам, хотелось бы максимальной совместимости... Да и к "особенностям работы" конкретной оси привыкать прийдется... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 23 февраля, 2009 · Жалоба А что по вашему должен резать корневой класс? Сумма rate дочерних классов не должна превышать rate корневого. Если вы хотите чтоб общая скорость дочерних была не выше rate корневого. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 24 февраля, 2009 · Жалоба Очевидно в LARTC по этому поводу ошиблись... Попробую уполовинить rate и добавить ceil=лимиту скорости, посмотрю на поведение... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Max P Опубликовано 26 февраля, 2009 · Жалоба а может знает кто как сделать в 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 первое правило пришло Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Max P Опубликовано 26 февраля, 2009 · Жалоба хм... нашел вариант пока просто указывать пачку команд типа 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 по порядку, но что то как то это неаккуратненько, контроля нет Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 26 февраля, 2009 · Жалоба Почитайте http://ace-host.stuart.id.au/russell/files...doc/cls_u32.txt Может поможет Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Max P Опубликовано 26 февраля, 2009 · Жалоба спасибо, забористая трава *ушел курить Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Max P Опубликовано 26 февраля, 2009 · Жалоба ну короче понятно, все хэндлы всё равно будут >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: так что наверно просто оставлю то что сделал раньше Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 26 февраля, 2009 · Жалоба Неправда Посмотрите пример у меня в 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 ) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Max P Опубликовано 26 февраля, 2009 · Жалоба хм... странно... у меня не давал такие хэндлы делать... попробую еще поэксперементировать вот кстате вопросец по вашему примеру - имеет ли смысл для дефолта делать tc filter, если при этом в tc class ... default указано? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 26 февраля, 2009 · Жалоба Смысл есть У меня были непонятные глюки(пропадание траффика), если не делать "закрывающий" фильтр. А HFSC так вообще кажется остановит весь траффик который не классифицирован (там еще по хитрому надо ARP добавить) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Max P Опубликовано 26 февраля, 2009 · Жалоба хм... у меня сейчас всё на hfsс, хоть и arp нет, но по match ip всё уже год четко работает, кстати hfsc довольно точно канал режет короче распилил фильтры по пятку хэш-таблиц в соответствии с классами, думаю оставить так, ибо трава в u32 все таки забористая :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Max P Опубликовано 26 февраля, 2009 · Жалоба короче провел эксперимент, скрипт: # Расшариваемый поток 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 вот и фиг знает как это понимать :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 27 февраля, 2009 · Жалоба короче провел эксперимент, скрипт:... вот и фиг знает как это понимать :) В моем скрипте стояла задача сделать цепочку, чтоб фильтровать сначала по маку, а потом несколько "ветвей" где фильтруем контент идущий на этот мак Я просто привел это как пример, что можно контролировать различные параметры. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...