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 analysis. First 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 184.108.40.206 and then made a quick HTTP TCP connection from my PC (10.1.7.5). 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 220.127.116.11 shows up as 18.104.22.168). 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. 🙂