LINUX.ORG.RU
ФорумAdmin

tc qdisc


0

0

Подскажите плиз, сделал вот такие настройки

tc qdisc add dev eth1.400 root handle 1: htb default 999

# Class tc class add dev eth1.400 parent 1: classid 1:1 htb rate 100mbit ceil 100mbit burst 131000 tc class add dev eth1.400 parent 1:1 classid 1:2001 htb rate 512kbit ceil 600kbit burst 13100 prio 1

# tc qdisc add dev eth1.400 parent 1:2001 handle 2001: sfq perturb 10

#Filter tc filter add dev eth1.400 protocol ip parent 1:0 prio 1 handle 2001 fw flowid 1:2001

#MARK iptables -t mangle -A FORWARD -i eth0 -o eth1.400 -d 10.xx.xx.1 -j MARK --set-mark 2001

все вроде пашет, вопрос только возник, если мне надо шейпить не один ипишник на эту скорость (512кбит), а скаже 5-10-15... если я их буду маркировать тойже меткой (2001) то он будет КАЖДОМУ выдавать скорость по 512-600 кбит? или он этот один канал(512-600кбит)будет делить на то кол-во ИПов, которые я помечу одной и той же меткой?

Заранее спасибо


Полагаю, будет делить канал на всех. Ибо фильтр туп как швабра: трафик с одной меткой - сливаем в одну трубу.

Хотя я не спец по tc, поэтому сие мнение не есть абсолютная истина.

nnz ★★★★
()

посмотрите внимательнее доки по htb. Там можно обойтись без MARK вобще.

Valmont ★★★
()

>2001: sfq

Вот эта фигня будет поровну распределять канал между потоками. Хинт - на айпишники пофигу. Так что один ип с кучей соединений захавает бОльшую часть трафика.

redgremlin ★★★★★
()

В нашей сети админ для ограничения полосы делал следующее:
1) к рут классу htb цеплялись классы с разными приоритетами (у безлимитчиков повыше, у лимитчиков пониже, и админский с наивысшим приоритетом) всего было три подкласса (у вас их пока 2). Например 100 мегабит делится на 40мбит+60мбит+64k
2) фильтрами траффик во-первых классифицируется в какой класс он попадет, а во-вторых, в этих же фильтрах проводится полисинг

$tc filter add dev %s parent %s protocol ip prio 50 handle 800::$fh u32 match ip %s %s police rate %s burst %s drop flowid %s

Т.е. по сути ограничение полосы каждому клиенту делается фильтром, причем лишние пакеты дропаются. И это работало, и работало хорошо. К сожалению, этот функционал плохо документирован (как и весь traffic control, впрочем).
И про исходящий трафик тоже не забывайте, таким же макаром на ingress его филтровать.
Другой путь - по классу htb на каждого клиента, но исходящий от клиентов трафик все равно придется таким методом делать, либо исхитрятся через IFB

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

>К сожалению, этот функционал плохо документирован

LARTC 12.3 чем не устраивает? Скажем, ваша строчка - тот же первый пример из 12.3.3, только циферки другие.

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