LINUX.ORG.RU
ФорумAdmin

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


0

0

Заинтересовал сабж, внятного описания так и не нашёл.

Есть свой сервер, на котором установлено соединение с удалённым VPN-сервером. Этот свой раздаёт на четыре компа интернет через pptpd. Стоит задача равномерного размазывания полосы (1 Мбит/с download, 512 Кбит/с upload) между этими четырьмя компами. Необходимо, чтобы балансировка осуществлялась динамически, т.е. если все 4 качают на полной скорости, то им канал будет разделён на 4 части, а если 2 качают, то на 2 части. Также хотелось бы, чтобы в пределах одного айпишника трафик равномерно размазывался на все соединения. А ещё желательно иметь отдельные гарантированные полосы для, например, ssh.

Вот и вопрос, как это сделать? И если можно, кроме кода внятные комментарии.

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

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

AFAIK, HTB?

nnz ★★★★
()
Ответ на: комментарий от post-factum

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

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

nnz ★★★★
()
Ответ на: комментарий от post-factum

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

nnz ★★★★
()

# повесить дисциплину на устройство
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

как-то так

azure ★★
()
Ответ на: комментарий от nnz

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

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

flowid 1:10

flowid 1:11

конечно же

azure ★★
()
Ответ на: комментарий от post-factum

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

tc q a dev eth0 parent 1:10 sfq

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

azure ★★
()
Ответ на: комментарий от post-factum

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

nnz ★★★★
()
Ответ на: комментарий от azure

>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:

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

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

d0b
()
Ответ на: комментарий от d0b

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

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

azure ★★
()
Ответ на: комментарий от azure

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

d0b
()
Ответ на: комментарий от d0b

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

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

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

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

azure ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.