приоритеты трафика

Можно сделать так

Создал 2 или 3 канала с нарастающим приоритетом. 1-й канал (высокий приоритет). 2-й канал(средний) -- веб-серфинг. 3-й канал -- закачки всякий (низкий приоритет). Первые 2 канала имеют дисциплину sfq. 3-й канал - htb - еще делится на столько каналов, сколько имеется клиентов.

На первые два канала попадают пакеты с меткой, например, 1 и 2. До 3-го канала нужно прикрутить еще один фильтр по ІР. Да, и еще 3-й канал должен быть default.

В iptables метим нужные пакеты. Пакеты без меток (торренты там всякие) пойдут по 3-му каналу и трафик чесно будет делится. Чтобы отличить трафик веб-серфинга от закачек через 80-й порт, можно воспользоваться критерием в iptables: -m limit, или -m hashlimit, или -m tbr (в останнем не уверен).

Подобная схема довольно неплохо работает у меня.

ну собственно я вроде так и сделал все кроме 80-го и 22го порта идет с меньшим приоритетом, или ты имеешь ввиду что на 3й канал в htb еще какие-то ограничения ввести?

сейчас добавил еще

iptables -A POSTROUTING -t mangle -o eth0 -j MARK --set-mark 2

тоесть все что не идет на 22 и 80 порты уж точно должно идти по 1:30 тоесть с минимальным приоритетоми, и всеравно ютуб тормозит, качаю по хттп 5 кб, торрентн качает на всю скорость канала, причем сейчас посмотрел tc -s qdisc ls dev eth0

пакеты через 1:10 вообще неотсылаются почти, все идет через 1:20 и 1:30 непойму где мог допустить ошибку, вроде все правильно

нужно, по-моему, менять правила в PREROUTING А в 3-й ветке тоже можно задать ограничение как на всю ветку, так и на каждого клиента.

Да, и полезными будут правила:

### config for hashlimit ###

HL_BURST=1000

HL_TABLE_SIZE=100

HL_LIMIT=60/sec

HL_TABLE_MAX=2000

HL_GC_INTERVAL=2000

HL_EXPIRE=10000

HL_NAME=websurf

############################

iptables -t mangle -A PREROUTING -p tcp \

-m multiport --ports 80,21 \

-m hashlimit --hashlimit $HL_LIMIT \

--hashlimit-mode 'dstip,srcport,dstport' \

--hashlimit-burst $HL_BURST \

--hashlimit-name $HL_NAME \

--hashlimit-htable-size $HL_TABLE_SIZE \

--hashlimit-htable-expire $HL_EXPIRE \

--hashlimit-htable-gcinterval $HL_GC_INTERVAL \

-j MARK --set-mark 0x2

Проблема в том, что PRIO не ограничивает канал а лишь управляет приоритетами.
eth0 способна отдавать пакеты с большей скоростью чем твой лимит по скорости на интернет.
Из-за этого у провайдера образуется большая очередь пакетов, а у тебя очередь практически не наблюдается.

Чтобы всё заработало, тебе нужно сделать так, чтобы очередь образовывалась у тебя а не у прова. Для этого тебе придётся прикрутить на самый верх qdisc который будет пропускать трафик со скоростью аплоада минус пару процентов.

Кроме того ты сделал ограничения только в одну сторону.

Как всё это сделать можно прочитать в знаменитом хауту http://lartc.org/
Где-то в интернетах есть перевод на русский если нужен.

>Чтобы всё заработало, тебе нужно сделать так, чтобы очередь образовывалась у тебя а не у прова. Для этого тебе придётся прикрутить на самый верх qdisc который будет пропускать трафик со скоростью аплоада минус пару процентов.

ясно, спасибо, как-то этот момент я упустил, просто изначально подумал, тк провайдер периодически скорость добавляет, то хотелось сделать наиболее универсальное решение, которое будет работать без моих поправок

>Кроме того ты сделал ограничения только в одну сторону.

этот момент неясен, у меня ведь и при sport и при dport = 80 все перенаправляется в полосу 1:10 тоесть с максимальным приоритетом

и еще сейчас подумалось, но никак найти немогу, вот у меня маркируются все пакеты проходящие через mangle PREROUTING и POSTROUTING, небудет ли так, что маркированый пакет, идущий на 80й порт пойдет по правилу
tc filter add dev eth0 protocol ip parent 1:0 prio 2 \
handle 2 fw flowid 1:30

а не
tc filter add dev eth0 protocol ip parent 1: prio 1 \
u32 match ip dport 80 0xffff flowid 1:10

>Как всё это сделать можно прочитать в знаменитом хауту http://lartc.org/
Где-то в интернетах есть перевод на русский если нужен.

я переводом этого и руководствовался, он на опеннете есть, просто как-то это все запутанно, от недостатка опыта видимо

>>Кроме того ты сделал ограничения только в одну сторону.
>этот момент неясен, у меня ведь и при sport и при dport = 80 все
>перенаправляется в полосу 1:10 тоесть с максимальным приоритетом

вот этой командой:
tc qdisc add dev eth0 root handle 1: prio
ты добавляешь qdisc на _исходящий_(egress) с интерфейса eth0 трафик.
Для регулирования входящего трафика нужно использовать ingress qdisc, но его возможности весьма ограничены, так что я думаю тебе нужно будет воспользоваться устройством IMQ (сам не пробовал). про IMQ описано в этом же хауту.

>iptables -A PREROUTING -t mangle -i eth0 -j MARK --set-mark 2

mangle PREROUTING это входящий трафик на интерфейс eth0, а qdisc повешен на исходящий.

>tc filter add dev eth0 protocol ip parent 1: prio 1 \
>u32 match ip sport 22 0xffff flowid 1:10

Не понятно кто такой 1:10. У PRIO только три класса (по умолчанию), наверное имелось ввиду что-то другое.

>ты добавляешь qdisc на _исходящий_(egress) с интерфейса eth0 трафик. Для регулирования входящего трафика нужно использовать ingress qdisc, но его возможности весьма ограничены, так что я думаю тебе нужно будет воспользоваться устройством IMQ (сам не пробовал). про IMQ описано в этом же хауту.

этот момент упустил, буду читать

>mangle PREROUTING это входящий трафик на интерфейс eth0, а qdisc повешен на исходящий.

я и на POSTROUTING точно такое же правило вешаю

>Не понятно кто такой 1:10. У PRIO только три класса (по умолчанию), наверное имелось ввиду что-то другое.

это дочерний класс 1:1, я просто практически полностью скопипастил эту часть из хауту

в общем спасибо, теперь ясно где ошибки и в какую сторону думать дальше