Sniffer Capture : Fast Retransmissions 1

[misjay01]

Hello,

We have a profile server that is currently experiencing high CPU everytime users log out of their PCs at 5:30pm The profiles are saved on the server when users logout.

Performed some sniffer captures and at most I can only see Window Frozen, Repeat ACK, ACK too long and Fast Retransmissions under under symptoms and diagnoses. The majority errors are fast retransmissions and ACK too log.

Does anyone know what the fast retransmissions could mean and if the problem is server related.

Server Specific:
1.4 Gig Processor
2 Gig RAM
2 x 200MG Ether-channeled NIC
2 x 36 Gig Local Disks + SAN

 

[mpennac]

Here are some comments on the symptoms you are seeing:

Window Frozen - 99.999% of the time this symptom does not indicate a problem on the host. The analyzer will note the highest TCP window size advertised by the host. If this window size falls below this value and stays there longer than the threshold set in the expert symptom, you get the error. What does this mean? The server may not be using the best buffer management, but as long as the window size does not hit zero, it will not be a problem.

ACK Too Long - The Microsoft TCP stack, as well as many others will Acknowledge every other TCP data frame. If an odd number of data frames are received, the receiving TCP stack will typcially wait 200ms for the next data frame before sending the ACK. Most analyzers have the expert symptom ACK Too Long set to a 200ms threshold. This is too low for a MS environment and will result in false positives. I increase the threshold to 250ms. If there are really long ACK's you will still catch them, but you will avoid the delayed acknowledgements.

Fast Retransmissions - Was the analyzer software loaded on the server, or a computer talking to the server? In certain cases, the analyzer software will pull the packets transmitted by the analyzer pc twice. You will see the same frame two times in a row in the trace. One way to determine if this is the case, is to look at the IP Identification field. If the value is the same in both frames, you have a NDIS/Analyzer problem. A true retransmission will have different IP Identification numbers, and the TCP information will be the same. If this is the case, use a separate computer for analyzing, that will not be transmitting frames.

If you want to know if the server is really retransmitting frames, run netstat -s at the command prompt. Look at the TCP section and Retransmitted Segments. If this value is rising quickly, frames are being lost.

My experience with profile servers has been limited, but I know that Web Browser caches can be a real problem. Since the cache is part of the profile stored on the server, a user with a big cache can create a lot of traffic.

Hope this helps.

mpennac

http://www.netprospecialists.com

 

[misjay01]

Mpennnac,

Thanks for your response. I had the analyser software running on a laptop which was connected via SPAN port on the server switch (Cisco 6513).

The following is a sample output :-

4/11/2004 17:29:12.351 57s 91ms Minor Fast Retransmission TCP: [10.16.78.71] - [172.17.150.32] Port 1224 - 139
4/11/2004 17:29:12.374 57s 67ms Minor Fast Retransmission TCP: [10.16.96.181] - [172.17.150.32] Port 1064 - 139
4/11/2004 17:29:12.486 43s 844ms Minor Repeat Ack TCP: [10.16.113.162] - [172.17.150.32] Port 1604 - 139
4/11/2004 17:29:12.495 56s 947ms Minor Fast Retransmission TCP: [10.16.217.89] - [172.17.150.32] Port 4776 - 139
4/11/2004 17:29:19.405 50s 37ms Minor Fast Retransmission TCP: [10.16.102.82] - [172.17.150.32] Port 3477 - 139
4/11/2004 17:29:19.477 49s 965ms Minor Fast Retransmission TCP: [10.16.74.81] - [172.17.150.32] Port 3000 - 139
4/11/2004 17:29:19.593 49s 849ms Minor Fast Retransmission TCP: [10.16.107.70] - [172.17.150.32] Port 3814 - 139
4/11/2004 17:29:19.594 49s 848ms Minor Fast Retransmission TCP: [10.16.38.183] - [172.17.150.32] Port 3608 - 139
4/11/2004 17:29:19.723 49s 719ms Minor Fast Retransmission TCP: [10.16.77.83] - [172.17.150.32] Port 1067 - 445
4/11/2004 17:29:19.753 49s 688ms Minor Fast Retransmission TCP: [10.16.92.109] - [172.17.150.32] Port 2569 - 139
4/11/2004 17:29:19.958 49s 483ms Minor Fast Retransmission TCP: [10.16.94.177] - [172.17.150.32] Port 1060 - 139
4/11/2004 17:29:20.193 49s 249ms Minor Fast Retransmission TCP: [10.16.103.79] - [172.17.150.32] Port 1261 - 445
4/11/2004 17:29:20.201 49s 241ms Minor Fast Retransmission TCP: [10.16.99.96] - [172.17.150.32] Port 1061 - 445
4/11/2004 17:29:20.346 <1ms Minor Ack Too Long TCP: [10.16.214.177] - [172.17.150.32] Port 3672 - 445
4/11/2004 17:29:20.347 35s 983ms Minor Ack Too Long TCP: [10.16.113.162] - [172.17.150.32] Port 1604 - 139
4/11/2004 17:29:20.348 5s 233ms Minor Ack Too Long TCP: [10.16.214.177] - [172.17.150.32] Port 3672 - 445
4/11/2004 17:29:20.349 <1ms Minor Ack Too Long TCP: [10.16.218.86] - [172.17.150.32] Port 3032 - 139
4/11/2004 17:29:20.354 49s 88ms Minor Fast Retransmission TCP: [10.16.193.78] - [172.17.150.32] Port 1073 - 139
4/11/2004 17:29:20.357 49s 85ms Minor Fast Retransmission TCP: [10.16.112.62] - [172.17.150.32] Port 2117 - 139
4/11/2004 17:29:20.357 11s 582ms Minor Ack Too Long TCP: [10.16.215.206] - [172.17.150.32] Port 4284 - 445
4/11/2004 17:29:20.360 <1ms Minor Ack Too Long TCP: [10.16.71.63] - [172.17.150.32] Port 1062 - 139
4/11/2004 17:29:20.404 49s 38ms Minor Fast Retransmission TCP: [10.16.76.78] - [172.17.150.32] Port 3824 - 139

 

[stevemerc]

from what I have seen a lot of fast retrans and repeat acks are actually duplicate packets seen in the trace. See if the IP identifier in the origanil packet then the fast retrans is the same. If spannning check how the span is configured. If not check for a loop.

 

[ChunderPants]

Hi All
I'm having the same problem with users reporting slow response connecting to thinclient (citrix) terminal servers. I have configured a SPAN port on the cisco switch along with sniffer pro to capture the data. I'm seeing the same responses as above Ack to long, Window Frozen, Fast Retransmission. The capture shows the same info at 3 different sites on the network. Could this be a server problem and not a network issuse? Buffer size problem on the servers?