I think I’ve explained this enough times to justify a blog.  🙂  The topic of TCP Flags and NetFlow has come up a few times in technical discussions regarding NetFlow collection and analysisFirst of all, Cisco NetFlow is not packet analysis nor is it intended to be at this time.  If anything, some feel it is intended to augment the use of packet analyzers.  In other words, it often allows you to solve problems with a more high level view before  busting out a packet analyzer like Wireshark.  And since NetFlow is inherently distributed, it allows you to capture aggregated packet information on nearly every link of the network.  This of course depends on whether or not your router and switches support NetFlow, sFlow, IPFIX, jFlow, NetStream, etc.

You can see in the NetFlow report below that I pinged a server and then made a quick HTTP TCP connection from my PC (  Notice the two flows below, the first is the HTTP TCP connection and the second is the ICMP ping.  Click to expand the image.

The HTTP connection generated 5 packets in one direction as shown in the Wireshark packet capture below.  All 5 have to do with the HTTP TCP connection as I filtered out the ICMP frames.  In my haste, I cut off the final ‘80’ of the source IP address (i.e. notice below that shows up as   I outlined the TCP flags of SYN, ACK, FIN and PUSH in three of the packets.

On top of the screen capture above is a smaller window at the bottom where I outlined the TCP flags that were set in the flow.  Notice to the left that the packetDeltaCount is 5. What the router did is OR the flags together, total the bytes and packets and then export it as a single flow inside a NetFlow datagram.   I’ve seen a single flow represent thousands of packets.  I hope this helps others understand how NetFlow ORs TCP flags together.

Don’t you just love this stuff. 🙂

Mike Patterson author pic


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.


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