Re: ipt_ACCOUNT 1.15 released

[Thomas Jarosch <thomas.jarosch@intra2net.com>]

On Thursday, 16. April 2009 20:29:46 Thomas Jacob wrote:
> Also, in order to make IPv6 accounting practical, I would probably add
> some sort of subnet accounting along the following lines.
>
> -j ACCOUNT --network 1234:4567::/32 --account_mask /64
>
> which would only account packets in --network, and count data
> for a whole subnet instead of a single IP, as assigning single
> IPv6 addresses to customers is kind of silly in an ISP environment.
>
> To collect data for single IPs just use --account_mask 128.

Well, for IPv4 you can alreay use "--src 172.16.0.0/16"
and then do "-j ACCOUNT --addr 0.0.0.0/0" to merge
the complete subnet into one single IP address.

This should be possible with IPv6, too.

> Another idea, possibly useful from an ISP perspective, might be
> to only start the counters (i.e. add the entry to the hash bucket) if
> packets with the IP/subnet have arrived from a certain direction first.
>
> This way, your tables don't overflow with all the IP scans
> from the Internet.

Maybe a conntrack "state" match can help here?

> approaches taken by ipt_ACCOUNT or ipt_account. All I am interested in
> is a byte counter per target IP/subnet that can be queried once a day
> so that I know who is consuming my bandwidth. Something that passes
> each connection track to user space doesn't look so good for that.
>
> But maybe I am wrong about this, I  haven't actually tried to use it.

Me neither :-) IIRC the problem in the past was that ulogd (v1) could lose 
packets when the userspace <-> kernel communication queue was not processed
as fast as new packets arrived. Though my memory on this is quite blurry...

Thomas