Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 19 Mar 2008 09:48:08 +0000 (UTC)
From:      Vadim Goncharov <vadim_nuclight@mail.ru>
To:        freebsd-ipfw@freebsd.org
Subject:   Re: kern/80642: [ipfw] [patch] ipfw small patch - new RULE OPTION
Message-ID:  <slrnfu1oao.21d2.vadim_nuclight@hostel.avtf.net>
References:  <200803122100.m2CL0t7V088955@freefall.freebsd.org> <slrnfthsg7.dgk.vadim_nuclight@hostel.avtf.net> <20080313094356.GA9219@tin.it> <47DF72A3.4030502@yandex.ru>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
Hi Andrey V. Elsukov! 

On Tue, 18 Mar 2008 10:43:31 +0300; Andrey V. Elsukov wrote about 'Re: kern/80642: [ipfw] [patch] ipfw small patch - new RULE OPTION':

>>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=80642
>>> Yes, this is useful, but some minor changes are needed, I think. First, rename
>>> it to "bytelimit" or somewhat. Second, allow this to use tablearg and possibly
>>> ability to reference a counter to corresponding dynamic rule, to allow this to
>>> act for a specific IP or connection without need to write many rules. Third,
>>> add packet counter as well. That's all possible with one opcode, though...
>> 
>> if anyone post an updated patch, i'll commit it.
> So, updated patch is here:
> http://butcher.heavennet.ru/patches/kernel/ipfw/ipfw_counterlimit.diff

> Now this option divided into two "counterlimit-bytes" and
> "counterlimit-packets".
> Rules example:
> add allow ip from any to 10.0.0.1 counterlimit-bytes 100M \
> 	in recv external_if
> add allow ip from any to 10.0.0.1 counterlimit-pakets 50 \
> 	in recv external_if

> About Vadim's prepositions:
> 1. tablearg: it's possible, but now we use u32 argument in
> tables, but counterlimits are 64-bits values. First of we
> should extend our current table argument to 64 bit.

I think this should be done - limit of 4G bytes is still useful for many
users (and 4G packets even more), and others could wait until table argument
will be extended to u64, which will break ABI

> 2. dynamic rules: i think it should be implemented as extension
> to current O_LIMIT opcode or something similar.

No, not there. Dynamic rules should be massively redone, with some other
things, I'll write a big proposal (possibly a SoC candidate) in a day or two.
What I'm trying to propose is generality - it allows more users to do
different things, and if you do something specific, you're limiting some of
them. For example, how do you propose toi change dynamic rules like O_LIMIT ?
I suppose that will allow only one action per dynamic rule only, not telling
about the ABI.

And what I am proposing is a using several checks: remember that
dynamic rule in fact jumps to action part of parent rule, which can be skipto.
Imagine a server with two interfaces to different providers, which must route
replies to requests to appropriate interface. In pf you would specify reply-to
and nothing more, but in ipfw you can make a whole block of checks for each
dynamic rule! Then, plain emulation of reply-to looks like this:

ipfw add 1 check-state

# ...some checks for outgoing and incoming firewalling here

ipfw add 100 skipto 300 tag 1 in recv $ext_if1 keep-state
ipfw add 200 skipto 300 tag 2 in recv $ext_if2 keep-state
ipfw add 300 allow { recv $ext_if1 or recv $ext_if2 }  # reqs from outside
ipfw add 400 allow in recv $int_if  # answers on internal pass
ipfw add 500 fwd $gw1 tagged 1      # the only left are answers on ext iface,
ipfw add 600 fwd $gw2 tagged 2      # send them to appropriate gateway

Here every matched dynamic rule will jump to rule 300, and will be checked till
rule 600. Now, assume that you want to limit bandwidth for "long-playing"
downloads from your server? So you simply insert a pipe rule to that block:

ipfw add 450 pipe 1 not counterlimit dyn-bytes 1000K

and all outgoing short-lived connections will be unaffected, and those
downloaded more than about 1 meg will be shaped.

It is useful not only for shaping, but, for example, when you are sending
packets to netgraph for L7 check with ng_bpf+ng_tag and know that check is
expensive and you are interested only in first packets of connection, others
are meaningless.

So, that dynamic rule checking is assumed to be plain q = lookup_dyn_rule(...);
if (q->bcnt) ...

> Also i have question about my current implementation. Does it
> needed to have ability of "humanized" printing of limits, which
> was implemented before?

It could be desirable to think about global ipfw option to print "humanized"
values not only in this option, but several others too. Just like hostnames,
IP addresses in tableargs, etc.

-- 
WBR, Vadim Goncharov. ICQ#166852181       mailto:vadim_nuclight@mail.ru
[Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight]




Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?slrnfu1oao.21d2.vadim_nuclight>