Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 24 Jul 2012 05:31:31 +1000 (EST)
From:      Ian Smith <smithi@nimnet.asn.au>
To:        Eugen Konkov <kes-kes@yandex.ru>
Cc:        freebsd-questions@freebsd.org
Subject:   Re[2]: ipfw counters for tables
Message-ID:  <20120724044804.X37097@sola.nimnet.asn.au>
In-Reply-To: <1443021317.20120723131347@yandex.ru>
References:  <20120722120042.DC8371065678@hub.freebsd.org> <20120723144551.K37097@sola.nimnet.asn.au> <1443021317.20120723131347@yandex.ru>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
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 <kes-kes@yandex.ru> 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



Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?20120724044804.X37097>