Netflow exports session data. Probably it will not export data about sessions that were never completely established.
This is not correct. NetFlow will account for every IP packet passing through the monitored interface(s). It will not account for non-IP traffic though.
NetFlow does not understand 'Established connections'. It understands Flows. A flow consists of
packets with the same values:
https://en.wikipedia.org/wiki/NetFlow
A network flow can be defined in many ways. Cisco standard NetFlow version 5 defines a flow as a unidirectional sequence of packets that all share the following 7 values:
Ingress interface (SNMP ifIndex)
Source IP address
Destination IP address
IP protocol
Source port for UDP or TCP, 0 for other protocols
Destination port for UDP or TCP, type and code for ICMP, or 0 for other protocols
IP Type of Service
If an active flow is finished (only for TCP) it will export it to the NetFlow Collector. If an active flow exceeds its configured 'Active Timeout' it will be exported to the NetFlow Collector.
If the router doesn't see any packet for an active flow past its configured timeout it will consider it inactive and eventually will export it to the netflow collector (based again on the configured timeout values).
The router will output a flow record when it determines that the flow is finished. It does this by flow aging: when the router sees new traffic for an existing flow it resets the aging counter. Also, TCP session termination in a TCP flow causes the router to expire the flow. Routers can also be configured to output a flow record at a fixed interval even if the flow is still ongoing.
NetFlow on Mikrotik has a bug when the bytes counter for a single flow exceeds the 32bit unsigned value (~4.2billion bytes - ~4Gbytes) it will wrap the counter back to zero (0) without exporting the flow first. This results in missing traffic when the NetFlow collector processes the received flows.
I've documented this problem here
http://forum.mikrotik.com/viewtopic.php ... ow#p509137
No solution yet.
IPFIX on v6.36rc also
has bugs. I haven't tried 6.36 stable yet.
I am not sure if this has anything to do with the problem described by cmurrayis since usually DDoS attacks consist of many many packets and not long flows (that would exceed the 32bit octet counter).
When you want to monitor interface traffic, I suggest you do that instead of relying on lower-level detail like Netflow.
(with SNMP you can retrieve interface bytes in/out counters and when you do that once a minute you can compute
mean bitrate from that. this is what traffic graphing software usually does)
You cannot do IP Accounting/Billing using SNMP on a single interface. It's useful for monitoring purposes but not for Billing.
NetFlow with a solution like
pmacct will account for each IP's traffic allowing to bill your clients based on their IP(s). It's really powerful and granular (while snmp is not). One downside is that NetFlow accounts for the ethernet payload data, not the ethernet headers. So there will be a small discrepancy between NetFlow and SNMP but this can be calculated/added afterwards.
When you have a trunk interface as cmurrayis has you cannot account for
each client's traffic, only an aggregate of all clients behind that interface.
cmurrayis is it possible that your netflow collector drops some netflow packets thus accounting for less traffic than what's actually passing through?
NetFlow packets are UDP so they are 'fire and forget'. If something goes missing it's not being resent.
Since this is a DDoS it will cause netflow to export myriad of inactive flows every X seconds, so it stands to reason that your collector may not be processing all the flows properly (dropping udp packets)
