Open source Netflow analysis for monitoring AS-to-AS traffic

Fri Mar 29 00:15:03 UTC 2024

Tom Beecher wrote on 28/03/2024 18:35:
> Fundamentally I've always disagreed with how sFlow aggregates flow data 
> with network state data.

"can aggregate" rather than "aggregates" - this is implementation 
dependent and most implementations don't bother with it.

Overall, sflow has one major advantage over netflow/ipfix, namely that 
it's a stateless sampling mechanism.  Once you have hardware that can 
reliably pick out one in N frames, the rest of the protocol is 
straightforward enough, which means that it's cheap to implement in 
hardware. If you're ok with 1. sampling and 2. the set of data that 
sflow provides, then sflow is great.

Netflow / ipfix, on the other hand, assumes that it's learning about 
flow state. For this, you need both a flow lookup mechanism and flow 
storage memory. Usually the flow lookup mechanism is implemented using 
the same technology as the packet forwarding lookup mechanism due to 
performance requirements, i.e. expensive. Similarly, the storage 
mechanism needs to be fast, which often precludes being large. Often 
both the lookup and storage mechanism are linked, e.g. tcam.

Obviously, not all netflow/ipfix implementations implement flow state, 
but most do; some implement stateless sampling ala sflow. Also many 
netflow implementations don't export mac address information, which 
limits usefulness in certain situations. But this is an implementation 
gap rather than a protocol weakness.

Tools should be chosen to fit the job. There are plenty of situations 
where sflow is ideal. There are others where netflow is preferable.

Nick