Sending traffic from one IMQ to another

I was wondering is this is possible:


iptables -t nat -I PREROUTING -i eth0 -j IMQ --todev 0
iptables -t nat -I PREROUTING -i imq0 -j IMQ --todev 1


this way i can apply different levels of QoS to imq0 and imq1 to get a
cascading effect.... for example give each user 64kbits, but rate
limit total ftp traffic to 128kbit. So if a user was to only do ftp
transfers, and no other user was doing any ftp transfers, the user
would get 64kbits max. However, if multiple users started ftp
transfers, the sum total ftp rate would not exceed 128kbits.


I tried the above setup, however, no packets ever match rule #2 above.

Any ideas how this can be accomplished?

TIA,
Padam

(E-Mail Removed) wrote:

> this way i can apply different levels of QoS to imq0 and imq1 to get a
> cascading effect.... for example give each user 64kbits, but rate
> limit total ftp traffic to 128kbit. So if a user was to only do ftp
> transfers, and no other user was doing any ftp transfers, the user
> would get 64kbits max. However, if multiple users started ftp
> transfers, the sum total ftp rate would not exceed 128kbits.

er... I don't think you need IMQ for that. A classful qdisc as HTB with
a carefully created tree and filters will suit your needs.

hjf

--
Sí esta atascado, fuércelo. Sí se rompe, es que necesitaba ser reemplazado.

http://www.hjf.com.ar/

On 2005-04-27, (E-Mail Removed) <(E-Mail Removed)> wrote:
> I was wondering is this is possible:
>
>
> iptables -t nat -I PREROUTING -i eth0 -j IMQ --todev 0
> iptables -t nat -I PREROUTING -i imq0 -j IMQ --todev 1
>
>
> this way i can apply different levels of QoS to imq0 and imq1 to get a
> cascading effect.... for example give each user 64kbits, but rate
> limit total ftp traffic to 128kbit. So if a user was to only do ftp
> transfers, and no other user was doing any ftp transfers, the user
> would get 64kbits max. However, if multiple users started ftp
> transfers, the sum total ftp rate would not exceed 128kbits.
>
>
> I tried the above setup, however, no packets ever match rule #2 above.
>
> Any ideas how this can be accomplished?
>
IMQ does not permit this. What happens is that, I munched the code when
porting it to 2.6[1], the kernel evaluates the state of a variable as it
leaves the PRE/POSTROUTING mangle[2] tables the decision is made which imq
device to jump to, if at all. All that happen when you run those commands is
not a 'jump' command like it looks like it does, but rather sets a flag
saying "yeah kernel, when you get around to it go to imqx". So at the end of
your '-j IMQ' commands above the kernel will actually jump to imq1
regardless.

Roughly now I expect you to be cursing Do not fear I have a solution,
which will be making a grand appearence in the next edition of my QoS script.
There has been much talk of instead using the 'dummy' linux module[3] for QoS
work. I have been playing around and found you can hook from the IMQ
interface to the dummy0 interface. dummy0 could then link into dummy1, and
then into dummy2, and so on and so forth. Cunning huh?

<internet> -> ppp0 -> imq0 -> dummy0 -> dummy1 -> ... -> eth0 -> <LAN>

If you cannot wait for me to shift myself and write this script (I also need
to port hipac-nf to 2.6.... :-/ ) you can do some research with the follow:

http://marc.theaimsgroup.com/?l=linu...2327422706&w=2

So far all I have done is create a chain (going as high as dummy0), yet to
play with dummy1. The following is roughly what you need, but it does not
work! I have been able to get ICMP echo/reply (aka ping) packets to traverse
this fancy chain with no problems; I have not done anymore due to time and
its a home live system which if it broke my flatmate would stop buying beer
in protest

--------
TC=/usr/sbin/tc
IPTABLES=/usr/local/sbin/iptables
IP=/usr/sbin/ip

IF=eth0 # WAN facing interface
IMQUP=imq0
DUMMYUP0=dummy0
IMQDW=imq1
DUMMYDW0=dummy1
DUMMYDW1=dummy2


########## imq <-> dummy hooks
# UP
$TC qdisc add dev $IMQUP root handle 1: prio
$TC qdisc add dev $DUMMYUP0 root handle 1: prio

$TC filter add dev $IMQUP parent 1:0 protocol ip prio 10 \
u32 match u32 0 0 flowid 1:1 action mirred egress redirect dev
$DUMMYUP0

# DOWN
$TC qdisc add dev $IMQDW root handle 1: prio
$TC qdisc add dev $DUMMYDW0 root handle 1: prio

$TC filter add dev $IMQDW parent 1:0 protocol ip prio 10 \
u32 match u32 0 0 flowid 1:1 action mirred egress redirect dev
$DUMMYDW0
$TC qdisc add dev $DUMMYDW1 root handle 1: prio
$TC filter add dev $DUMMYDW0 parent 1:0 protocol ip prio 10 \
u32 match u32 0 0 flowid 1:1 action mirred egress redirect dev
$DUMMYDW1
#########

$IPTABLES -t mangle -I POSTROUTING 2 -o $IF -j IMQ --todev 0
$IPTABLES -t mangle -I OUTPUT 2 -o $IF -j IMQ --todev 0
$IPTABLES -t mangle -I PREROUTING 2 -i $IF -j IMQ --todev 1

$IP link set $IMQUP up
$IP link set $IMQDW up
--------

A word of advice, I would avoid creating your QoS qdiscs on IMQ, just
because, it does not feel so clean. Use IMQ as a system to move packets into
your dummy0 chain rather than to move things into the dummy chain and then
shape them.

Have fun

Alex

[1] for I am Jim diGriz of jdg-qos-script fame
[2] you should consider the 'mangle' table rather than the 'nat' one
[3] this module provides you with 'dummy0',etc to use as a blackhole routing
device, useful for legacy reasons

>
> TIA,
> Padam
>