LARTC - Apr 2006 - Trying to do some very simple ingress limiting, no success

Hi,

I am trying to do some simple ingress limiting based on fwmark. I know
the ability and sense to do INGRESS limiting is ehm... limited ;-) but
still I want to try it.

I tried several things.

=== 1 ==
tcq ingress handle ffff: 
tcf parent ffff: protocol ip prio 1 handle 1 fw police rate 12mbit burst 10k
drop
tcf parent ffff: protocol ip prio 1 handle 2 fw police rate 10mbit burst 10k
drop
tcf parent ffff: protocol ip prio 1 handle 3 fw police rate 1mbit  burst 10k
drop

This installs OK, but the filters are never called. The netfilter stats
show the marks are set though. To make sure it''s not just the tc stats
output that''s borked, I changed the bw limits to a rediculous low
value,
and indeed, no effect at all.

=== 2 ==
tcq ingress handle ffff: 
tcq parent ffff: handle 10 htb 
tcc parent ffff: htb rate 12mbit
tcc parent ffff: htb rate 10mbit
tcc parent ffff: htb rate 1mbit
tcf parent ffff: protocol ip prio 1 fw 

I tricked tc into attaching a htb to the root qdisc. This gives no errors
but also doesn''t seem to do anything. If you use tc show
qdisc|filter|class
the qdisc,filters and classes are not even shown, so I guess it''s
borked
(tc should have given an error that it won''t work).

=======
IMHO it isn''t that complex I want to achieve... The example of the
synflood
protector also doesn''t work, btw.

I am using linux 2.6.16.1 and these rules to mark:

iptables -t mangle -N classify-high
iptables -t mangle -A classify-high -j MARK --set-mark 1
iptables -t mangle -A classify-high -j ACCEPT

iptables -t mangle -N classify-medium
iptables -t mangle -A classify-medium -j MARK --set-mark 2
iptables -t mangle -A classify-medium -j ACCEPT

iptables -t mangle -N classify-low
iptables -t mangle -A classify-low -j MARK --set-mark 3
iptables -t mangle -A classify-low -j ACCEPT

The "ACCEPT"s are necessary, otherwise the classification will
overflow and all packets are marked with "3".

Thanks in advance.


_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Erik Slagter wrote:
> Hi,
> 
> I am trying to do some simple ingress limiting based on fwmark. I know
> the ability and sense to do INGRESS limiting is ehm... limited ;-) but
> still I want to try it.
> 
> I tried several things.
> 
> === 1 ==> 
> tcq ingress handle ffff: 
> tcf parent ffff: protocol ip prio 1 handle 1 fw police rate 12mbit burst
10k drop
> tcf parent ffff: protocol ip prio 1 handle 2 fw police rate 10mbit burst
10k drop
> tcf parent ffff: protocol ip prio 1 handle 3 fw police rate 1mbit  burst
10k drop
> 
> This installs OK, but the filters are never called. The netfilter stats
> show the marks are set though. To make sure it''s not just the tc
stats
> output that''s borked, I changed the bw limits to a rediculous low
value,
> and indeed, no effect at all.
> 
There are two policers now the old one will work as you want but you 
need to change your kernel config. Unselect packet action and you should 
be able to choose a different policer.

Or you could try using tc filters instead of netfilter - I don''t know
if
it will be possible for what you want as I can''t see the rules that
mark.

> === 2 ==> 
> tcq ingress handle ffff: 
> tcq parent ffff: handle 10 htb 
> tcc parent ffff: htb rate 12mbit
> tcc parent ffff: htb rate 10mbit
> tcc parent ffff: htb rate 1mbit
> tcf parent ffff: protocol ip prio 1 fw 
> 
> I tricked tc into attaching a htb to the root qdisc. This gives no errors
> but also doesn''t seem to do anything. If you use tc show
qdisc|filter|class
> the qdisc,filters and classes are not even shown, so I guess it''s
borked
> (tc should have given an error that it won''t work).
> 
> =======
This has never worked if you want a queue on ingress you need to use IMQ 
(in the case that you need netfilter PREROUTING marks) or IFB (kernel >= 
2.6.16) but this will hook before netfilter - so no marks.

Andy.

On Sun, 2006-04-09 at 14:00 +0100, Andy Furniss wrote:
> Erik Slagter wrote:
> > Hi,
> > 
> > I am trying to do some simple ingress limiting based on fwmark. I know
> > the ability and sense to do INGRESS limiting is ehm... limited ;-) but
> > still I want to try it.
> > 
> > I tried several things.
> > 
> > === 1 ==> > 
> > tcq ingress handle ffff: 
> > tcf parent ffff: protocol ip prio 1 handle 1 fw police rate 12mbit
burst 10k drop
> > tcf parent ffff: protocol ip prio 1 handle 2 fw police rate 10mbit
burst 10k drop
> > tcf parent ffff: protocol ip prio 1 handle 3 fw police rate 1mbit 
burst 10k drop
> > 
> > This installs OK, but the filters are never called. The netfilter
stats
> > show the marks are set though. To make sure it''s not just the
tc stats
> > output that''s borked, I changed the bw limits to a rediculous
low value,
> > and indeed, no effect at all.
> > 
> There are two policers now the old one will work as you want but you 
> need to change your kernel config. Unselect packet action and you should 
> be able to choose a different policer.
Found it and deselected it. Now making new kernel...

The "old" policer is marked as "obsolete", so I guess it
will go away.

What am I supposed to replace it with, then?
> Or you could try using tc filters instead of netfilter - I don''t
know if
> it will be possible for what you want as I can''t see the rules
that mark.
It''s probably possible, but I already have quite a large set of
netfilter rules. I don''t want to make the whole thing even more
complicated by also adding lots of tc stuff, I''d rather have the
tc/iproute things as simple as possible.
 
> This has never worked if you want a queue on ingress you need to use IMQ 
> (in the case that you need netfilter PREROUTING marks) or IFB (kernel >=
> 2.6.16) but this will hook before netfilter - so no marks.
For IMQ I need to patch the kernel (feasible) and the netfilter tools
(not feasible :-() I just learned.

And you''re just telling me I cannot use IFB. Bummer. Anyway, if there
is
any simple (!) way to implement what I am searching for, I am happy.

I will try your "old policer version" suggestion asap.

Thanks for your help.


_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Erik Slagter wrote:
> 
> Found it and deselected it. Now making new kernel...
> 
> The "old" policer is marked as "obsolete", so I guess
it will go away.
> 
> What am I supposed to replace it with, then?
There may be a way in the future to get netfilter state with an 
ematch/meta data (I don''t know the detail Thomas Graf has mentioned
it).
> For IMQ I need to patch the kernel (feasible) and the netfilter tools
> (not feasible :-() I just learned.
I didn''t know there is a problrm with IMQ + netfilter.

Andy.

On Sun, 2006-04-09 at 14:00 +0100, Andy Furniss wrote:
> There are two policers now the old one will work as you want but you 
> need to change your kernel config. Unselect packet action and you should 
> be able to choose a different policer.
This indeed did the trick! Thanks!

Stupid that tc & kernel allow all of this, don''t give any sort of
error
but simply refuse to work.


_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

On Sun, 2006-04-09 at 14:42 +0100, Andy Furniss wrote:
> > The "old" policer is marked as "obsolete", so I
guess it will go away.
> > What am I supposed to replace it with, then?
> 
> There may be a way in the future to get netfilter state with an 
> ematch/meta data (I don''t know the detail Thomas Graf has
mentioned it).
Is there already a tc man page that reveals all of this :-(
> > For IMQ I need to patch the kernel (feasible) and the netfilter tools
> > (not feasible :-() I just learned.
> 
> I didn''t know there is a problrm with IMQ + netfilter.
You just told me ;-)

The IMQ handling is done before the netfilter handling...


_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

On Mon, 10 Apr 2006 14:38:10 +0200
Erik Slagter <erik@slagter.name> wrote:
> > I didn''t know there is a problrm with IMQ + netfilter.
> 
> You just told me ;-)
> 
> The IMQ handling is done before the netfilter handling...
 
That''s IFB, not IMQ. IFB is an intermediate functional block that
appeared in kernel 2.6.16. IFB is a device, IMQ is a iptables target
(and a device)

And IMQ is a kernel patch (and iptables has to be patched as well) while
IFB is in the mainstream kernel.

-- 
___________________________________________________________________
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.

+------------------------------------------------------------------+
| Richard Lucassen, Utrecht                                        |
| Public key and email address:                                    |
| http://www.lucassen.org/mail-pubkey.html                         |
+------------------------------------------------------------------+

On Mon, 2006-04-10 at 15:41 +0200, richard lucassen
wrote:
> On Mon, 10 Apr 2006 14:38:10 +0200
> Erik Slagter <erik@slagter.name> wrote:
> 
> > > I didn''t know there is a problrm with IMQ + netfilter.
> > 
> > You just told me ;-)
> > 
> > The IMQ handling is done before the netfilter handling...
>  
> That''s IFB, not IMQ. IFB is an intermediate functional block that
> appeared in kernel 2.6.16. IFB is a device, IMQ is a iptables target
> (and a device)
> 
> And IMQ is a kernel patch (and iptables has to be patched as well) while
> IFB is in the mainstream kernel.
Sorry for the mix-up.

Anyway, the result is the same.

Cannot use IMQ because patching iproute2 is not feasible, cannot use IFB
because it''s at the wrong location in the chain.

And the simple approach I wanted in the first place, now works.


_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

On Mon, 10 Apr 2006 15:51:47 +0200
Erik Slagter <erik@slagter.name> wrote:
> > That''s IFB, not IMQ. IFB is an intermediate functional block
that
> > appeared in kernel 2.6.16. IFB is a device, IMQ is a iptables target
> > (and a device)
> > 
> > And IMQ is a kernel patch (and iptables has to be patched as well)
> > while IFB is in the mainstream kernel.
> 
> Sorry for the mix-up.
> 
> Anyway, the result is the same.
> 
> Cannot use IMQ because patching iproute2 is not feasible, cannot use
> IFB because it''s at the wrong location in the chain.
You don''t need to patch iproute2 for IMQ, just iptables and the kernel.
IMQ lives well together with all other stuff AFAIK.
 
R.

-- 
___________________________________________________________________
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.

+------------------------------------------------------------------+
| Richard Lucassen, Utrecht                                        |
| Public key and email address:                                    |
| http://www.lucassen.org/mail-pubkey.html                         |
+------------------------------------------------------------------+

On Mon, 2006-04-10 at 16:10 +0200, richard lucassen
wrote:
> > Cannot use IMQ because patching iproute2 is not feasible, cannot use
> > IFB because it''s at the wrong location in the chain.
> 
> You don''t need to patch iproute2 for IMQ, just iptables and the
kernel.
> IMQ lives well together with all other stuff AFAIK.
Hmmm, if you mean the iptables program, then same story :-(


_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

On Mon, 10 Apr 2006 16:29:24 +0200
Erik Slagter <erik@slagter.name> wrote:
> On Mon, 2006-04-10 at 16:10 +0200, richard lucassen wrote:
> > > Cannot use IMQ because patching iproute2 is not feasible, cannot
> > > use IFB because it''s at the wrong location in the chain.
> > 
> > You don''t need to patch iproute2 for IMQ, just iptables and
the
> > kernel. IMQ lives well together with all other stuff AFAIK.
> 
> Hmmm, if you mean the iptables program, then same story :-(
You just create two extra .so files, that''s all. The patch works well
with iptables-1.3.5.

-- 
___________________________________________________________________
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.

+------------------------------------------------------------------+
| Richard Lucassen, Utrecht                                        |
| Public key and email address:                                    |
| http://www.lucassen.org/mail-pubkey.html                         |
+------------------------------------------------------------------+