Forum Discussion
NimbostratusLTM TCP statistics - Received Reset
I have a problem finding information about BIGIP-LTM statistics.
We have a very important application, whith long-lasting sessions. When viewing the VS statistics with the TCP profile we see the following:
ltm virtual /Infrabel/a1183-tms-imi_vs {
destination /Infrabel/10.252.13.204%113:6039
ip-protocol tcp
mask 255.255.255.255
partition Infrabel
persist {
/Infrabel/a1183-tms-imi_sticky-mirror {
default yes
}
}
pool /Infrabel/a1183-tms-imi_pool
profiles {
tcp { }
}
source 0.0.0.0%113/0
source-address-translation {
type automap
}
vs-index 160
}
------------------------------------------------------------------
Ltm::Virtual Server: /Infrabel/a1183-tms-imi_vs
------------------------------------------------------------------
Status
Availability : available
State : enabled
Reason : The virtual server is available
CMP : enabled
CMP Mode : all-cpus
Destination : 10.252.13.204%113:6039
PVA Acceleration : none
Traffic ClientSide Ephemeral General
Bits In 271.7M 0 -
Bits Out 267.2M 0 -
Packets In 658.9K 0 -
Packets Out 734.9K 0 -
Current Connections 43 0 -
Maximum Connections 44 0 -
Total Connections 2.9K 0 -
Evicted Connections 0 0 -
Slow Connections Killed 0 0 -
Min Conn Duration/msec - - 59.9K
Max Conn Duration/msec - - 155.9M
Mean Conn Duration/msec - - 97.7K
Total Requests - - 0
SYN Cookies
Status not-activated
Hardware SYN Cookie Instances 0
Software SYN Cookie Instances 0
Current SYN Cache 0
SYN Cache Overflow 0
Total Software 0
Total Software Accepted 0
Total Software Rejected 0
Total Hardware 0
Total Hardware Accepted 0
CPU Usage Ratio (%)
Last 5 Seconds 0
Last 1 Minute 0
Last 5 Minutes 0
--------------------------------------------------------------
| Ltm::TCP Profile: tcp
--------------------------------------------------------------
| Virtual Server Name /Infrabel/a1183-tms-imi_vs
|
| Connections | Open 86 | Current in CLOSE-WAIT/LAST-ACK 0 | Current in FIN-WAIT/CLOSING 0 | Current in TIME-WAIT 0 | Accepted 2.9K | Not Accepted 0 | Established 2.9K | Failed 0 | Expired 0 | Abandoned 2 | | Miscellaneous | Received Reset 2.9K | Bad Checksum Datagrams 0 | Malformed Segments 0 | Out-of-Order Segments 0 | Received SYN Cookies 0 | Received Bad SYN Cookies 0 | SYN-Cache Overflow 0 | Retransmitted Segments 76Here I see Accepted - Established 2.9K. But I also see Received Reset 2.9K.
When I take a look at the pool statistics, everything seems OK.
Can someone give me more specific explication about this error - where I can find documentation and if possible how we can investigate more (LOG is not an option due to heavy traffic).
Thanks
6 Replies
Yann_Desmarest_Nacreous
Hi,
Statistics are just counter that need to be reset sometimes. To make sure that your app works fine, you can reset the statistics in the webui (Statistics >> Module Statistics >> Local Traffic). You can reset tcp stats of your tcp profile in your VS and check if tcp reset counter increase again.
You can also launch a tcpdump on the F5 cli and check if there is some tcp reset from one of the peer.
In your case, the tcp reset can come from the client too.
jan_de_wachter_Yann, Thanks for your answer. We do a reset of the statistics every Sunday. The statistics show us that every connection receives a TCP reset. But since the pool statistics are also updated, I'am sure the connection client - F5 - servers is working. What can cause this TCP reset. We dot not prefer using TCPDUMP since the amount of traffic that is generated.- Yann_Desmarest_Hi, You can use a clone pool to clone traffic of the VS to an external system. You can use a linux system that has wireshark installed. You can also sniff the traffic on your network and check for tcp reset.
Yann_DesmarestCirrus
Hi,
Statistics are just counter that need to be reset sometimes. To make sure that your app works fine, you can reset the statistics in the webui (Statistics >> Module Statistics >> Local Traffic). You can reset tcp stats of your tcp profile in your VS and check if tcp reset counter increase again.
You can also launch a tcpdump on the F5 cli and check if there is some tcp reset from one of the peer.
In your case, the tcp reset can come from the client too.
- jan_de_wachter_Yann, Thanks for your answer. We do a reset of the statistics every Sunday. The statistics show us that every connection receives a TCP reset. But since the pool statistics are also updated, I'am sure the connection client - F5 - servers is working. What can cause this TCP reset. We dot not prefer using TCPDUMP since the amount of traffic that is generated.
- Yann_DesmarestHi, You can use a clone pool to clone traffic of the VS to an external system. You can use a linux system that has wireshark installed. You can also sniff the traffic on your network and check for tcp reset.
