Bug ID 624016: Traffic data stats got lost on hardware accelerated flows when the flows are terminated earlier

Last Modified: May 23, 2019

Bug Tracker

Affected Product:  See more info
BIG-IP LTM(all modules)

Known Affected Versions:
12.1.0, 12.1.0 HF1, 12.1.0 HF2, 12.1.1, 12.1.1 HF1, 12.1.1 HF2, 12.1.2, 12.1.2 HF1, 12.1.2 HF2, 12.1.3, 12.1.3.1, 12.1.3.2, 12.1.3.3, 12.1.3.4, 12.1.3.5, 12.1.3.6, 12.1.3.7, 12.1.4, 12.1.4.1, 13.0.0, 13.0.0 HF1, 13.0.0 HF2, 13.0.0 HF3, 13.0.1, 13.1.0, 13.1.0.1, 13.1.0.2, 13.1.0.3, 13.1.0.4, 13.1.0.5, 13.1.0.6, 13.1.0.7, 13.1.0.8, 13.1.1, 13.1.1.1, 13.1.1.2, 13.1.1.3, 13.1.1.4, 13.1.1.5, 14.0.0, 14.0.0.1, 14.0.0.2, 14.0.0.3, 14.0.0.4, 14.1.0, 14.1.0.1, 14.1.0.2, 14.1.0.3, 14.1.0.4, 14.1.0.5

Opened: Oct 20, 2016
Severity: 3-Major

Symptoms

When the clients tend to reset HTTP keep alive connections immediately after data are received, instead of gracefully closing the connections per RFC, it presents a problem for TMOS, as we rely on the hardware FSUs (flow status updates) to calculate the packet counts for offloaded flows, but these flows were reset before the FSUs were sent from the hardware. So, we lost these packet stats for the offloaded flows, because BIG-IP can not determine the traffic direction without the connection flow information. FIN packets will have the same effects to close the connection. If there are FSUs after the FIN packets, they won't be counted either.

Impact

pva traffic stats may not accurately show the packets/bytes counts for the offloaded flows.

Conditions

Clients that reset connection immediately after data is received.

Workaround

One workaround fix is to consult with the hardware ePVA packet and byte forward counters in addition to the global PVA traffic stats. For verification purposes, this can be quickly used without any code changes with the following command: # tmctl -d blade -s name,active,bus,rqm_epva_fwd_pkts,rqm_epva_fwd_bytes tmm/hsbe2_internal_pde These rqm_epva_fwd_pkts/bytes counters are the current hardware counters from the ePVA registers, whare are more up to date. The only catch is that you will need to correspond the lbb_pde number to the individual PVA numbers in the output of "tmsh show sys pva-traffic". To get the global stats for all PDEs as in "tmsh show sys pva-traffic global", you will have to add thses number up with a script.

Fix Information

None

Behavior Change