Шейпинг трафика с помощью tc

>Заинтересовал сабж, внятного описания так и не нашёл.
http://lartc.org/howto/

>Также хотелось бы, чтобы в пределах одного айпишника трафик равномерно размазывался на все соединения.
AFAIK, HTB?

А случайно не sfq?

Емнип, SFQ распределяет канал между потоками, а не айпишниками. Т.е. один айпишник с кучей коннектов сожрет весь канал.

Впрочем, я не спец по tc, поэтому мои слова не есть абсолютная истина ;)

А случайно не sfq? между потоками - sfq

Да, сорри, я не ту часть сообщения процитировал.
HTB поможет по-честному распределить трафик между айпишниками. Вот.

# повесить дисциплину на устройство
tc q a dev eth0 root handle 1: htb
# к ней коревой класс прицепить. Он будет гарантировать что больше 1 мбит через него не пройдет
tc c a dev eth0 parent 1: classid 1:1 htb rate 1024kbit
# класс для первого абонента. гарантия на 256 кбит\с с возможностью заимствования до 1024кбит\с
tc c a dev eth0 parent 1:1 classid 1:10 htb rate 256kbit ceil 1024kbit
tc c a dev eth0 parent 1:1 classid 1:11 htb rate 256kbit ceil 1024kbit
tc c a dev eth0 parent 1:1 classid 1:12 htb rate 256kbit ceil 1024kbit
tc c a dev eth0 parent 1:1 classid 1:13 htb rate 256kbit ceil 1024kbit
# далее, фильтрами раскидать трафик куда надо:
tc f a dev eth0 protocol ip prio 10 parent root u32 match ip dst 192.168.1.10 0xffff flowid 1:10
tc f a dev eth0 protocol ip prio 10 parent root u32 match ip dst 192.168.1.20 0xffff flowid 1:20
tc f a dev eth0 protocol ip prio 10 parent root u32 match ip dst 192.168.1.30 0xffff flowid 1:30
tc f a dev eth0 protocol ip prio 10 parent root u32 match ip dst 192.168.1.40 0xffff flowid 1:40

как-то так

>classid 1:10
>classid 1:11
>...
>flowid 1:10
>flowid 1:20
>...

Оно так и должно быть?

А как тут sfq прицепить?

> Оно так и должно быть?

Не-не-не :) затупил.

flowid 1:10

flowid 1:11

конечно же

> А как тут sfq прицепить?

tc q a dev eth0 parent 1:10 sfq

как-то так (пишу по памяти)

Всем спасибо, вроде как разобрался.

Если не секрет, каков окончательный вариант?

>tc f a dev eth0 protocol ip prio 10 parent root u32 match ip dst 192.168.1.10 0xffff flowid 1:10

Разве тут в фильтре не src вместо dst прописывать нужно? ИМХО тут destination вообще не при делах, так как мы ограничиваем только исходящий трафик. А шейпить входящим возможно только на imq или подобных виртуальных интерфейсах.

По поводу sfq, то как-то так:

tc qdisc add dev eth0 parent 1:10 handle 10: sfq perturb 10

И соответственно в фильтре меняем flowid 10:

Может, конечно, где то и ошибся, пишу по памяти.

А вообще в самом начале ссылку давали на очень неплохой материал. Стоит прочтения.

> Разве тут в фильтре не src вместо dst прописывать нужно? ИМХО тут destination вообще не при делах, так как мы ограничиваем только исходящий трафик. А шейпить входящим возможно только на imq или подобных виртуальных интерфейсах.

ну мы то шейпим на интерфейсе, который смотрит к клиентам. И там у пакета по dst надо смотреть, к кому он идет.

Ну так клиенты то подключаются по pptp, а следовательно тогда дисциплины необходимо вешать аж никак не на eth0, а на каждый pppX. Но это ИМХО геморно... Это если бы они были через NAT, и при этом интерфейс eth0 смотрел бы как раз в локалку, то тогда да... А в данном случае проще, и скорее всего правильно, вешать дисциплины на канал, который смотрит в инет. И это получиться только для исходящего трафика. Для входящего - придется создавать что то типа imq или fbi. Сам сейчас с этим разбираюсь. Хотя возможно есть вариант написать скрипт для ppp-up. В общем в данной теме еще есть над чем подумать.

> Ну так клиенты то подключаются по pptp....

наверно, я ночью читал, и упустил это из виду. с pptp вплотную не работал, не знаю как там.

> А в данном случае проще, и скорее всего правильно, вешать дисциплины на канал, который смотрит в инет. И это получиться только для исходящего трафика. Для входящего - придется создавать что то типа imq или fbi. Сам сейчас с этим разбираюсь. Хотя возможно есть вариант написать скрипт для ppp-up. В общем в данной теме еще есть над чем подумать.

да, сейчас пытаюсь все делать через IFB: результат меня пока не удовлетворяет. То ли HTB недодумана, то ли я лыжник в непогоду, но htb не дропает лишние пакеты, и из-за этого весьма значительно возрастает задержка (300мс и более только из-за того, что htb все держит в очереди).