Hi Anton,
On Friday, 23. January 2015 11:24:46 Anton Khalikov wrote:
> 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?
it's good to know there are still some other ipt_ACCOUNT users besides us :D
Regarding IPv6 support: As Neal pointed out, the current data structure
wouldn't work out of the box.
For our personal use case we developed the following:
- Develop nfacct together with Pablo Neira Ayuso.
That is used for "global" uplink accounting.
- Use conntrack accounting to replace ipt_ACCOUNT. The data
is already there and it's IPv6 ready ouf of the box.
64bit counters as a bonus, which comes more of a concern
with fast 1Gbps / 10 Gbps / 100 Gps (soon) network cards.
We identified some bottlenecks when using conntrack accounting
and adressed those:
- Reliable transfer between kernel and userspace.
No accounting data is to be lost.
- Poll request of all non-zero counters + reset counters to zero
like in ipt_ACCOUNT
AND
- Proactive, async dump of connection status in the kernel
when a connection finishes. Otherwise it might be lost
if it was not in the previous dump.
- Filtering by marks on the kernel side. So only "interesting"
traffic can be queried and transferred efficiently.
The code for that has been done by Pablo Neira Ayuso.
Here's an example code showing that in action:
https://git.netfilter.org/libmnl/tree/examples/netfilter/nfct-daemon.c
I think the new transfer methods also made it into ulogd2.
There's also an optimization done by Patrick McHardy to have memory mapped
(mmap) transfers for netlink. That's the underlying transfer mechanism for
the accounting data dump. We haven't tried / benchmarked that yet.
Anton, you mention conntrack breaks under DDoS attacks.
What box was used to handle the traffic and what
kind of packet traffic did you experience? SYN flooding?
Cheers,
Thomas
--
ipt_ACCOUNT - see http://www.intra2net.com/en/developer/ipt_ACCOUNT for details.
To unsubscribe send a mail to ipt_ACCOUNT+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx
|
