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 10.1.7.5 to 66.186.184.194, 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. 

Summary
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.

Michael Patterson
Scrutinizer Product Manager
Click to download Scrutinizer now!
Join NetFlow Developments on Linkedin.com

Tags: Flexible NetFlow, netflow collection engine, NetFlow Collector, netflow deduplication, netflow exporting, Network Traffic Analysis

This entry was posted on Tuesday, August 17th, 2010 at 5:13 am and is filed under NetFlow, NetFlow Analyzer. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.