IMQ: как честно поделить 128kbit?

Не пробовали по ip роутить?

Вот такой опыт есть:

есть скрипты ipt и ipr, в ipt описываются правила NAT и паркировки пакетов для tc. В ipr идёт раздача каналов к этим маркированым пакетам.

ipt (выдержка)
----------------------------------
#1mbit passive ftp MARK 2
$ipt -t nat -A POSTROUTING -s 172.18.65.103 -p tcp -m tcp --dport 1024:65535 -j SNAT --to-source xxx.xxx.xxx.xxx
$ipt -t mangle -A POSTROUTING -d 172.18.65.103 -j MARK --set-mark 2
$ipt -t mangle -A POSTROUTING -s 172.18.65.103 -j MARK --set-mark 2
---------------------------------

ipr
--------------------------------
#1mbit MARK 2
$ipr class add dev eth0.7 parent 1:1 classid 1:2 htb rate 1mbit ceil 1mbit burst 10k
$ipr class add dev eth0.10 parent 1:1 classid 1:2 htb rate 1mbit ceil 1mbit burst 10k
$ipr qdisc add dev eth0.7 parent 1:2 handle 2:0 esfq perturb 10 hash dst
$ipr qdisc add dev eth0.10 parent 1:2 handle 2:0 esfq perturb 10 hash dst
$ipr filter add dev eth0.7 protocol ip parent 1:0 prio 1 handle 2 fw flowid 1:2
$ipr filter add dev eth0.10 protocol ip parent 1:0 prio 1 handle 2 fw flowid 1:2
-------------------------------

здесь используется esfq для описания каналов, но ничего не мешает использовать htb указав половину для каждого.

HTB? Может поможет оно для этих целей и было придуманно + куча других возможностей(типа приоритетов, сначала cs, потом http и т.д)

> Не пробовали по ip роутить?

нуу.. можно попробовать, но через нужные фильтры оно проходит и так и по целевым классам раскладывается правильно. собственно я марками тоже делал когда просто жестоко зарезал отдачу на eth0 (внутрь сетки) до 64kbit. оно работало, но это не совсем то что мне хотелось бы..

> HTB? Может поможет оно для этих целей и было придуманно

:-) а у меня что?

почему не совсем то?

Задача-то довольно проста - если 64к канал занимают оба устройства - они должны делить его поровну.

В противном случае, одно из устройство использует часть "чужого канала" (если он ниже 64к).

Идеально для этих целей подходит esfq, ибо разделяет канал поровну между всеми ip адресами.

Придётся, конечно, попатчить немного ядро, но у меня поднялось без проблем.

> почему не совсем то? Задача-то довольно проста - если 64к канал занимают оба устройства - они должны делить его поровну.

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

про esfq -- почитаю конечно, спасибо.

s/64k/128k

А мне кажется что можно обойтись без IMQ!

В новом ESFQ появились интересные возможности, связанные с равномерным распредлением выходящего трафика в интернет при использование gateway + NAT. Что по сути своей как мне кажется избавляет от необходимости imq.
http://fatooh.org/esfq-2.6/current/README
hash ctorigdst, ctorigsrc, ctrepldst, ctreplsrc:
# Example 3: Like the example above, but for the WAN interface (eth1 instead of
# eth0). This example is intended for usage on a NAT router, so it uses
# ctorigsrc instead of src).
tc qdisc add dev eth1 parent 1:12 handle 12: esfq perturb 10 hash ctorigsrc

У меня gateway именно так и работает!

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

Я думаю, что там, где от IMQ требуются свойства именно интерфейса, а не только "точки" между DNAT/SNAT, заменить не получится.

А по первоначальному вопросу:
1) у вас скорость входящего трафика никак не зависит от исходящего (канал дуплексный) ?
2) почему 128K делится на 3x64K ??? Почему не на 2x64 или 3x42 ? (с учетом наличия приоритетов в классах затрудняюсь точно сказать какие эффекты будет вызывать наличие разных видов трафика в приведенном примере)

> Я думаю, что там, где от IMQ требуются свойства именно интерфейса, а не только "точки" между DNAT/SNAT, заменить не получится.

совершенно верно :-)

> 1) у вас скорость входящего трафика никак не зависит от исходящего (канал дуплексный) ?

да. банальный pppoe на adsl-e. физически там 1024/768

> 2) почему 128K делится на 3x64K ??? Почему не на 2x64 или 3x42 ? (с учетом наличия приоритетов в классах затрудняюсь точно сказать какие эффекты будет вызывать наличие разных видов трафика в приведенном примере)

я пробовал убирать высокоприоритетный класс и оставлял только два равноприоритетных -- толку ноль.

[quote]
Не думаю, что полностью избавляет. В случае NAT-а - да, а вот в случае обработки трафика - нет. ESFQ будет обрабатывать только исходящий трафик, а dmiceman-у нужно ограничивать именно входящий, и без IMQ здесь никак (иначе на какой интерфейс вешать ESFQ ?).
[/quote]

Да, тут я учел момент только транзитного трафика приходящего с интернета и направленного в локалку.
Скорость входящего трафика направленного в локалку можно ограничить на сетевухе которая смотрит в локалку (вот эту сетевуху и и думал посадить ESFQ).


Буду упрямится, но и входящий трафик (состоящий из транзитного и к локальным процессам) можно подшепить без IMQ а с помощью IFB, например
что то вроде:

modprobe ifb
ip link set dev ifb0 up
tc qdisc del dev ifb0 root
... далее на IFB посадить ESFQ .....

Перенаправить весь входящий трафик на eth0 (cетевуху смотрящая в интернет) в IFB
tc filter add dev eth0 parent ffff: protocol ip \
u32 match u32 0 0 action mirred egress redirect dev ifb0



PS
собственно сейчас вот с этим IFB я и экспериментирую

такого новомодного ругательства как IFB я еще не знаю :-) но по смыслу -- чем он от IMQ отличается?

Считается IFB идеологически более правильная реализация псевдо-устройства, поэтому IMQ никогда не поставят в кернел.

Насколько я понял идеологически
IFB - это скорее для iproute2
IMQ - iptables

Документация по IFB в исходниках iproute
doc/actions/

Допишу ещё следствия, которые я вижу (но с которыми до конца не разобрался)

Если фильтры для классов делать по меткам в iptables то будет следующая ситуция

входящий трафик на eth0 перенапрвляется в IFB, то в IFB нет ни какой информации о метках сделанных в iptables (поскольку IFB стоит до iptables).

Что мне кажется крайне не удобным, привык использовать iptables connbytes а аналога iproute2 такого нет как мне кажется