cancel
Showing results for 
Search instead for 
Did you mean: 
Martin_Duke
Legacy Employee
Legacy Employee

I'm pleased to announce that F5® TMOS® 12.1 is the first release to contain our TCP Analytics package. If you would like to measure how well TCP is delivering application data, perform A/B testing, or get diagnostic help for slow data delivery, this tool is a new and powerful way to do those things. TCP Analytics works with virtual servers that use either a TCP profile or a FastL4 profile.

What stats are available?

We're collecting several different statistics, some of them conventional TCP metrics and some of them brand new concepts. BIG-IP collects statistics over five minute intervals and then reports them through our AVR (Application Visibility and Reporting) module.

  • RTT Minimum, Mean, and Maximum measures the best-case, worst-case, and average delay (Round Trip Time, or RTT) experienced by packets. Although packet delay is meaningful to users in its own right, if the mean RTT is closer to maximum than minimum RTT, it's an indication router queues in the path are filling up. This congestion might be due to cross traffic, or caused by the profile settings on your BIG-IP.
  • RTTVAR Mean is the mean value of the "RTT Variation," which is a concept defined in the TCP specification. RTT Variation is a close analogue of the statistical variance but is easier to compute. The RTTVAR is a measurement of the variation in delay, or "jitter", that your applications experience. High jitter can have all sorts of negative consequences, but is most damaging to streaming applications where sudden jumps in latency deliver packets too late given the amount of buffered audio or video.
  • Goodput is the total amount of data delivered to the upper layer, which might be SSL, HTTP, or some other application. This is the aggregate goodput for the set of connections you choose to display, not the goodput experienced by a particular connection. In other words, if there are more connections there is usually more goodput. The definition of goodput specifically excludes data that TCP retransmits or cannot deliver due to gaps in received packets.
  • Connections Opened and Closed; Packets Sent, Received, and Lost are self-explanatory. TCP Analytics measures lost packets by tracking packet retransmissions. In isolated cases, retransmissions turn out to be unnecessary, but Analytics will report the packet as lost anyway.
  • Mean Connection Time measures the average time from completion of the three way handshake to the remote host's acknowledgment of the BIG-IP FIN flag, unless an iRule causes collection to start late or finish early.
  • Delay State Analysis is an attempt to answer the question "why is my TCP so slow?". It divides the entire life of a TCP connection into a total of 10 states based on why the connection is sending (or, more accurately, not sending) data at any given time. By reporting the time connections spend in each state, users can immediately see what the principal causes of delay are. In some cases, users can easily address these causes by tuning their TCP profile. In other cases, the root cause is a client, the network path itself, or an application delay outside the scope of TCP. (Delay State Analysis is not available with FastL4 profiles.)

Aggregate stats aren't that useful to me. How can I look at specific sets of connections?

Many BIG-IPs deal with millions of connections at a time, so storing statistics for every connection individually uses a lot of memory. However, the AVR engine is designed to hash relevant connection attributes and attach it to its data storage, so that users can pull out statistics for particular subsets of data.

In the TCP Analytics profile you attach to a virtual, you decide what connection attributes you want to store. We don't track them all automatically, because in many cases a BIG-IP with many connections and storing all attributes will run into memory limitations and lose some attribute granularity.

The connection attributes available are virtual server, IP Address or /24 IP subnet address, nexthop MAC address, geolocation, and whether the connection is clientside or serverside.

In addition, you can use the power of iRules to be more selective. First of all, you can turn on and off statistics collection via iRule, meaning you can collect stats only for connections that meet specific conditions laid out in the iRule. Secondly, iRules can attach an arbitrary string as an attribute. In other words, you can create arbitrary connection categories based on any iRule logic you like, and then display separate statistics for those categories. For example, you could separate download connections out by file size and display the stats for them separately.

This is great. How do I get started?

There are four main steps:

1) Provision AVR on your BIG-IP under System > Resource Provisioning. If you are licensed for LTM, you are licensed for AVR.

2) Create a TCP Analytics Profile.

3) Attach the TCP Analytics Profile to one or more virtual servers.

4) Watch the stats come in!

There are many more details at the online help for the product.

Obviously, there are many nuances we could explore in this space. Based on your feedback, I may dive into those nuances in a future article. Until then, enjoy!

Comments
Amanpreet_Singh
Cirrostratus
Cirrostratus

I must say this is a nice explanation of feature.

 

Sam_Novak
Nimbostratus
Nimbostratus

A very nice article indeed! I know in the AVR documentation is mentions that there can be a performance hit when turning on analytics; is that also the case for TCP analytics? If so, how much of a hit are we talking about? I currently have 99 virtual servers, most seeing a little less than 100K a day; would having TCP analytics, or HTTP analytics for that matter, make a noticeable impact on the performance from a client perspective?

 

Martin_Duke
Legacy Employee
Legacy Employee

It obviously depends on many factors, but in our experience working with it the CPU and memory hit was less than 10%. Whether that would be noticeable for your clients depends on the hardware you have and how hard each connection works the BIG-IP.

 

Also, the more you refine your statistics collection (e.g. turning it on only by iRule) the less of a performance impact there will be.

 

smouzakis
Nimbostratus
Nimbostratus

Is it possible to calculate packets per second/source ip address?

 

Martin_Duke
Legacy Employee
Legacy Employee

Each data point, under default settings, represents 5 minutes of time. So taking the of packets for an IP address allows you to easily find packets/second.

 

I don't have AVR provision so look like i have to do that first, does it required Reboot ? or re-registration of license key to F5 network?

 

Is there any performance issue to do TCP analysis?

 

Martin_Duke
Legacy Employee
Legacy Employee

You don't have to mess with the licensing. I believe that re-provisioning generally requires a reboot.

 

smouzakis
Nimbostratus
Nimbostratus

There is no need to reboot the device. The bigip only restarts the services automatically after the re-provision.

 

Does it work with 11.6.0 or only support on 12.0.x?

 

Martin_Duke
Legacy Employee
Legacy Employee

We introduced it in 12.1, as the article states.

 

Reason i asked because i can see AVR provision on 11.6.0 too but you said it's on 12.1 then it must be something else for.

 

Martin_Duke
Legacy Employee
Legacy Employee

Yes, AVR has been around for a long time, but not for TCP.

 

Any negative impact running TCP analytics on high volume VS?

 

Martin_Duke
Legacy Employee
Legacy Employee

Yes, as discussed earlier in the thread.

 

Ismael_Goncalv1
Historic F5 Account

It seems TCP Analytics are also supported by Forwarding Virtual Servers with FastL4 enabled (Forwarding or Performance L4). However, there is no way to use TCP::analytics to selectively enable/disable collection. Is there a workaround for that? Apparently TCP::analytics always require a TCP Profile on the VS.

 

Martin_Duke
Legacy Employee
Legacy Employee

Hi IRG,

 

There is no workaround. There are no FastL4 iRules, and we didn't introduce an entire FastL4 iRule framework as part of this feature.

 

Adding this capability is on our roadmap, but is a very low priority. If you would find it to be valuable, please talk to your account team about it.

 

slick
Altostratus
Altostratus

Hi, We are using BigIP for CGNAT, using the dedicated CGNAT module. This link points to LTM based implementation. I tried looking for the analytics profile somewhere else in the GUI and could not find it (didn't try TMSH yet). Obviously in CGNAT module we don't have LTM, so does this mean we can't use AVR for TCP ?

 

Regards Amos

 

Martin_Duke
Legacy Employee
Legacy Employee

Did you provision AVR?

 

slick
Altostratus
Altostratus

I believe I did. here is the output of show sys provision: root@(CGNAT-03-F5-HFA)(cfg-sync Standalone)(Active)(/Common)(tmos) show sys provision

 

Sys::Provision

 

Module CPU (%) Memory (MB) Host-Memory (MB) Disk (MB)

afm 0 0 0 0 am 0 0 0 0 apm 0 0 0 0 asm 0 0 0 0 avr 1 2048 768 3900 fps 0 0 0 0 gtm 0 0 0 0 host 10 3254 0 219484 ilx 0 0 0 0 lc 0 0 0 0 ltm 0 0 0 0 pem 0 0 0 0 swg 0 0 0 0 tmos 89 26900 280 0 vcmp 0 0 0 0

 

root@(CGNAT-03-F5-HFA)(cfg-sync Standalone)(Active)(/Common)(tmos)

 

slick
Altostratus
Altostratus

And here it is in the GUI:

 

Did I miss anything ?

 

Version history
Last update:
‎12-Aug-2016 08:00
Updated by:
Contributors