Необходимо поднять шейпер на TC.
Задался таким вопросом, в каком месте работает TC?
Тут, в "<Routing decision>", сразу после nat-PREROUTING?----------------------------
<Network>
1) mangle - PREROUTING
2) nat - PREROUTING
<Routing decision>
+------------+--------------+
3) mangle - INPUT |
4) filter - INPUT |
<Local process> 8) mangle - FORWARD
<Routing decision> 9) filter - FORWARD
5) mangle - OUTPUT |
6) nat - OUTPUT |
7) filter - OUTPUT |
+------------+--------------+
10) mangle - POSTROUTING
11) nat - POSTROUTING
<Network>
----------------------------
http://l7-filter.sourceforge.net/PacketFlow.png
>http://l7-filter.sourceforge.net/PacketFlow.pngСпасибо tungus.
Получается что ingress qdisc работает вообще до iptables.Почему тогда работает такой финт:
iptables -t mangle -A PREROUTING -i eth0 -s 192.168.0.1 -j MARK --set-mark 1
tc qdisc add dev eth0 handle ffff: ingress
tc filter add dev eth0 parent ffff: protocol ip prio 50 handle 1 fw police rate 32Kbit burst 4K drop flowid :1т.е. маркеры я расставляю в iptbales, и согласно их ingress qdisc режет трафик.
Как так получается?
>[оверквотинг удален]
>Почему тогда работает такой финт:
>iptables -t mangle -A PREROUTING -i eth0 -s 192.168.0.1 -j MARK --set-mark
>1
>tc qdisc add dev eth0 handle ffff: ingress
>tc filter add dev eth0 parent ffff: protocol ip prio 50 handle
>1 fw police rate 32Kbit burst 4K drop flowid :1
>
>т.е. маркеры я расставляю в iptbales, и согласно их ingress qdisc режет
>трафик.
>Как так получается?iptables -L -t mangle
>>http://l7-filter.sourceforge.net/PacketFlow.png
>
>Спасибо tungus.
>Получается что ingress qdisc работает вообще до iptables.
>Да.
>Почему тогда работает такой финт:
>iptables -t mangle -A PREROUTING -i eth0 -s 192.168.0.1 -j MARK --set-mark
>1
>tc qdisc add dev eth0 handle ffff: ingress
>tc filter add dev eth0 parent ffff: protocol ip prio 50 handle
>1 fw police rate 32Kbit burst 4K drop flowid :1
>
>т.е. маркеры я расставляю в iptbales, и согласно их ingress qdisc режет
>трафик.
>Как так получается?А с чего вы взяли что у вас работает такой финт?
Единственный способ ограничивать скорость входящего трафика используя iptables для классификации - это IMQ : http://www.docum.org/docum.org/kptd/Даже с ifb http://www.linux-foundation.org/en/Net:IFB неполучится использовать iptables для классификации
>А с чего вы взяли что у вас работает такой финт?
>Единственный способ ограничивать скорость входящего трафика используя iptables для классификации - это
>IMQ : http://www.docum.org/docum.org/kptd/
>
>Даже с ifb http://www.linux-foundation.org/en/Net:IFB неполучится использовать iptables для классификацииГм. Хотя согласно http://www.docum.org/docum.org/kptd/ "QOS INGRESS" идёт после PREROUTING. Нато будет спросить на lartc mailing list
>Гм. Хотя согласно http://www.docum.org/docum.org/kptd/ "QOS INGRESS" идёт после PREROUTING. Нато будет спросить на lartc mailing listТочно, думаю, вот эта блок-схема правильнее будет.
Но засада в том что, если включен NAT, то пакет в цепочке PREROUTING идет еще неотработанный NAT'ом, и адрес назначения еще не известен. А раз так, то отмаркировать его нельзя, а нельзя отмаркировать, то и шейпер его пропустит...А с IMQ намучался уже, никак не могу ядро с ним скомпилировать, то одни ошибки, то другие.
>Но засада в том что, если включен NAT, то пакет в цепочке
>PREROUTING идет еще неотработанный NAT'ом, и адрес назначения еще не известен.
>А раз так, то отмаркировать его нельзя, а нельзя отмаркировать, то
>и шейпер его пропустит...
>
>А с IMQ намучался уже, никак не могу ядро с ним скомпилировать,
>то одни ошибки, то другие.Ядро скомпилировал, но реч не об этом.
Подскажите, а пакет в IMQ уходит, судя по диаграмме, из цепочки PREROUTING?
Значит при включенном NAT'е, пакет будет содержать IP_DEST не истинного владельца.
А раз так, то его не отмаркируешь, и мне толку от IMQ не будет никакого...
>Ядро скомпилировал, но реч не об этом.Вообще в последнее время информация на http://www.linuximq.net/ давно не обновлялась (хотя 2008-02-18 как раз обновилась) - более актуальные патчи можно найти на mailing list http://tech.groups.yahoo.com/group/linuximq/ (или например на http://www.actusa.net/~linuximq/ )
>
>Подскажите, а пакет в IMQ уходит, судя по диаграмме, из цепочки PREROUTING?
>
>Значит при включенном NAT'е, пакет будет содержать IP_DEST не истинного владельца.
>А раз так, то его не отмаркируешь, и мне толку от IMQ
>не будет никакого...Смотря как собрано - нужно включить "after NAT in PREROUTING" при сборке ядра
prompt "IMQ behavior (PRE/POSTROUTING)"
depends on IMQ
default IMQ_BEHAVIOR_BB
helpThis settings defines how IMQ behaves in respect to its
hooking in PREROUTING and POSTROUTING.IMQ can work in any of the following ways:
PREROUTING | POSTROUTING
-----------------|-------------------
#1 After NAT | After NAT
#2 After NAT | Before NAT
#3 Before NAT | After NAT
#4 Before NAT | Before NATThe default behavior is to hook before NAT on PREROUTING
and after NAT on POSTROUTING (#3).This settings are specially usefull when trying to use IMQ
to shape NATed clients.More information can be found at: www.linuximq.net
If not sure leave the default settings alone.
Попадались так же мне сторонние патчи (не с linuximq.net), где можно указать поведение как параметр модуля imq.ko
У вас кстати какое ядро используется? Не 2.4?
tungus, спасибо за развернутый ответ!>У вас кстати какое ядро используется? Не 2.4?
2.6.18-5-686
При компиляци, когда увидел количество опций, ужаснулся.
На всякий, если кому надо, вот ссылка на IMQFAQ, там как раз сказано как менять точки выхода в IMQ http://wiki.nix.hu/cgi-bin/twiki/view/IMQ/ImqFaq#Can_I_chang...
>У вас кстати какое ядро используется? Не 2.4?А какие с 2.4 могут быть проблемы?
>Но засада в том что, если включен NAT, то пакет в цепочке
>PREROUTING идет еще неотработанный NAT'ом, и адрес назначения еще не известен.
>А раз так, то отмаркировать его нельзя, а нельзя отмаркировать, то
>и шейпер его пропустит...
>
>А с IMQ намучался уже, никак не могу ядро с ним скомпилировать,
>то одни ошибки, то другие.отработанный НАТ'ом он будет в цепочке mangle FORWARD, вот там то его и отмаркировать ;)
>>Но засада в том что, если включен NAT, то пакет в цепочке
>>PREROUTING идет еще неотработанный NAT'ом, и адрес назначения еще не известен.
>>А раз так, то отмаркировать его нельзя, а нельзя отмаркировать, то
>>и шейпер его пропустит...
>>
>>А с IMQ намучался уже, никак не могу ядро с ним скомпилировать,
>>то одни ошибки, то другие.
>
>отработанный НАТ'ом он будет в цепочке mangle FORWARD, вот там то его
>и отмаркировать ;)Ага, карман шире ;) А маршрутизировать вы его как собираетесь после этого?
Вот трассировка прохождения пакета, от меня (192.168.0.2) в интернет и обратно, через маршрутизатор (192.168.0.1)eth0 (192.168.0.1) =>
PREROUTING / mangle 192.168.0.2 => 213.180.204.8
PREROUTING / nat 192.168.0.2 => 213.180.204.8
FORWARD / mangle 192.168.0.2 => 213.180.204.8
POSTROUTING / nat SNAT 192.168.0.2 на 127.62.11.73
=> tun0 (127.62.11.73)dvb0_1 =>
PREROUTING / mangle 213.180.204.8 => 127.62.11.73
PREROUTING / nat -нет-
FORWARD / mangle 213.180.204.8 => 192.168.0.2
=> eth01. Когда пакет возвращяется, цепочку "PREROUTING / nat" он даже и не проходит, видимо с ним на этом шаге происходит обратная трансляция NAT. Достаточно странно что пакет в этой цепочке не появляется, пусть после трансляции хоть бы всплывал тут...
2. Ядро скомпилировано так, чтобы пакет улетал в IMQ только после POSTROUTING / nat.
Какой глубинный смысл строчки "iptables -t mangle -A PREROUTING -i * -j IMQ --todev 0". Причем именно в _mangle_, если пакет туда попадет уже после PREROUTING / nat ?3. Получается так, что входящий пакет, который проходит NAT, даже при использовании IMQ, невозможно отмаркировать для нужд шейпера.
Вот если NAT убрать, все получается красиво, если NAT работает, блин не получается...
Приветствую Всех!Каким образм трасировку прохождения пакета снимали, очень надо), много
вопросов отпадет.