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-...@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 packetsbytes
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 16100583003060562 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
16100583003060562 deny *counttable* log logamount 20 ip from
table(1) to any in recv ng0
5300 10.5.0.1/32
300562 10.5.0.7/32
8000 6 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
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
