Решено: iproute tc & QoS (написание правил)

[patrius]

обычно при написании правил используется что-то вида

Код:

tc qdisc add dev br0 root handle 1: htb default 999 ... tc class add dev br0 parent 1:1 classid 1:999 htb rate 32kbps ceil 100kbps prio 7 tc qdisc add dev br0 parent 1:999 handle 999: sfq perturb 10

а если сделасть иным образом?

Код:

tc qdisc add dev br0 root handle 1: htb ... tc class add dev br0 parent 1:1 classid 1:999 htb rate 32kbps ceil 100kbps prio 7 tc filter add dev br0 protocol ip parent 1: prio 7 u32 match ip dst 0.0.0.0/0 flowid 1:999 tc qdisc add dev br0 parent 1:999 handle 999: sfq perturb 10

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

собственно смущает

Код:

#tc filter show br0 filter parent 1: protocol ip pref 3 u32 fh 801::812 order 2066 key ht 801 bkt 0 flowid 1:12 match c0a86439/ffffffff at 16 filter parent 1: protocol ip pref 3 u32 fh 801::813 order 2067 key ht 801 bkt 0 flowid 1:13 match c0a8640e/ffffffff at 16 filter parent 1: protocol ip pref 7 u32 filter parent 1: protocol ip pref 7 u32 fh 802: ht divisor 1 filter parent 1: protocol ip pref 7 u32 fh 802::800 order 2048 key ht 802 bkt 0 flowid 1:18 match 00000000/00000000 at 16 filter parent 1: protocol ip pref 9 u32 filter parent 1: protocol ip pref 9 u32 fh 800: ht divisor 1 filter parent 1: protocol ip pref 9 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:2 match c0a86401/ffffffff at 12 filter parent 1: protocol ip pref 9 u32 fh 800::801 order 2049 key ht 800 bkt 0 flowid 1:2 match ac101001/ffffffff at 12

[Heimdall]

Код:

tc filter add dev br0 protocol ip parent 1: prio 7 u32 match ip dst 0.0.0.0/0 flowid 1:999

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

А arp куда попадет? В отдельный фильтр?

[Alex2ndr]

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

Можно и так сделать. Только обычно это менее удобно, т к нужно писать лишнее правило. Это как в iptables - можно политику задать, а можно в последнем правиле DROP написать.

собственно смущает
...

Если вы дадите более подробное описание того, что именно вас смущает, то может чего и скажу по этому вопросу. А лезть в мануал, чтобы вспомнить что обозначают все эти буковки в фильтрах.... не хочу

А arp куда попадет? В отдельный фильтр?

А arp то тут при чем? Шейпер работает на 3-м уровне, а arp - на втором. Так что никакими arp мозги можно не забивать.

[Heimdall]

А arp то тут при чем? Шейпер работает на 3-м уровне, а arp - на втором. Так что никакими arp мозги можно не забивать.

Нет. ARP - протокол сетевого уровня.
Без класса по умолчанию ARP по идее надо описать отдельно. Проверил

Код:

$tc qdisc add dev $dev root handle 1: htb # default 999 $tc class add dev $dev parent 1: classid 1:1 htb rate ${ceil} ceil ${ceil} $tc class add dev $dev parent 1:1 classid 1:999 htb rate ${ceil} ceil ${ceil} prio 7 $tc filter add dev $dev protocol ip parent 1: prio 7 u32 match ip dst 0.0.0.0/0 flowid 1:999 $tc qdisc add dev $dev parent 1:999 handle 999: sfq perturb 10 $tc class add dev $dev parent 1:1 classid 1:2 htb rate ${ceil} ceil ${ceil} prio 7 $tc filter add dev $dev protocol arp parent 1: u32 match u32 0 0 flowid 1:2 $tc qdisc add dev $dev parent 1:2 handle 2: sfq perturb 10

Код:

arping -I wlan0 modem

Код:

class htb 1:999 parent 1:1 prio 7 quantum 6250 rate 500000bit ceil 500000bit burst 1600b/8 mpu 0b overhead 0b cburst 1600b/8 mpu 0b overhead 0b level 0 Sent 94520 bytes 538 pkt (dropped 0, overlimits 0 requeues 0) class htb 1:1 root rate 500000bit ceil 500000bit burst 1600b/8 mpu 0b overhead 0b cburst 1600b/8 mpu 0b overhead 0b level 7 Sent 97250 bytes 603 pkt (dropped 0, overlimits 0 requeues 0) class htb 1:2 parent 1:1 prio 7 quantum 6250 rate 500000bit ceil 500000bit burst 1600b/8 mpu 0b overhead 0b cburst 1600b/8 mpu 0b overhead 0b level 0 Sent 2730 bytes 65 pkt (dropped 0, overlimits 0 requeues 0)

[Alex2ndr]

Нет. ARP - протокол сетевого уровня.

На самом деле это неоднозначный вопрос Например страница Википедии, посвященная OSI на английском говорит о том, что ARP это Data Link Layer (т е 2). А та же страница, но по-русски говорит, что ARP это протокол сетевого уровня. Так что здесь нужно копаться в определениях... Лично я для себя считаю 3-м уровнем маршрутизируемые протоколы.

Без класса по умолчанию ARP по идее надо описать отдельно. Проверил
...

Возможно даже с классом по умолчанию arp стоит писать отдельно, т к класс по умолчанию обычно делают неприоритетным (ведь приоритетного трафика обычно меньше чем иного). Из этого следует, что arp запросы будут стоять в очереди вместе со всякими торрентами, что может негативно сказаться в больших сетях. Но я считаю (повторюсь), что обычно на arp можно не обращать внимание, т к его доля весьма мала по сравнению со всем остальным трафиком. Разве что у вас реально большие широковещательные домены. Лично я в своих шейперах про arp не вспоминаю даже.

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

[patrius]

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

Можно и так сделать. Только обычно это менее удобно, т к нужно писать лишнее правило. Это как в iptables - можно политику задать, а можно в последнем правиле DROP написать.

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

собственно смущает
...

Если вы дадите более подробное описание того, что именно вас смущает, то может чего и скажу по этому вопросу. А лезть в мануал, чтобы вспомнить что обозначают все эти буковки в фильтрах.... не хочу

Я как-то не встречал информации о порядке срабатывания фильтров.
ИМХО, считаю, что они отрабатываются в порядке ввода. в приведенном примере tc filter show, отображает в порядке убывания приоритета. Или я упустил момент значимости приоритета фильтра.
Последнее время перечитываю соответствующий раздел LAR&TC.. и что-то в упор не вижу инфы по этому поводу.

А arp то тут при чем? Шейпер работает на 3-м уровне, а arp - на втором. Так что никакими arp мозги можно не забивать.

Нет. ARP - протокол сетевого уровня.
Без класса по умолчанию ARP по идее надо описать отдельно. Проверил

Код:

$tc qdisc add dev $dev root handle 1: htb # default 999 $tc class add dev $dev parent 1: classid 1:1 htb rate ${ceil} ceil ${ceil} $tc class add dev $dev parent 1:1 classid 1:999 htb rate ${ceil} ceil ${ceil} prio 7 $tc filter add dev $dev protocol ip parent 1: prio 7 u32 match ip dst 0.0.0.0/0 flowid 1:999 $tc qdisc add dev $dev parent 1:999 handle 999: sfq perturb 10 $tc class add dev $dev parent 1:1 classid 1:2 htb rate ${ceil} ceil ${ceil} prio 7 $tc filter add dev $dev protocol arp parent 1: u32 match u32 0 0 flowid 1:2 $tc qdisc add dev $dev parent 1:2 handle 2: sfq perturb 10

Код:

arping -I wlan0 modem

Код:

class htb 1:999 parent 1:1 prio 7 quantum 6250 rate 500000bit ceil 500000bit burst 1600b/8 mpu 0b overhead 0b cburst 1600b/8 mpu 0b overhead 0b level 0 Sent 94520 bytes 538 pkt (dropped 0, overlimits 0 requeues 0) class htb 1:1 root rate 500000bit ceil 500000bit burst 1600b/8 mpu 0b overhead 0b cburst 1600b/8 mpu 0b overhead 0b level 7 Sent 97250 bytes 603 pkt (dropped 0, overlimits 0 requeues 0) class htb 1:2 parent 1:1 prio 7 quantum 6250 rate 500000bit ceil 500000bit burst 1600b/8 mpu 0b overhead 0b cburst 1600b/8 mpu 0b overhead 0b level 0 Sent 2730 bytes 65 pkt (dropped 0, overlimits 0 requeues 0)

По поводу ARP могу сказать, что все протоколы, которые в данном раскладе нуждаются в повышении приоритета я выделяю в отдельные правила будь то ICMP, GRE или еще какая шняга )


Именно по САБЖУ могу обозначить, что для меня подобное решение, т.е. плавающее дефолт самое нормальное )))

[Alex2ndr]

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

Ну я делаю так же. Но готов мирится с отсутствием одного фильтра

Я как-то не встречал информации о порядке срабатывания фильтров.
ИМХО, считаю, что они отрабатываются в порядке ввода. в приведенном примере tc filter show, отображает в порядке убывания приоритета. Или я упустил момент значимости приоритета фильтра.
Последнее время перечитываю соответствующий раздел LAR&TC.. и что-то в упор не вижу инфы по этому поводу.

Лично я не заморачиваюсь и даю каждый фильтр со своим приоритетом. Вроде этот счетчик там достаточно большой(по моему до 65536) и можно не беспокоится. Так что для меня prio равно номеру правила.
А LAR&TC действительно бедноват в этом вопросе(и не только в нем). Я теперь усиленно ищу более подробный источник информации.

[patrius]

только что наткнулся на фразу, в самой зачитай мною статье:

Поле preference (в качестве синонима можно использовать priority) описывает приоритет определяемого фильтра, что позволяет задавать несколько фильтров (списков правил) с различными приоритетами. Вообще, правила обслуживаются в порядке добавления в список, в случае с приоритетами -- первыми обслуживаются правила, имеющие наивысший приоритет (чем меньше число, тем выше приоритет).

раздел
со старенького документика... с OpenNet