Introduction
I spent some time ago comparing packet traces to Cisco NetFlow using our network bandwidth monitoring tool ‘Scrutinizer’.  I setup 3 scenarios where I captured the actual packets with Wireshark and captured the NetFlow datagrams with our NetFlow collector.  In this 3 part series, the details from these three labs will be explained:

* FTP – NetFlow traffic analysis
* HTTP – NetFlow reporting
* VoIP – NetFlow analyzer

In the first NetFlow lab we did an FTP Comparison.  Here are the steps I used in the study:

* I started WireShark
* I logged in and FTP’d a file
* I logged out
* I stopped WireShark
* 6 Ingress Flows represent 2221 packets
* 6 Egress Flows represent 1123 packets

Ingress NetFlow
First I reviewed the ingress NetFlow received by Scrutinizer from the Cisco router.  I counted 2221 packets and compared this to what Wireshark displayed.  Click on the image below to expand.

Notice below that Wireshark also displayed 2221 packets in the same direction.

Egress NetFlow
Next I took a look at the outgoing packets in our NetFlow collection tool. We counted 1123 packets and once again I compared this to Wireshark.

Notice below that Wireshark also displays 1123 packets.

Now lets dig into the details of the frames and find out what you do and don’t get with NetFlow analysis. We already know that we see everything with a packet trace.

NetFlow details Vs. a Packet Trace
There are too many differences to point out between NetFlow and a packet trace even in a 3 part blog so I decided to pick out an obvious one: passwords.  Below you can see that Wireshark displays the password I used in the FTP transfer.

Now lets take a look at what details we get from our NetFlow report. Below I took at series of screen captures to display every NetFlow field exported by our Cisco router.

Note the sourceTransportPort and destinationTransportPort: depending on which one is random, I found that the Cisco ASA and other firewalls will change this number.  Expect this behavior when viewing netflow from these devices.

You can see above that although it looks like a lot of data, it is only about ~25 fields and none of them displays the password.  Even the TCP flags are aggregated together in NetFlow.

Summary
The lesson I try to point out in the FTP – NetFlow traffic analysis lab is that NetFlow is intended to be an aggregation technology and not a packet analysis technology.  I think there will always be this line in the sand.

  • Packet trace analysis : verbose, all the details, less high level information
  • NetFlow traffic analysis : aggregated, summary details, more high level information

The future of NetFlow has plenty of opportunity without overlapping with packet capture. Lets move onto part 2 of this series.

February 23rd, 2013 updateNetFlow Vs. Packet Analysis found in Cisco Communities

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

Big Data

Sankey Flow Graph

One of the greatest benefits of NetFlow collection for traffic analysis, is we’re provided with the ability to visualize the…

Leave a Reply