This is part 3 of a 3 part series.  Part 1 and part 2 covered other topics.  In the third NetFlow lab we studied the traffic from a VoIP connection.

Here are the steps I used in the study:

  • I started WireShark
  • I started iaxLite
  • I made a call
  • The other end picked up
  • I hung up
  • I closed iaxLite
  • I stopped WireShark
  • 1 Ingress Flow represents 1364 UDP packets
  • 1 Egress Flow represents 1364 UDP packets


Wireshark Packet Trace
First I looked at the traffic from my PC to the PBX using Wireshark.  This very short call created 1364 packets!  I wonder how many flows will be exported?

Click on the image below to expand.

We then looked at this traffic in our NetFlow, sFlow and IPFIX reporting tool ‘Scrutinizer’.  I setup a filter for to, you can see it on the left hand side of the screen capture. Notice that the NetFlow collector only received 1 flow from the Cisco router and the packetDeltaCount is exactly the same as Wireshark 1364.  If the flow had gone through multiple routers and the netflow collection engine had performed deduplication, I wonder if the number would be exact? I doubt it.

A word on NetFlow Deduplication
We perform deduplication within our Flow Analytics engine.  This allows us to avoid triggering multiple alarms as the exact same packets traversed several netflow exporting routers. We also use deduplication to show the top hosts, conversations, protocols, domains, countries, etc. across multiple routers and switches so there are practical applications for it.  However, it is all limited to our Flow Analytics module.  In the above scenario, the averaging of NetFlow in deduplication would not have been appropriate as sometimes network traffic analysis requires precise data. Also, many service providers feel that NetFlow billing requires accurate data as well.  Don’t get me wrong, averaging is good it just isn’t accurate. Lets go back to wireshark and see what the PBX was transmitting.

After configuring my filter, I noticed that the PBX had sent exactly the same amount of packets back to my pc: 1364.  Interesting.

Now lets take a look at this using the NetFlow collector. In Scrutinizer I was able to leave the filter on the left and just toggle to Outbound at the top.  Exactly the same number: 1364.

In this lab on VoIP – NetFlow analyzer, we saw tremendous aggregation on the part of NetFlow.  I think this final lab enforces what was stated in the summary of lab 1:

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

Although the above could change, only time will tell.  Keep your eye on the horizon by paying attentiog to Cisco Flexible NetFlow (FnF) and the evolving standard IPFIX.

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