шейпер tc

[Zolks 24]

Пробую разобраться с хеш таблицами

Подскажите, что я делаю не так?

 

#!/bin/bash

tc qdisc del dev bond0.8 root

tc qdisc add dev bond0.8 root handle 1: htb default 900

tc class add dev bond0.8 parent 1: classid 1:1 htb rate 4000Mbit burst 150k

tc class add dev bond0.8 parent 1:1 classid 1:100 htb rate 3800Mbit burst 150k

tc class add dev bond0.8 parent 1:100 classid 1:104 htb rate 20Mbit ceil 20Mbit
tc class add dev bond0.8 parent 1:100 classid 1:105 htb rate 20Mbit ceil 20Mbit

tc filter add dev bond0.8 parent 1:0 protocol ip u32

tc filter add dev bond0.8 parent 1:0 handle 12: protocol ip u32 divisor 8
tc filter add dev bond0.8 parent 1:0 handle 13: protocol ip u32 divisor 256

tc filter add dev bond0.8 parent 1:0 protocol ip u32 ht 800:: match ip dst 172.24.128.0/17 hashkey mask 0x0000ff00 at 16 link 12:

tc filter add dev bond0.8 parent 1:0 protocol ip u32 ht 12:3: match ip dst 172.24.129.0/24 hashkey mask 0xff at 16 link 14:
tc filter add dev bond0.8 parent 1:0 protocol ip u32 ht 12:4: match ip dst 172.24.130.0/24 hashkey mask 0xff at 16 link 15:
tc filter add dev bond0.8 parent 1:0 protocol ip u32 ht 12:5: match ip dst 172.24.131.0/24 hashkey mask 0xff at 16 link 16:
tc filter add dev bond0.8 parent 1:0 protocol ip u32 ht 12:1: match ip dst 172.24.132.0/24 hashkey mask 0xff at 16 link 17:
tc filter add dev bond0.8 parent 1:0 protocol ip u32 ht 12:2: match ip dst 172.24.128.0/24 hashkey mask 0xff at 16 link 13:

tc filter add dev bond0.8 protocol ip parent 1:0 u32 ht 13:1: match ip dst 172.24.128.46 flowid 1:104
tc filter add dev bond0.8 protocol ip prio 1 u32 ht 13:3: match ip dst 172.24.128.57 flowid 1:105

 

 

собственно при ip = 172.24.128.46 шейпер не работает
 

[KaYot 3 711]

А он и не должен работать, неверно фильтры составлены.

 

tc filter add dev bond0.8 parent 1:0 protocol ip u32 ht 800:: match ip dst 172.24.128.0/17 hashkey mask 0x0000ff00 at 16 link 12:

tc filter add dev bond0.8 parent 1:0 protocol ip u32 ht 12:0: match ip dst 172.24.128.0/24 hashkey mask 0xff at 16 link 13:

 

tc filter add dev bond0.8 protocol ip parent 1:0 u32 ht 13:2e: match ip dst 172.24.128.46 flowid 1:104

 

Смысл хеширования в быстром поиске, все эти циферки в ht значимы. Во втором уровне (12:0) 0 означает смещение от базового хешированного значения второго октета, 128-128=0.

В третьем уровне хешируется последний октет, значит там цифирка 13:2e - этот самый октет, 0x2e=46.

[KaYot 3 711]

Даже не совсем так. Вы везде используете ff в хешах, значит используется весь октет, то я по привычке для нормальных схем прикинул.

Значит и во втором уровне должен быть весь октет адреса, 12:80: (0x80=128).

Правильнее было бы в верхнем уровне поставить маску 7f, ведь для вашей подсети /17 старший бит не нужен и он не меняется. Тогда дальше можно считать смещение от 0, а не от 128.

Відредаговано 2014-09-30 08:03:54 KaYot

[Zolks 24]

вот почему нигде в примерах нет такого простого и доступного описания? )

спасибо, теперь все понятно.

 

и в догонку еще вопрос тогда:

я правильно понимаю, что для каждого ip мне нужен свой фильтр и свой класс?

[KaYot 3 711]

я правильно понимаю, что для каждого ip мне нужен свой фильтр и свой класс?

Конечно. Все что не попало в фильтры сваливается в дефолтный класс 900(у вас), его тоже не мешает описать.

[Zolks 24]

а можно ли загонять в tc не весь траффик, а только маркированный в iptables?

 

как-то нехорошо работает..

у тестового клиента от 7 до 10% потерь. + падает скорость у тестового клиента с ip 172.24.0.46 (т.е. не попадающего в правила)

1275 класов и фильтров

 

#!/bin/bash

tc qdisc del dev bond0.8 root
tc qdisc add dev bond0.8 root handle 1: htb default 900
tc class add dev bond0.8 parent 1: classid 1:1 htb rate 4000Mbit burst 150k
tc class add dev bond0.8 parent 1:1 classid 1:100 htb rate 3800Mbit burst 150k

tc filter add dev bond0.8 parent 1:0 protocol ip u32 ht 800:: match ip dst 172.24.128.0/17 hashkey mask 0x0000ff00 at 16 link 12:


tc filter add dev bond0.8 parent 1:0 protocol ip u32

tc filter add dev bond0.8 parent 1:0 handle 12: protocol ip u32 divisor 8
tc filter add dev bond0.8 parent 1:0 handle 13: protocol ip u32 divisor 256
tc filter add dev bond0.8 parent 1:0 handle 14: protocol ip u32 divisor 256
tc filter add dev bond0.8 parent 1:0 handle 15: protocol ip u32 divisor 256
tc filter add dev bond0.8 parent 1:0 handle 16: protocol ip u32 divisor 256
tc filter add dev bond0.8 parent 1:0 handle 17: protocol ip u32 divisor 256

tc filter add dev bond0.8 parent 1:0 protocol ip u32 ht 12:0: match ip dst 172.24.128.0/24 hashkey mask 0x000000ff at 16 link 13:
tc filter add dev bond0.8 parent 1:0 protocol ip u32 ht 12:1: match ip dst 172.24.129.0/24 hashkey mask 0x000000ff at 16 link 14:
tc filter add dev bond0.8 parent 1:0 protocol ip u32 ht 12:2: match ip dst 172.24.130.0/24 hashkey mask 0x000000ff at 16 link 15:
tc filter add dev bond0.8 parent 1:0 protocol ip u32 ht 12:3: match ip dst 172.24.131.0/24 hashkey mask 0x000000ff at 16 link 16:
tc filter add dev bond0.8 parent 1:0 protocol ip u32 ht 12:4: match ip dst 172.24.132.0/24 hashkey mask 0x000000ff at 16 link 17:


tc class add dev bond0.8 parent 1:100 classid 1:1001 htb rate 20Mbit ceil 20Mbit
tc filter add dev bond0.8 protocol ip parent 1:0 u32 ht 13:0: match ip dst 172.24.128.1 flowid 1:1001
tc class add dev bond0.8 parent 1:100 classid 1:1255 htb rate 20Mbit ceil 20Mbit
tc filter add dev bond0.8 protocol ip parent 1:0 u32 ht 13:fe: match ip dst 172.24.128.255 flowid 1:1255

tc class add dev bond0.8 parent 1:100 classid 1:1256 htb rate 20Mbit ceil 20Mbit
tc filter add dev bond0.8 protocol ip parent 1:0 u32 ht 14:0: match ip dst 172.24.129.1 flowid 1:1256
tc class add dev bond0.8 parent 1:100 classid 1:1510 htb rate 20Mbit ceil 20Mbit
tc filter add dev bond0.8 protocol ip parent 1:0 u32 ht 14:fe: match ip dst 172.24.129.255 flowid 1:1510

tc class add dev bond0.8 parent 1:100 classid 1:1511 htb rate 20Mbit ceil 20Mbit
tc filter add dev bond0.8 protocol ip parent 1:0 u32 ht 15:0: match ip dst 172.24.130.1 flowid 1:1511
tc class add dev bond0.8 parent 1:100 classid 1:1765 htb rate 20Mbit ceil 20Mbit
tc filter add dev bond0.8 protocol ip parent 1:0 u32 ht 15:fe: match ip dst 172.24.130.255 flowid 1:1765

tc class add dev bond0.8 parent 1:100 classid 1:1766 htb rate 20Mbit ceil 20Mbit
tc filter add dev bond0.8 protocol ip parent 1:0 u32 ht 16:0: match ip dst 172.24.131.1 flowid 1:1766
tc class add dev bond0.8 parent 1:100 classid 1:2020 htb rate 20Mbit ceil 20Mbit
tc filter add dev bond0.8 protocol ip parent 1:0 u32 ht 16:fe: match ip dst 172.24.131.255 flowid 1:2020

tc class add dev bond0.8 parent 1:100 classid 1:2021 htb rate 20Mbit ceil 20Mbit
tc filter add dev bond0.8 protocol ip parent 1:0 u32 ht 17:0: match ip dst 172.24.132.1 flowid 1:2021
tc class add dev bond0.8 parent 1:100 classid 1:2275 htb rate 20Mbit ceil 20Mbit
tc filter add dev bond0.8 protocol ip parent 1:0 u32 ht 17:fe: match ip dst 172.24.132.255 flowid 1:2275

Відредаговано 2014-09-30 09:28:33 Zolks

[KaYot 3 711]

Можно

You can mark packets with either ipchains or iptables and have that mark survive routing across interfaces. This is really useful to for example only shape traffic on eth1 that came in on eth0. Syntax:[/size]

# tc filter add dev eth1 protocol ip parent 1:0 prio 1 handle 6 fw flowid 1:1

Note that this is not a u32 match![/size]

 

You can place a mark like this:

# iptables -A PREROUTING -t mangle -i eth0 -j MARK --set-mark 6

Відредаговано 2014-09-30 09:20:21 KaYot

[Abram 98]

Zolks,

Гуглите по "tc fwmark".

Красить надо в -t mangle.

Кстати, удобно так местами делать.

 

А, уже ответили - "handle X fw ...".

Відредаговано 2014-09-30 09:20:28 Abram

[KaYot 3 711]

Если вы используете

tc filter add dev bond0.8 parent 1:0 protocol ip u32 ht 800:: match ip dst 172.24.128.0/17 hashkey mask 0x0000ff00 at 16 link 12:

То по идее дальнейший фильтр нужно делать не так
tc filter add dev bond0.8 parent 1:0 protocol ip u32 ht 12:0: match ip dst 172.24.128.0/24 hashkey mask 0x000000ff at 16 link 13:
А так
tc filter add dev bond0.8 parent 1:0 protocol ip u32 ht 12:80: match ip dst 172.24.128.0/24 hashkey mask 0x000000ff at 16 link 13:

 

И в клиентском фильтре ошибки:

tc filter add dev bond0.8 protocol ip parent 1:0 u32 ht 13:0: match ip dst 172.24.128.1 flowid 1:1001

Нужно таки что б хеш совпадал с ip, tc filter add dev bond0.8 protocol ip parent 1:0 u32 ht 13:1: match ip dst 172.24.128.1 flowid 1:1001

 

А потери понятно почему, никаких чудес. По умолчанию tc не создает ничего, соответственно у конечного класса нет qdisk'a(очереди). Длинна буфера шейпера 0 байт.

Добавьте его, мне нравится конечная дисциплина sfq

qdisc add dev bond1 parent 1:1001 handle 1001 sfq  perturb 10

[KaYot 3 711]

+ падает скорость у тестового клиента с ip 172.24.0.46 (т.е. не попадающего в правила)

А с этим я когда-то почти неделю мучался, пока дошло

Та же ситуация, как я писал выше - все что не попадает в правила шейпера сливается в дефолтный класс. А у него очереди тоже нет. И пока нагрузка на железо небольшая, и пакеты успевают пролетать условно wire-speed - проблем нет. Но как только идет рост pps и пакеты не успевают покинуть трубу мгновенно - они уничтожаются tc вместо буферизирования.

 

Создайте явно дефлтный класс 1:900, добавьте ему какое-то большое ограничение скорости и очередь. Можно попроще, у меня стоит pfifo limit 10000(пакетов).

[Zolks 24]

А потери понятно почему, никаких чудес. По умолчанию tc не создает ничего, соответственно у конечного класса нет qdisk'a(очереди). Длинна буфера шейпера 0 байт.

Добавьте его, мне нравится конечная дисциплина sfq

qdisc add dev bond1 parent 1:1001 handle 1001 sfq  perturb 10

 

  очередь добавлять необходимо для каждого конечного класса?

  добавил - ничего не изменилось (

 

  может еще что-то пропустил?

  и буду благодарен за рабочий пример

[KaYot 3 711]

Да, очередь имеет смысл только для конечного класса. Добавлять ее нужно везде.

Для отладки смотри статистику tc, вроде tc -s class или tc -s qdisc, и смотри по счетчикам куда идет трафик и где дропается.

[Zolks 24]

посмотрел статистику. оказывается в конечные классы вобще ничего не попадает.

а просадка скорости была вызвана отсутствием очереди, а не шейпер ее резал.

tc qdisc del dev bond0.8 root
tc qdisc add dev bond0.8 root handle 1: htb default 900
tc class add dev bond0.8 parent 1: classid 1:1 htb rate 4000Mbit burst 150k
tc class add dev bond0.8 parent 1:1 classid 1:100 htb rate 3800Mbit burst 150k
tc class add dev bond0.8 parent 1: classid 1:900 htb rate 3800Mbit burst 150k
tc qdisc add dev bond0.8 parent 1:900 handle 900 sfq  perturb 10

tc filter add dev bond0.8 parent 1:0 protocol ip u32 ht 800:: match ip dst 172.24.128.0/17 hashkey mask 0x0000ff00 at 16 link 12:

tc filter add dev bond0.8 parent 1:0 protocol ip u32

tc filter add dev bond0.8 parent 1:0 handle 12: protocol ip u32 divisor 8
tc filter add dev bond0.8 parent 1:0 handle 13: protocol ip u32 divisor 256
tc filter add dev bond0.8 parent 1:0 handle 14: protocol ip u32 divisor 256
tc filter add dev bond0.8 parent 1:0 handle 15: protocol ip u32 divisor 256
tc filter add dev bond0.8 parent 1:0 handle 16: protocol ip u32 divisor 256
tc filter add dev bond0.8 parent 1:0 handle 17: protocol ip u32 divisor 256

tc filter add dev bond0.8 parent 1:0 protocol ip u32 ht 12:0: match ip dst 172.24.128.0/24 hashkey mask 0x000000ff at 16 link 13:
tc filter add dev bond0.8 parent 1:0 protocol ip u32 ht 12:1: match ip dst 172.24.129.0/24 hashkey mask 0x000000ff at 16 link 14:
tc filter add dev bond0.8 parent 1:0 protocol ip u32 ht 12:2: match ip dst 172.24.130.0/24 hashkey mask 0x000000ff at 16 link 15:
tc filter add dev bond0.8 parent 1:0 protocol ip u32 ht 12:3: match ip dst 172.24.131.0/24 hashkey mask 0x000000ff at 16 link 16:
tc filter add dev bond0.8 parent 1:0 protocol ip u32 ht 12:4: match ip dst 172.24.132.0/24 hashkey mask 0x000000ff at 16 link 17:


tc class add dev bond0.8 parent 1:100 classid 1:1001 htb rate 20Mbit ceil 20Mbit
tc qdisc add dev bond0.8 parent 1:1001 handle 1001 sfq  perturb 10
tc filter add dev bond0.8 protocol ip parent 1:0 u32 ht 13:1: match ip dst 172.24.128.1 flowid 1:1001
tc class add dev bond0.8 parent 1:100 classid 1:1002 htb rate 20Mbit ceil 20Mbit
tc qdisc add dev bond0.8 parent 1:1002 handle 1002 sfq  perturb 10
tc filter add dev bond0.8 protocol ip parent 1:0 u32 ht 13:2: match ip dst 172.24.128.2 flowid 1:1002

[Zolks 24]

выяснилось что проблема в этой строке

tc filter add dev bond0.8 parent 1:0 protocol ip u32 ht 800:: match ip dst 172.24.128.0/17 hashkey mask 0x0000ff00 at 16 link 12:

в этот фильтр ничего не проходит,

более того, эта строка выдает такую ошибку:

RTNETLINK answers: Invalid argument
We have an error talking to the kernel

[Zolks 24]

кажется победил. проблема заключалась в том, что я направлял трафик в таблицу, которая еще не была создана.

 

всего-то надо было перенести эту строчку ниже, после создания таблиц.

tc filter add dev bond0.8 parent 1:0 handle 12: protocol ip u32 divisor 8
tc filter add dev bond0.8 parent 1:0 handle 13: protocol ip u32 divisor 256
tc filter add dev bond0.8 parent 1:0 handle 14: protocol ip u32 divisor 256
tc filter add dev bond0.8 parent 1:0 handle 15: protocol ip u32 divisor 256
tc filter add dev bond0.8 parent 1:0 handle 16: protocol ip u32 divisor 256
tc filter add dev bond0.8 parent 1:0 handle 17: protocol ip u32 divisor 256

tc filter add dev bond0.8 parent 1:0 protocol ip u32 ht 800:: match ip dst 172.24.128.0/17 hashkey mask 0x0000ff00 at 16 link 12:

[KaYot 3 711]

Не, нету там никаких таблиц. Порядок создания фильтров в данном случае не важен, грабли где-то в другом месте.

[Zolks 24]

Не, нету там никаких таблиц. Порядок создания фильтров в данном случае не важен, грабли где-то в другом месте.

тем не менее оказалось что важен, сам был удивлен.

после переноса строки ошибка пропала и шейпер заработал.

[ttttt 195]

а втулите в конце каждого правила " || exit $? ", может там еще какое-то тихо падает, а вы не знаете

[Zolks 24]

отстраненный вопрос..

интересно, для nat сервера + шейпинг загрузка ядер в районе 50-60% это нормально и безболезненно?

[ttttt 195]

При всплеске трафика потери пакетов и большие задержки будут.

[Zolks 24]

после включения шейпера идет просадка трафика с 800 мбит/с до 200 мбит/с.. печаль..

 

qdisc htb 1: dev bond0.8 root refcnt 2 r2q 10 default 900 direct_packets_stat 950
 Sent 7141497771 bytes 6612385 pkt (dropped 8237, overlimits 449639 requeues 0)
 rate 0bit 0pps backlog 0b 14147p requeues 0
qdisc pfifo 900: dev bond0.8 parent 1:900 limit 15000p
 Sent 6229871095 bytes 4438282 pkt (dropped 4555, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 19478810b 14049p requeues 0
 

Відредаговано 2014-09-30 15:49:48 Zolks

[KaYot 3 711]

Т.е. видно что дропается где-то в правилах, а не в дефолтном(без ограничений). Ищите где, статистика ж там вплоть до конечных классов есть.

[Abram 98]

Zolks,

offload-ы отключены? Особенно всякие gro/tso.

[Zolks 24]

Zolks,

offload-ы отключены? Особенно всякие gro/tso.

сегодня буду разбираться.

 

 

вот собственно как это все выглядело на графиках.

 

[KaYot 3 711]

Больше похоже на то, что хеши таки не работают и у вас сервер просто лег по 100% загрузке.