From owner-freebsd-questions@FreeBSD.ORG Mon Jul 23 19:31:34 2012 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 401AB106564A for ; Mon, 23 Jul 2012 19:31:34 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id 9A01C8FC0A for ; Mon, 23 Jul 2012 19:31:33 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id q6NJVVTb098991; Tue, 24 Jul 2012 05:31:32 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Tue, 24 Jul 2012 05:31:31 +1000 (EST) From: Ian Smith To: Eugen Konkov In-Reply-To: <1443021317.20120723131347@yandex.ru> Message-ID: <20120724044804.X37097@sola.nimnet.asn.au> References: <20120722120042.DC8371065678@hub.freebsd.org> <20120723144551.K37097@sola.nimnet.asn.au> <1443021317.20120723131347@yandex.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-questions@freebsd.org Subject: Re[2]: ipfw counters for tables X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 19:31:34 -0000 On Mon, 23 Jul 2012 13:13:47 +0300, Eugen Konkov wrote: > ????????????, Ian. > ?? ?????? 23 ???? 2012 ?., 8:27:50: > IS> In freebsd-questions Digest, Vol 424, Issue 10, Message: 10 > IS> On Sun, 22 Jul 2012 14:55:46 +0300 Eugen Konkov wrote: > IS> Hi Eugen, > > >> I use ipfw tables to allow host to access to internet. > >> is there counter for matched packets/bytes for table entry like for > >> ipfw rule? > >> > >> #ipfw show 901 > >> rule packets bytes > >> 00901 302271108 27717115967 allow ip from 10.10.1.3 to any > >> > >> #ipfw table 7 list > >> ---table(7)--- > >> 10.7.60.41/32 100 > >> > >> No counters here ((( > > IS> No, there are no individual counters for matched entries in tables. > IS> Apart from extra space cost, the accounting time cost would be huge; > IS> lookups are fast but updating radix trees per match would be very slow. Sorry, I was likely wrong about time cost. Once you find an entry it's there for the updating, but you will have to use write locking on table entries, perhaps they're just read locked for lookups now? I haven't read ipfw for years. Adding new table entries is what's really slow. > IS> Also, a table may be referenced in multiple rules, or even twice in the > IS> same rule, so what could such a count really indicate? I guess you'll know how you want to use them, so objection overruled :) > IS> Of course, counts for matching the table are in the rule/s concerned: > > IS> 16100 58300 3060562 deny log logamount 20 ip from table(1) to any in recv ng0 > IS> 16200 4449 226060 deny log logamount 20 tcp from > IS> table(25) to any dst-port 25,110 in recv ng0 setup > IS> 23000 45 2700 allow log logamount 100 tcp from > IS> table(22) to w.x.y.z dst-port 22 in recv ng0 setup > but if lookup function will return matched entry, then calling rule > may update appropriate counter. Sounds like a good experiment in your local codebase, with some tests for speed and space costs? 64 bit counters? Might as well store the 32 bit timestamp too, just like the rule updating code does, I guess? > matchedentry= lookup_table( PACKETDATA ); > updatecounter(matchedentry); Code it up :) Post to freebsd-ipfw@ and see what Luigi and crew say. > #ipfw show 16100 > 16100 58300 3060562 deny *counttable* log logamount 20 ip from table(1) to any in recv ng0 > 50000 3000000 10.5.0.1/32 > 300 562 10.5.0.7/32 > 8000 60000 10.5.0.2/32 > > will this be slow? Well, display is from userland ipfw, where slow isn't very relevant. It'll be what it adds to kernel code and memory requirements that may matter. I'm not sure how you could make this feature optional, short of a kernel config option .. but what do I know? > IS> Myself, I'd be more interested in a last-match timestamp than a count > IS> for table entries, but that won't happen either for the above reasons :) I often use ipfw -t show (or -ted show) so I guess with -t or -T it may show last access timestamps along with packet/byte counts too, as usual? I'll be happy to test it when you've got working patches. cheers, Ian