[LARTC] Some questions concerning IPtables (& IMQ/SFQ)

[LARTC] Some questions concerning IPtables (& IMQ/SFQ)

[Nils Lichtenfeld]

Hi there!

Some questions I couldn't find an answer for:
IPtables:
- Is it possible to filter those ACK-packets (to eleminate problems
with ADSL-connections) with IPtables? It wasn't possible with IPchains,
so u32 had to be used. Now there is this nice little --tcp-flags
option. But I just don't know if this is all I need. The u32 was
checking for packetsize too. So if there is a eqivalent to the u32
ACK-filterrule, what would it look like?

What I have found in the ML is this:
----
# Set ACK as prioritized traffic (ACK's are less than 100 bytes)
$IPTABLES -t mangle -A MANGLE_MARK -p tcp -m length --length :100 -j
MARK --set-mark 1
$IPTABLES -t mangle -A MANGLE_MARK -p tcp -m length --length :100 -j
RETURN
----

Wouldn't that apply on a lot more packets than only the ACK ones? What
is the exact specification of an ACK-packet?

- With IPchains it was possible to mark and return in one rule. Looking
at the example above this doesn't seem possible (two -j operators). Is
that right?

- Can I have for example one custom chain and have forward and output
send its packets to it?

- Is there a howto that explains -t mangel, -A PREROUTING/POSTROUTING
etc.? The only IPtables HowTo I have found is
http://www.telematik.informatik.uni-karlsruhe.de/lehre/seminare/LinuxSe
m/downloads/netfilter/iptables-HOWTO.html

- From Patricks' IMQ-page:
----
SFQ is very useful as a leaf qdisc. But by default, its internal queue
length is 128 which is too much for small classes or even for
not-so-fast links. Changing SFQ_DEPTH in net/sched/ sch_sfq.c to about
10-20 results in flows responding much faster to bandwidth changes.
----

Is that ment for SFQ in general or only in conjunction with IMQ?


Thank you.
Greetings, Nils

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] Some questions concerning IPtables (& IMQ/SFQ)

[Tobias Geiger]

On Fri, May 03, 2002 at 04:50:18PM +0200, Nils Lichtenfeld wrote:
> Hi there!
Hi Nils
> 
> Some questions I couldn't find an answer for:
> IPtables:
> - Is it possible to filter those ACK-packets (to eleminate problems
> with ADSL-connections) with IPtables? It wasn't possible with IPchains,
> so u32 had to be used. Now there is this nice little --tcp-flags
> option. But I just don't know if this is all I need. The u32 was
> checking for packetsize too. So if there is a eqivalent to the u32
> ACK-filterrule, what would it look like?
> 
> What I have found in the ML is this:
> ----
> # Set ACK as prioritized traffic (ACK's are less than 100 bytes)
> $IPTABLES -t mangle -A MANGLE_MARK -p tcp -m length --length :100 -j
> MARK --set-mark 1
> $IPTABLES -t mangle -A MANGLE_MARK -p tcp -m length --length :100 -j
> RETURN
> ----
> 
> Wouldn't that apply on a lot more packets than only the ACK ones? What
> is the exact specification of an ACK-packet?

I don't know the exact technical specification for ACK packets, but i
use the example below, and it work's (i mean as far as i can see, no
"other" packets get in my $ack-queue)

> 
> - With IPchains it was possible to mark and return in one rule. Looking
> at the example above this doesn't seem possible (two -j operators). Is
> that right?
>
sorry, don't know
 
> - Can I have for example one custom chain and have forward and output
> send its packets to it?
> 
well i think so. 
i use constructs like these:

start_ingress_iptables() {

        $iptables -t mangle -N IMQ_INGRESS
        $iptables -t mangle -A IMQ_INGRESS -m state --state ESTABLISHED -p tcp --sport ssh -j MARK --set-mark $high
        $iptables -t mangle -A IMQ_INGRESS -m state --state ESTABLISHED -p tcp --sport http -j MARK --set-mark $high
        $iptables -t mangle -A IMQ_INGRESS -m state --state ESTABLISHED -m length --length 40:100 -j MARK --set-mark $ack
        $iptables -t mangle -A IMQ_INGRESS -j IMQ --todev 0
        $iptables -t mangle -A PREROUTING -i ${SHAPEDEV} -j IMQ_INGRESS

}

and i see no reason why i couln't add something like:
	iptables -t mangle -A POSTROUTING -o somedevice -j IMQ_INGRESS


> - Is there a howto that explains -t mangel, -A PREROUTING/POSTROUTING
> etc.? The only IPtables HowTo I have found is
> http://www.telematik.informatik.uni-karlsruhe.de/lehre/seminare/LinuxSe
> m/downloads/netfilter/iptables-HOWTO.html
>
netfilter.org ?!
 
> - From Patricks' IMQ-page:
> ----
> SFQ is very useful as a leaf qdisc. But by default, its internal queue
> length is 128 which is too much for small classes or even for
> not-so-fast links. Changing SFQ_DEPTH in net/sched/ sch_sfq.c to about
> 10-20 results in flows responding much faster to bandwidth changes.
> ----
> 
> Is that ment for SFQ in general or only in conjunction with IMQ?
> 
I think it's meant for slower links in general. 
btw i made the experience that SFQ_DEPTH has to be a value dividable by 8
(i use 24 and in my subjective opinion i have better interactivity)

> 
> Thank you.
> Greetings, Nils
>

Greetings

Tobias 
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] Some questions concerning IPtables (& IMQ/SFQ)

[Patrick McHardy]

Hi !
I guess i have to clarify this.

> - From Patricks' IMQ-page:
> ----
> SFQ is very useful as a leaf qdisc. But by default, its internal queue
> length is 128 which is too much for small classes or even for
> not-so-fast links. Changing SFQ_DEPTH in net/sched/ sch_sfq.c to about
> 10-20 results in flows responding much faster to bandwidth changes.
> ----
> 
> Is that ment for SFQ in general or only in conjunction with IMQ?

It was meant in conjunction with IMQ and ingress shaping.
The text is a bit misleading, i'm not sure if it is right.
My thought was:
One connection, 1 mbit rate, avg. pkt size 1480 = ~88pkt/sec.
To fill up entire SFQ_DEPTH of 128 it would take 1.45 seconds.
So if less bandwidth was available for this connection it would take at 
least this long + 1/2 rtt until package drops become noticeable for the 
remote side. This is probably not true as SFQ drops a (not necessary 
the last one!) packet from its longest slot if if queue becomes full.
I had a noticable effect in combination with imq but since then changed
the point at which imq tries to dequeue packets and in the mean time, i'm 
using it without changed SFQ_DEPTH.
I saw the same advice on another page, but like said before, i'm not sure 
if it is true. I'm going to think about it again as soon as my head clears 
up ;)

Bye,
Patrick

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/