ipfw counters for tables
smithi at nimnet.asn.au
Mon Jul 23 19:31:34 UTC 2012
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 at 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 );
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.
More information about the freebsd-questions