LINUX.ORG.RU
ФорумAdmin

tc, проблема с фильтрами... или классами?


0

0

Здравствуйте уважаемые. Ни как не получается разобраться самому, помогите если сможете. Проблема заключается в следующем: Есть интерфейс ppp0 например. Применяю следующие правила

PPP_ID=ppp1
tc qdisc add dev $PPP_ID root handle 1: htb  r2q 70
tc class add dev $PPP_ID parent 1: classid 1:1 htb rate 100mbit burst 20k

tc class add dev $PPP_ID parent 1:1 classid 1:3218 htb rate 580kbit burst 20k prio 1 quantum 4096
tc class add dev $PPP_ID parent 1:1 classid 1:30 htb rate 50mbit ceil 80mbit burst 20k prio 4

tc qdisc add dev $PPP_ID parent 1:30 handle 30 sfq perturb 10
tc qdisc add dev $PPP_ID parent 1:3333 handle 3218 sfq perturb 10

tc filter add dev $PPP_ID parent 1:0 protocol ip prio 10 u32 match ip src 85.91.192.0/20 flowid 1:30
tc filter add dev $PPP_ID parent 1:0 protocol ip prio 10 u32 match ip src 217.25.80.0/22 flowid 1:30
tc filter add dev $PPP_ID parent 1:0 protocol ip prio 10 u32 match ip src 85.143.0.0/20 flowid 1:30
tc filter add dev $PPP_ID parent 1:0 protocol ip prio 10 u32 match ip src 92.246.128.0/19 flowid 1:30
tc filter add dev $PPP_ID parent 1:0 protocol ip prio 10 u32 match ip src 212.67.0.0/19 flowid 1:30
tc filter add dev $PPP_ID parent 1:0 protocol ip prio 10 u32 match ip src 217.23.16.0/20 flowid 1:30
tc filter add dev $PPP_ID parent 1:0 protocol ip prio 10 u32 match ip src 95.37.0.0/17 flowid 1:30
tc filter add dev $PPP_ID parent 1:0 protocol ip prio 10 u32 match ip src 93.120.128.0/17 flowid 1:30
tc filter add dev $PPP_ID parent 1:0 protocol ip prio 10 u32 match ip src 79.126.0.0/17 flowid 1:30
tc filter add dev $PPP_ID parent 1:0 protocol ip prio 10 u32 match ip src 213.177.96.0/19 flowid 1:30
tc filter add dev $PPP_ID parent 1:0 protocol ip prio 10 u32 match ip src 89.109.0.0/18 flowid 1:30
tc filter add dev $PPP_ID parent 1:0 protocol ip prio 10 u32 match ip src 82.208.64.0/18 flowid 1:30
tc filter add dev $PPP_ID parent 1:0 protocol ip prio 10 u32 match ip src 217.118.93.0/24 flowid 1:30
tc filter add dev $PPP_ID parent 1:0 protocol ip prio 10 u32 match ip src 92.242.64.0/19 flowid 1:30
tc filter add dev $PPP_ID parent 1:0 protocol ip prio 10 u32 match ip src 89.189.0.0/19 flowid 1:30
tc filter add dev $PPP_ID parent 1:0 protocol ip prio 10 u32 match ip src 195.98.32.0/19 flowid 1:30
tc filter add dev $PPP_ID parent 1:0 protocol ip prio 10 u32 match ip src 212.92.128.0/18 flowid 1:30
tc filter add dev $PPP_ID parent 1:0 protocol ip prio 10 u32 match ip src 62.220.32.0/20 flowid 1:30
tc filter add dev $PPP_ID parent 1:0 protocol ip prio 10 u32 match ip src 194.190.176.0/20 flowid 1:30
tc filter add dev $PPP_ID parent 1:0 protocol ip prio 10 u32 match ip src 195.122.224.0/19 flowid 1:30
tc filter add dev $PPP_ID parent 1:0 protocol ip prio 10 u32 match ip src 91.194.192.0/23 flowid 1:30
tc filter add dev $PPP_ID parent 1:0 protocol ip prio 10 u32 match ip src 217.18.52.0/23 flowid 1:30
tc filter add dev $PPP_ID parent 1:0 protocol ip prio 10 u32 match ip src 81.19.130.0/24 flowid 1:30
tc filter add dev $PPP_ID parent 1:0 protocol ip prio 10 u32 match ip src 81.19.128.0/23 flowid 1:30
tc filter add dev $PPP_ID parent 1:0 protocol ip prio 10 u32 match ip src 193.125.70.0/23 flowid 1:30
tc filter add dev $PPP_ID parent 1:0 protocol ip prio 10 u32 match ip src 213.190.224.0/19 flowid 1:30
tc filter add dev $PPP_ID parent 1:0 protocol ip prio 10 u32 match ip src 78.40.184.0/21 flowid 1:30
tc filter add dev $PPP_ID parent 1:0 protocol ip prio 10 u32 match ip src 89.28.199.0/24 flowid 1:30
tc filter add dev $PPP_ID parent 1:0 protocol ip prio 10 u32 match ip src 94.25.78.0/24 flowid 1:30

tc filter add dev $PPP_ID parent 1:0 protocol ip prio 50 u32 match ip src 0.0.0.0/0 flowid 1:3218

тут же приведу результаты с интерфейса

# tc q s dev ppp0
qdisc htb 1: root r2q 70 default 0 direct_packets_stat 0
qdisc sfq 30: parent 1:30 limit 127p quantum 1488b perturb 10sec
qdisc sfq 3218: parent 1:3218 limit 127p quantum 1488b perturb 10sec

# tc c s dev ppp0
class htb 1:1 root rate 100000Kbit ceil 100000Kbit burst 20462b cburst 1600b
class htb 1:30 parent 1:1 leaf 30: prio 4 rate 50000Kbit ceil 80000Kbit burst 20Kb cburst 1590b
class htb 1:3218 parent 1:1 leaf 3218: prio 3 rate 580000bit ceil 580000bit burst 20Kb cburst 1599b

# tc f s dev ppp0
filter parent 1: protocol ip pref 10 u32
filter parent 1: protocol ip pref 10 u32 fh 800: ht divisor 1
filter parent 1: protocol ip pref 10 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:30
  match 555bc000/fffff000 at 12
filter parent 1: protocol ip pref 10 u32 fh 800::801 order 2049 key ht 800 bkt 0 flowid 1:30
  match d9195000/fffffc00 at 12
.....................вырезано для экономии места...................
filter parent 1: protocol ip pref 10 u32 fh 800::81c order 2076 key ht 800 bkt 0 flowid 1:30
  match 5e194e00/ffffff00 at 12
filter parent 1: protocol ip pref 50 u32
filter parent 1: protocol ip pref 50 u32 fh 801: ht divisor 1
filter parent 1: protocol ip pref 50 u32 fh 801::800 order 2048 key ht 801 bkt 0 flowid 1:3218
  match b0100409/ffffffff at 16

Задача следующая: весь трафик общий трафик из внешки в этот интерфейс должен идти со скоростью 580kbit (класс 1:3218) а трафик из определенных подсетей которые указаны в фильтрах (класс 1:30) должен иметь скорость 50-80 мегабит, но это уже не суть проблема заключается вот в чем, трафик из внешки режется прекрасно и получается 580kbit и с пиринговых подсетей трафик идет с большой скоростью по 20mbit например. Прикол заключается в том, что если качать одновременно с пиринговых подсетей, тогда скорость на внешку которой отведено 580kbit снижается сильно. Долго мучал всё это дело, вот что выявил. Когда человек качает что либо из внешки весь трафик попадает в класс 1:3218 стабильно, ни одного пакетика в 1:30 и всё режется прекрасно до нужной скорости Но когда человек качает из пиринговых сетей, трафик попадает в оба класса и в 1:30 и в 1:3218. В связи с этим если человек качает что то из пиринговых сетей общий канал (1:3218) забивается трафиком этим тоже, и скорость общая на внешку падает. при этом замечено следующее, если я делаю приоретет у фильтра 1:3218 например не 50 а 5, таким образом:

tc filter add dev $PPP_ID parent 1:0 protocol ip prio 5 u32 match ip src 0.0.0.0/0 flowid 1:3218
чтоб он был приорететнее, чем 1:30, тогда абсолютно все пакеты и с пиринговых подсетей и с внешки попадают в общий класс (1:3218) в класс 1:30 не попадает ни одного, и скорость режется на всё до 580кбит Но если сделать приоретет у фильтра общего (1:3128) меньше, чем у фильтра пиринговых сетей (то есть число больше 10) то пакеты идущие из пиринговых подсетей всё равно попадают в общий класс (1:3218) ((( уже голову сломал, подскажите в чем ошибка?

Как вы определили, что трафик попадает в оба класса? Может у вас просто забивается канал, может попробовать поставить rate 2 Мбит без ceil для 1:30 и посмотреть?

mky ★★★★★
()

Честно говоря, нифига не понял.

Но что-то мне подсказывает, что тебе достаточно при помощи критерия ipp2p вылавливать пиринговые сети и через маркировку отправлять их в нужный класс.

iptables -t mangle -N mark_p2p
iptables -t mangle -A mark_p2p -m ipp2p --bit --dc -j CONNMARK --set-mark 5
iptables -t mangle -A mark_p2p -j CONNMARK --restore-mark
iptables -t mangle -I PREROUTING -j mark_p2p
iptables -t mangle -I POSTROUTING -j mark_p2p

tc filter add бла-бла-бла handle 5 fw бла-бла-бла

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

прошу прощения, если как то не очень понятно излагаюсь. я смотрю так:

# tc -s c s dev ppp0
class htb 1:1 root rate 100000Kbit ceil 100000Kbit burst 20462b cburst 1600b
 Sent 2116775369 bytes 2302297 pkt (dropped 0, overlimits 0 requeues 0)
 rate 310936bit 39pps backlog 0b 0p requeues 0
 lended: 135 borrowed: 0 giants: 0
 tokens: 1592 ctokens: 118

class htb 1:30 parent 1:1 leaf 30: prio 4 rate 50000Kbit ceil 80000Kbit burst 20Kb cburst 1590b
 Sent 1858866393 bytes 1949367 pkt (dropped 0, overlimits 0 requeues 0)
 rate 182696bit 23pps backlog 0b 0p requeues 0
 lended: 1949232 borrowed: 135 giants: 0
 tokens: 3183 ctokens: 146

class htb 1:3252 parent 1:1 leaf 3252: prio 1 rate 128000bit ceil 128000bit burst 20Kb cburst 1599b
 Sent 257898295 bytes 352938 pkt (dropped 332, overlimits 0 requeues 0)
 rate 130448bit 16pps backlog 0b 8p requeues 0
 lended: 352930 borrowed: 0 giants: 0
 tokens: 976581 ctokens: -175763 

при этом если человек качает из внешки растут счетчики Sent и rate (скорость) только в классе 1:3252. вот эти:

class htb 1:3252 parent 1:1 leaf 3252: prio 1 rate 128000bit ceil 128000bit burst 20Kb cburst 1599b
 Sent 257898295 bytes 352938 pkt (dropped 332, overlimits 0 requeues 0)
 rate 130448bit 16pps backlog 0b 8p requeues 0 
а в классе 1:30 всё тихо. но стоит ему качать из сетей которые фильтруются в 1:30 начинают расти счетчики и в 1:30 и в 1:3252 получается что трафик попадает в оба класса и забивается канал 1:3252 Собственно всё логично вроде, потому что если посмотреть на фильтр
tc filter add dev $PPP_ID parent 1:0 protocol ip prio 50 u32 match ip src 0.0.0.0/0 flowid 1:3252
в него должно попадать абсолютно всё. но ему отдан более низкий приоретет чем 1:30 и по идее те пакеты, что попадают в 1:30, уже не должны попадать в 1:3252, но они всё равно попадают и забивают его, вот я и ломаю голову...

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

Есть подозрение, что когда кто-то качает по p2p, трафик идет как из подсетей 1:30, так и с прочих подсетей. Ибо пиринговые сети — они большие.

Так что опять не понял, в чем проблема.

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

Проблема не совсем понятна. Опишите подробней, конфигурацию сетей и кто куда ходит.

Попробуйте задать параметр default для htb qdisc вместо кривого хака с u32 match ip src 0.0.0.0/0 flowid 1:3252

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

вобщем суть такая. существует так называемое "нижегородское кольцо". суть его в том что многие провайдеры объеденнены в одну сеть и трафик между ними бесплатный и скорость 100-1000 мегабит. но это уже не суть))) так вот этот список подсетей который относятся к классу 1:30 входят в "нижегородское кольцо", это внешние подсети провайдеров. вот до них нужно сделать скорость большую, а на всё остальное (то есть внешку) скорость зарезана должна быть ну например 512 килобит, это уже не суть. вот и загвоздка какая то у меня тут. когда человек качает с кольца что угодно, на внешку скорость у него становится медленее. и всё потому что трафик с кольца попадает в оба класса и на кольцо и на внешку. и канал для внешки в данном случае 1:3218 забивается трафиком с кольца...

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

Я тебе могу предоставить готовые конфиги для FreeBSD для Нижегородского кольца, с port_based QoS приоритезацией трафика, там даж скорость резать не надо. Тока у меня на НН кольцо идет Стрим, а на внешку - Р-Телеком.

dev-ice
()
Ответ на: комментарий от truebadur

tc q a dev $PPP_ID root handle 1: htb default 3218

и убрать вот это:

tc filter add dev $PPP_ID parent 1:0 protocol ip prio 50 u32 match ip src 0.0.0.0/0 flowid 1:3218

Попробуйте и расскажите, что произошло.

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

dev-ice я смотрел конфиги под фряху тоже уже готовые, но чет не помогло )) если можешь запостить или выслать на litec@mail.ru, буду благодарен, посмотрю что к чему еще раз. azure по моему я уже так пробовал делать, класс на внешку делал дефолтным, и всё равно с кольца трафик сыпался в этот класс. Попробую еще раз, после этого отпишу обязательно.

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