Skip navigation
All People > Michael Patterson > Michael Patterson's Blog > 2013 > December
2013

If you are looking to obtain deeper application performance monitoring with IPFIX or NetFlow, this post should give you some ideas to think about. Traditional NetFlow only delivers details on the addresses, ports, bytes, packets and a few other details about the applications running on your network.  It’s better than nothing, sort of like sFlow but, you can do so much more with many IPFIX exports. 

 

DPI and Round Trip Time

What I want to share today is how to gain access to deeper application performance metrics.  We’ve posted over a dozen blogs about NBAR (DPI) and Performance Monitoring (i.e. Medianet) which means you are probably familiar with the ability to gain details like round trip time, jitter, packet loss, URLs and packet size.  These details are just the beginning.

 

IPFIX is À la carte

IPFIX to some vendors equates to À la carte.  In other words, what do you want?  Today, this is of course means within the constraints of what the hardware is able to export.  Sound awesome?  Well, before you go and enable every possible metric, consider this.  The more details you want the packets to match on, the less likely they will end up being part of the same flow.  For example, if hosts A and B communicated over 8 different ports, that could result in 8 flow records.  If you remove ports from the tuple, then you only get 1 flow record.  If you add URL, you might end up with more than 8 flow records.  And so it’s a tradeoff. The more details, the less aggregation which means more flows and more overhead for the router and the network. Be careful what you ask for.

 

Cisco AVC

Cisco has compiled many of their next generation NetFlow exports into something called Cisco Application Visiblity and Control (AVC).  Instead of using NetFlow to export the details, they used IPFIX.  Why? Because IPFIX is the official IETF standard and it supports variable length strings (e.g. URLs) among other things.

 

Average Transaction Duration

We started working with these exports earlier this year and were excited to learn about the average transaction duration metric.  Our network traffic analysis solution sums up this metric for selected records and divides the value by the number of transactions.  What you end up with is average length of completed transactions.  Check it out in the screen capture below.

 

http-host-transaction-delay.png

 

Above you can see that in the last 24 hours, whenever 10.12.1.47 connected to fcs.dell.com the average transaction duration was 235.42 seconds.  This is just the beginning.  I could drill in and find out how many flows were involved, the application, the packet retransmits, etc.

 

How does Cisco determine this metric?  All transactions must have the same 5 tuple and there are two ways a transaction can end:

  • Flow Ends or times out
  • Client starts a new transaction on the same 5 tuple (checks time stamps)

 

Update Your Flexible NetFlow Configuration

To export this metric, make sure you enter the following in the Flexible NetFlow configuration:

Collect connection transaction duration {sum, min, max}

 

We noticed a whole bunch of new and exciting metrics useful for deeper application performance monitoring.  For example, you can also export the TCP Window-size:

collect transport tcp window-size [minimum|maximum|sum]

 

Expect Application Visibility and Control to cause some significant growth in the flow monitoring market.  Many customers are clamoring for this type of visibility but, they may need to upgrade IOS on the router.  You can also expect the types of IPFIX exports to become more diverse and even start to rival what is possible with single location packet analysis.

 

Download our “Flow Based Approaches in Network Management” white paper that we co-authored with Cisco.