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: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?slrnfu1oao.21d2.vadim_nuclight>