On Friday, January 23, 2015 01:24:46 AM Anton Khalikov wrote:
> Hello everyone
>
> I wonder if there are any plans to add ipv6 support to ipt_ACCOUNT? I
> know there is shiny new nfacct tool but it is useless when it comes to
> task to count traffic on per host basis on large networks. And also
> there is conntrack, but again, it becomes useless and even bottleneck
> during DDoS attacks while ipt_ACCOUNT never failed. ipt_ACCOUNT stayed
> alive and didn't eat CPU too much even when 1Gbps and 600kpps DDoS
> happened. So at the moment there is no high performance and low CPU
> usage substitution for ipt_ACCOUNT from my point of view. You guys did a
> great job and thank you for that. Would you like to continue?
As I recall from looking at it and my recent experiences, iptACCOUNT will
require a serious rewrite to handle IPv6. It uses a kernel page to store stats
for an IPv4 /24 (bytes & packets; in & out). Since IPv6 addresses are
typically anywhere within a /64, that method becomes unworkable (unthinkable,
really).
Another problem is that it uses 32-bit counters. They roll over in about 34
seconds at saturated gigE speeds. At 10G speeds, they can roll over in barely
more than 3 seconds.
The last problem I can readily identify is that IPv6 uses
- link local addresses
- a prefix for DHCP-assigned addresses
- a prefix for SLAAC addresses
- possibly a prefix for private addresses
That's potentially four addresses per NIC that must be tracked.
I haven't yet thought of a way to modernize iptACCOUNT and remain efficient
That bolt of lightning over my head hasn't flashed on yet.
I seem to recall reading about ipset being enhanced to track per-address
stats. It might be efficient if it was written like the rest of ipset.
Neal
--
ipt_ACCOUNT - see http://www.intra2net.com/en/developer/ipt_ACCOUNT for details.
To unsubscribe send a mail to ipt_ACCOUNT+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx
|