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 -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
