LINUX.ORG.RU
Форум — Admin  

Ограничение скорости с помощью tc из iproute2


0

0

Помогите. Возникла проблема с настройкой tc.
Не могу загнать в определенную очередь пакеты идущие с одной из машин 172.16.130.10 (качальщик завелся), а тк трафик безплатный, то хочу его просто ограничить.
Пакеты помечаются в iptables, а в очередь 1:12 идти не хотят.
Вот кусок моего файла

ipt=/usr/local/sbin/iptables
ipr=/sbin/tc
# очистка таблицы mangle
$ipt -t mangle -F

$ipr qdisc del dev eth0 root &> /dev/null
$ipr qdisc del dev eth1 root &> /dev/null

# kbps = KByte/sek
# ограничение скорости канала -----------------------------------------------------------------

$ipr qdisc add dev eth0 root handle 1: htb default 13
$ipr class add dev eth0 parent 1: classid 1:1 htb rate 128kbit ceil 128kbit burst 200
# ssh, DNS,
$ipr class add dev eth0 parent 1:1 classid 1:10 htb rate 10kbit ceil 128kbit burst 200 prio 0
# HTTP
$ipr class add dev eth0 parent 1:1 classid 1:11 htb rate 128kbit ceil 128kbit burst 200 prio 1
# zaharov2
$ipr class add dev eth0 parent 1:1 classid 1:12 htb rate 1kbit ceil 1kbit burst 20 prio 3
# Other
$ipr class add dev eth0 parent 1:1 classid 1:13 htb rate 64kbit ceil 64kbit burst 200 prio 2

$ipr qdisc add dev eth0 parent 1:11 handle 110: sfq perturb 10
$ipr qdisc add dev eth0 parent 1:12 handle 120: sfq perturb 10
$ipr qdisc add dev eth0 parent 1:13 handle 130: sfq perturb 10

$ipr filter add dev eth0 protocol ip parent 1:0 prio 1 handle 1 fw flowid 1:10
$ipr filter add dev eth0 protocol ip parent 1:0 prio 2 handle 2 fw flowid 1:11
$ipr filter add dev eth0 protocol ip parent 1:0 prio 3 handle 0x3 fw flowid 1:12
$ipr filter add dev eth0 protocol ip parent 1:0 prio 4 handle 0x4 fw flowid 1:13


# zaharov 2

$ipt -t mangle -A PREROUTING -p tcp -m tcp -s 172.16.131.10 -j MARK --set-mark 0x3
$ipt -t mangle -A PREROUTING -p tcp -m tcp -d 172.16.131.10 -j MARK --set-mark 0x3
$ipt -t mangle -A PREROUTING -p tcp -m tcp -s 172.16.131.10 -j RETURN
$ipt -t mangle -A PREROUTING -p tcp -m tcp -d 172.16.131.10 -j RETURN

# icmp
$ipt -t mangle -A PREROUTING -p icmp -j MARK --set-mark 0x1
$ipt -t mangle -A PREROUTING -p icmp -j RETURN
$ipt -t mangle -A PREROUTING -m tos --tos Minimize-Delay -j MARK --set-mark 0x1
$ipt -t mangle -A PREROUTING -m tos --tos Minimize-Delay -j RETURN
$ipt -t mangle -A PREROUTING -m tos --tos Maximize-Throughput -j MARK --set-mark 0x4
$ipt -t mangle -A PREROUTING -m tos --tos Maximize-Throughput -j RETURN
# SSH
$ipt -t mangle -A PREROUTING -p tcp -m tcp --sport 22 -j MARK --set-mark 0x1
$ipt -t mangle -A PREROUTING -p tcp -m tcp --sport 22 -j RETURN
# SYN
$ipt -t mangle -A PREROUTING -p tcp -m tcp --tcp-flags SYN,RST,ACK, SYN -j MARK --set-mark 0x1
$ipt -t mangle -A PREROUTING -p tcp -m tcp --tcp-flags SYN,RST,ACK, SYN -j RETURN
# HTTP
$ipt -t mangle -A POSTROUTING -p tcp -m tcp --dport 80 -j MARK --set-mark 0x2
$ipt -t mangle -A POSTROUTING -p tcp -m tcp --dport 80 -j RETURN
$ipt -t mangle -A POSTROUTING -p tcp -m tcp --sport 80 -j MARK --set-mark 0x2
$ipt -t mangle -A POSTROUTING -p tcp -m tcp --sport 80 -j RETURN
# Other
$ipt -t mangle -A PREROUTING -j MARK --set-mark 0x4

anonymous

А как определили, что не хотят ? Что показывает "tc -s -d class show dev eth0" для класса 1:12 ? Да, в shaper на eth0 в вашем случае будет попадать только исходящий из eth0 трафик. eth0 - это локальный интерфейс (смотрит в локальную сеть) ?

Да, а случайно не с 80 tcp порта качает этот качальщик ? Тогда может несмотря на то, что пакеты идут от/на 172.16.131.10 последующие правила ("-A POSTROUTING -p tcp -m tcp --(s|d)port 80 -j MARK --set-mark 0x2") перемаркировуют их ?

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

Програмка
#!/bin/bash
/sbin/tc -s class show dev eth0 | tail -12
/sbin/iptables -L -n -v -t mangle | grep 172.16.131.10

показывает
class htb 1:13 parent 1:1 leaf 130: prio 2 rate 64Kbit ceil 64Kbit burst 199b cburst 1680b
Sent 53247 bytes 155 pkts (dropped 0, overlimits 0)
rate 696bps 1pps
lended: 146 borrowed: 9 giants: 0
tokens: -130400 ctokens: 17700

class htb 1:12 parent 1:1 leaf 120: prio 3 rate 1Kbit ceil 1Kbit burst 19b cburst 1600b
Sent 0 bytes 0 pkts (dropped 0, overlimits 0)
lended: 0 borrowed: 0 giants: 0
tokens: 128000 ctokens: 10246399

55 8124 MARK tcp -- * * 172.16.131.10 0.0.0.0/0 tcp MARK set 0x3
0 0 MARK tcp -- * * 0.0.0.0/0 172.16.131.10 tcp MARK set 0x3
55 8124 RETURN tcp -- * * 172.16.131.10 0.0.0.0/0 tcp
0 0 RETURN tcp -- * * 0.0.0.0/0 172.16.131.10 tcp

т е пакеты маркируются, а в очередь не попадают.
eth0 - это интерфейс, который смотрит в инет, в локальную сеть смотрит eth1, а пользователи заходят на сервер с помощью vpn. Остальные то очереди вроде как работают.
Насчет перемаркировки пакетов. Там везде есть политика return, которая , как я понял, не дает пакетам идти дальше.
А вообще тут есть что еще попробовать. Буду пробовать.

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

Поменял eth0 на eth1.
Попробовал качнуть через ftp (пока свою машину установил для экспериментов)
Попробовал переделать фильтры, чтобы не через iptables.

$ipr filter add dev eth1 parent 1:0 protocol ip prio 4 u32 \
match ip src 172.16.131.10/32 flowid 1:12

$ipr filter add dev eth1 parent 1:0 protocol ip prio 4 u32 \
match ip dst 172.16.131.10/32 flowid 1:12

все равно не работает.
Какие будут еще предложения.

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

Так как стоит vpn (pptp ?) то следует ограничивать на ppp+ интерфейсах, а не на ethX (или как дебильный вариант можно ограничивать на eth1 скорость gre пакетов).

Посмотри в сторону imq - это то что надо для ограничения по нескольким интерфейсам.

См. http://www.linux.org.ru/jump-message.jsp?msgid=1198896

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

> Там везде есть политика return, которая , как я понял, не дает пакетам идти дальше.
Да, это так, но только в пределах одной цепочки, т.е. RETURN завершает просмотр правил той цепочки, в которой он стоит, на прохождение остальных он никак не влияет. Получается, что пришел транзитный пакет, залез в mangle PREROUTING, промаркировался, RETURN закончил проверку правил PREROUTING, далее пакет пошел проверяться по другим цепочкам, в конце залез в POSTROUTING и так вдруг обнаружилось, что у пакета sport/dport 80, соответственно он перемаркировался. И в shaper попал не с той меткой, какая ожидалась.

> Попробовал переделать фильтры
А почему в них "prio 4" ? Сделайте лучше у них "prio 1", а остальные подвиньте. Пусть эти фильтры вызываются первыми !

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

Если я посажу все фильтры на внутреннюю сеть (eth1), то , как я понял я ограничу по скорости все локальные сервисы, которые висят на этом серваке, что делать не хотелось бы. Надо попробовать настроить на ppp*, но не знаю как.

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

> Если я посажу все фильтры на внутреннюю сеть (eth1), то , как я понял я ограничу по скорости все локальные сервисы, которые висят на этом серваке, что делать не хотелось бы. Надо попробовать настроить на ppp*, но не знаю как.

Выше ж написано - IMQ

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

А Вы не знаете, где можно найти доку по IMQ?

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

>Если я посажу все фильтры на внутреннюю сеть (eth1), то , как я понял я ограничу по скорости все локальные сервисы, которые висят на этом серваке, что делать не хотелось бы. Надо попробовать настроить на ppp*, но не знаю как.

Что мешает сделать default 10, и дать ему самый высокий приоритет.

Что-то типа htb rate 100mbit ceil 100Mmit prio 0...А потом все остальное. И все это на карточке которая смотрит в локалку. У меня так работает.

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

>Что-то типа htb rate 100mbit ceil 100Mmit prio 0...А потом все остальное. >И все это на карточке которая смотрит в локалку. У меня так работает.

Но тогда, если захочешь что-то выкачать по фтр с сервера по локалке, макс скорость будет, та которую назначил на сервере. Да и HTTP сервер админить по локали будет не удобно. Или как то можно это обойти.

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

И еще. Надо учесть все варианты работы через инет (протокол, порт), чтобы они попали в класс до default. Если можно, кинь твой вариант файла настроек.

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

> то , как я понял я ограничу по скорости все локальные сервисы
Это из чего следует ??? Включение shaper-а на внутреннем интерфейсе само по себе никаким образом ничего ограничивать не начнет. Все будет зависеть от дальнейшей настройки: что мешает вешать htb без указания default класса ? Почему нельзя написать фильтры (или маркировку через iptables), которые будут касаться только внешнего трафика и никак не затронут локальный ???

В случае с IMQ будет то же самое: в IMQ нужно будет направлять только тот трафик, который следует ограничивать. Если направить локальный, то будет ограничиваться и локальный, но только зачем это делать ? :-)

> А Вы не знаете, где можно найти доку по IMQ?
А на linuximq.net кто-нибудь заходил ? Разделы FAQ и Usage там никто не смотрел ????
"iptables -j IMQ --help|tail" никто не пробовал запускать ?
"Kernel Packet Traveling Diagram" на docum.org никто не изучал ? (http://www.docum.org/docum.org/kptd/ , hint: ее лучше скопировать в txt-файл, и потом смотреть - картинка прямее становится).
В конце концов, есть русская документация: http://www.opennet.ru/docs/RUS/LARTC/index.html , раздел "9.7. Intermediate queueing device".
P.S. Не говоря уже о google.ru и т.п. ...

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

>И еще. Надо учесть все варианты работы через инет (протокол, порт), чтобы они попали в класс до default. Если можно, кинь твой вариант файла настроек.

Ну так ы чем проблема... Все подефаулту падает в дефаулт...А то что нада ограничивать маркируешь, и забиваешь в соотвествующие класы..

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