Have you ever been drilling in on a host in your NetFlow or sFlow analyzer hoping to get the kind of juicy details you get with a packet analyzer like Wireshark?  If so, you have felt the disappointment that comes about when the details simply aren’t there.   Why does this happen and what can be done about it?

The Limitations of NetFlow
NetFlow is an aggregation of traffic.  For example, if my PC sends 800 packets to John’s PC and John’s PC sends 20 back to me.  This becomes two flows.  A single NetFlow v5 packet can contain up to 30 flows (NetFlow v9 contains up to 24).    It is easy to understand how a single NetFlow UDP datagram can represent over a dozen hosts communicating over the network with thousands of packets.   NetFlows aggregation is pretty good.  Alas, it has short comings as well.

What is in NetFlow v5
Because of NetFlow’s aggregation, we only get a few details.  For   example:

* Source and Destination Interfaces
* Source and Destination Ports
* Source and Destination Autonomous System
* Source and Destination Address Prefix Mask
* Protocol (UDP, TCP, etc.)
* Total Packets, Total Octets
* Start and end times of the flow
* TCP flags
* ToS (i.e. for DSCP)
See more on V5 & V9  NetFlow packet formats

Compare NetFlow to Wireshark

Q: What if you want the raw packets like you get in Wireshark.  Can you get the details to and from a host using NetFlow?
A: You can’t get all of the same details but, if you are using Scrutinizer NetFlow & sFlow Analyzer you can get a list of all the flows to and from the host as shown below. This is about as good as it gets with NetFlow and Scrutinizer can do it.

Raw NetFlow in Scrutinizer NetFlow & sFlow Analyzer

This is just the beginning of what it takes to display NetFlow in HD (High Definition).

Mike Patterson author pic

Michael

Michael is one of the Co-founders and the former product manager for Scrutinizer. He enjoys many outdoor winter sports and often takes videos when he is snowmobiling, ice fishing or sledding with his kids. Cold weather and lots of snow make the best winters as far as he is concerned. Prior to starting Somix and Plixer, Mike worked in technical support at Cabletron Systems, acquired his Novell CNE and then moved to the training department for a few years. While in training he finished his Masters in Computer Information Systems from Southern New Hampshire University and then left technical training to pursue a new skill set in Professional Services. In 1998 he left the 'Tron' to start Somix which later became Plixer.

Related

Leave a Reply