настройка tc (скорость закачки и отдачи для конкретного ip)

[Tokra]

Доброго времени суток господа. Сразу перейду к сути вопроса.
Есть общий канал шириной 10 mbit/s. Есть 6 айпи (считайте конечных пользователей), для которых необходимо поделить канал исходя из 1 mbit/s на закачку и столько же на отдачу. Стоит сервер под linux. Пакеты iptables и iproute установлены. На сервере интерфейс eth0 смотрит во внутреннею сеть (ip 192.168.20.1), eth1 в internet (ip допустим 195.1.1.1).
После перелопачивания всей доступной информации по tc , я предполагаю, что мою задачу можно решить таким способом:
1) Создаем дисциплину обработки очереди на устройстве eth0
tc qdisc add dev eth0 root handle 1: htb default 10
2) Создаем родительский класс
tc class add dev eth0 parent 1: classid 1:1 htb rate 100mbit ceil 100mbit burst 15k
3) Создаем дочерний класс с соответствующей скоростью
tc class add dev eth0 parent 1:1 classid 1:10 htb rate 1mbit ceil 1mbit burst 15k
5) Дальше маркируем трафик, с помощью tc filter :
tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip src 0.0.0.0/0 match ip dst 192.168.20.10 flowid 1:10 /*это скорость закачки для клиента с ip 192.168.20.10*/
tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip src 192.168.20.10 match ip dst 0.0.0.0/0 flowid 1:10 /*скорость отдачи для клиента. Или здесь я не прав???*/
tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip src 0.0.0.0/0 match ip dst 192.168.20.11 flowid 1:10
tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip src 192.168.20.11 match ip dst 0.0.0.0/0 flowid 1:10
И так далее для всех 6 ip.
Правильно ли я реализовал поставленную задачу? Или мне необходимо создать еще и отдельный qdisc для eth1 и на нем резать пакеты идущие от клиента в интернет. Дубу благодарен за ответы.

[danger08]

http://www.opennet.ru/docs/RUS/LARTC/x2755.html

[Tokra]

http://www.opennet.ru/docs/RUS/LARTC/x2755.html

В этом руководстве нет ответа на мой вопрос. А вопрос стоит именно в том, как организовать для конечного клиента гарантированую скорость закачки и отдачи. В howto этого не описано. Везде пишется, что tc умеет шейпить только исходящий трафик с интерфейса. Отсюда делам вывод, что исходящий трафик с интерфейса eth0, который, смотрит во внутреннюю сеть будет входящим для конечного клиента, соответственно его скорость будет скоростью закачки для клиента. Остается вопрос, как задать скоость отдачи для конечного клиента?

[alfss]

....

[danger08]

http://www.opennet.ru/docs/RUS/LARTC/x2755.html

В этом руководстве нет ответа на мой вопрос. А вопрос стоит именно в том, как организовать для конечного клиента гарантированую скорость закачки и отдачи. В howto этого не описано.

Описано, вы просто не увидели.

Везде пишется, что tc умеет шейпить только исходящий трафик с интерфейса. Отсюда делам вывод, что исходящий трафик с интерфейса eth0, который, смотрит во внутреннюю сеть будет входящим для конечного клиента, соответственно его скорость будет скоростью закачки для клиента. Остается вопрос, как задать скоость отдачи для конечного клиента?

А по аналогии, подумать, что исходящий от клиента трафик можно шейпить на интерфейсе, глядящем в интернет (eth1)?

На каждом интерфейсе создаете по дисциплине, на eth0 для шейпинга исходящего к клиенту ("закачка" с точки зрения клиента); на eth1 для шейпинга исходящего в инет от клиента ("отдача" с точки зрения клиента).

[Tokra]

http://www.opennet.ru/docs/RUS/LARTC/x2755.html

В этом руководстве нет ответа на мой вопрос. А вопрос стоит именно в том, как организовать для конечного клиента гарантированую скорость закачки и отдачи. В howto этого не описано.

Описано, вы просто не увидели.

Везде пишется, что tc умеет шейпить только исходящий трафик с интерфейса. Отсюда делам вывод, что исходящий трафик с интерфейса eth0, который, смотрит во внутреннюю сеть будет входящим для конечного клиента, соответственно его скорость будет скоростью закачки для клиента. Остается вопрос, как задать скоость отдачи для конечного клиента?

А по аналогии, подумать, что исходящий от клиента трафик можно шейпить на интерфейсе, глядящем в интернет (eth1)?

На каждом интерфейсе создаете по дисциплине, на eth0 для шейпинга исходящего к клиенту ("закачка" с точки зрения клиента); на eth1 для шейпинга исходящего в инет от клиента ("отдача" с точки зрения клиента).

На счет того, необходимо ли создавать отдельную дисциплину на eth1 я как раз спрашивал в самом начале свое поста.

Или мне необходимо создать еще и отдельный qdisc для eth1 и на нем резать пакеты идущие от клиента в интернет.

Меня волновал один нюанс, будет ли эта дисциплина корректно работать с натом?

в настройка нат реализован так:

iptables -t nat -A POSTROUTING -s 192.168.20.0/255.255.255.0 -o eth1 -j SNAT --to-source 195.1.1.1

Создаем правило фильтра tc на интерфесе eth1 (корневая дисциплина и классы для eth1 созданы)

tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip src 192.168.20.11 flowid 1:10

Вопрос в том, tc маркирует пакеты до того момента, как было принято решение о маршрутизации и ставит их в нужную очередь или уже после?

[danger08]

Меня волновал один нюанс, будет ли эта дисциплина корректно работать с натом?

в настройка нат реализован так:

iptables -t nat -A POSTROUTING -s 192.168.20.0/255.255.255.0 -o eth1 -j SNAT --to-source 195.1.1.1

Создаем правило фильтра tc на интерфесе eth1 (корнева дисциплина и классы для eth1 созданы)

tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip src 192.168.20.11 flowid 1:10

Вопрос в том, tc маркирует пакеты до того момента, как было принято решение о маршрутизации и ставит их в нужную очередь или уже после?

Пакеты маркируются в таблице *mangle, а snat в таблице *nat.
Здесь рассмотрена последовательность прохождения пакета по цепочкам. видно, что `mange PREROUTING` делается заведомо ранее, `nat POSTROUTING`, т.е. к моменту выполнения действия `SNAT` вы будете иметь возможность промаркировать пакеты от локальных клиентов.

Момент активизации правил, описанных очередью - и как следствие, шейпинг (как я понимаю). всегда один - после прохождения всех цепочек абсолютно, и выходе пакетов "в свет" (то бишь, когда пакеты физически покидают роутер через физический интерфейс, на котором навешана дисциплина).

[Tokra]

Меня волновал один нюанс, будет ли эта дисциплина корректно работать с натом?

в настройка нат реализован так:

iptables -t nat -A POSTROUTING -s 192.168.20.0/255.255.255.0 -o eth1 -j SNAT --to-source 195.1.1.1

Создаем правило фильтра tc на интерфесе eth1 (корнева дисциплина и классы для eth1 созданы)

tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip src 192.168.20.11 flowid 1:10

Вопрос в том, tc маркирует пакеты до того момента, как было принято решение о маршрутизации и ставит их в нужную очередь или уже после?

Пакеты маркируются в таблице *mangle, а snat в таблице *nat.
Здесь рассмотрена последовательность прохождения пакета по цепочкам. видно, что `mange PREROUTING` делается заведомо ранее, `nat POSTROUTING`, т.е. к моменту выполнения действия `SNAT` вы будете иметь возможность промаркировать пакеты от локальных клиентов.

Момент активизации правил, описанных очередью - и как следствие, шейпинг (как я понимаю). всегда один - после прохождения всех цепочек абсолютно, и выходе пакетов "в свет" (то бишь, когда пакеты физически покидают роутер через физический интерфейс, на котором навешана дисциплина).

Как проходят пакеты по цепочкам я знаю. Вопрос в том, tc filter маркирут пакет до SNAT или после (я, просто, не собираюсь для маркировки пакетов использовать iptables)?

Если сначала tc filter маркирут пакет по правилу

Код: Выделить всё

tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip src 192.168.20.11 flowid 1:10

затем ставит его в нужную очередь. После этого ядро решает как маршрутизировать этот пакет. И только тогда iptables делает свое дело

Код: Выделить всё

iptables -t nat -A POSTROUTING -s 192.168.20.0/255.255.255.0 -o eth1 -j SNAT --to-source 195.1.1.1

тогда, вроде, все должно работать.
А если наоборот... Тут появляются вопросы...

[danger08]

Вопрос в том, tc filter маркирут пакет до SNAT или после (я, просто, не собираюсь для маркировки пакетов использовать iptables)?

К сожалению, после SNAT (поскольку все рутины tc работают после всех преобразований, перед диспетчеризацией).
Если хотите типа критерий `ip src` и чтоб SNAT работал, то надо маркировать через iptables.

Если сначала tc filter маркирут пакет по правилу

Код: Выделить всё

tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip src 192.168.20.11 flowid 1:10

затем ставит его в нужную очередь. После этого ядро решает как маршрутизировать этот пакет. И только тогда iptables делает свое дело

Код: Выделить всё

iptables -t nat -A POSTROUTING -s 192.168.20.0/255.255.255.0 -o eth1 -j SNAT --to-source 195.1.1.1

Нет, дело обстоит так: пакетный фильтр делает свою работу и преобразования. tc (любые его рутины) включается после него.

[Tokra]

Вопрос в том, tc filter маркирут пакет до SNAT или после (я, просто, не собираюсь для маркировки пакетов использовать iptables)?

К сожалению, после SNAT (поскольку все рутины tc работают после всех преобразований, перед диспетчеризацией).
Если хотите типа критерий `ip src` и чтоб SNAT работал, то надо маркировать через iptables.

Если сначала tc filter маркирут пакет по правилу

Код: Выделить всё

tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip src 192.168.20.11 flowid 1:10

затем ставит его в нужную очередь. После этого ядро решает как маршрутизировать этот пакет. И только тогда iptables делает свое дело

Код: Выделить всё

iptables -t nat -A POSTROUTING -s 192.168.20.0/255.255.255.0 -o eth1 -j SNAT --to-source 195.1.1.1

Нет, дело обстоит так: пакетный фильтр делает свою работу и преобразования. tc (любые его рутины) включается после него.

Огромное спасибо