Hi, I am troubleshooting slowness for Citrix running over a site to site VPN. The site also has a considerable number of users browsing the web. I have run a packet capture on the firewall to capture all traffic and am trying to provide data as to prove where the slowness is. It's not slow all the time. I have noticed that when I run a filter for (tcp.window_size<1460)&&(tcp.flags.reset==0) I get back a lot of packets and a considerable number are around a windows size of 100. This is from multiple clients but what exactly does this mean or could someone tell me what I need to be looking at next to help the situation. Thanks I'm pretty new to Wireshark : ) asked 05 Mar '15, 14:21 Costello |
2 Answers:
Troubleshooting Citrix (or any remote desktop) traffic is probably among the most complicated analysis problems you can run into. That's because those protocols are highly asynchronous, other than traditional request/response protocols, so it's kinda hard to tell when something took too long when it shouldn't have. Especially since all those protocols are proprietary and can't be decoded with Wireshark (well, the Citrix-capapable commercial analyzers I've seen do not impress me with their decode abilities, either). The window size is a good indicator if it gets pretty low - 100 byte (scaled) is not a lot. Rule of thumb is that there should always be at least two segments of Window Size, e.g. 2* 1460 bytes, so 100 bytes is very low. Often, Citrix is run on thin clients which are not strong enough to handle high resolution flash movies, so you'll see window sizes go down in those situations. Low window sizes often indicate weak hardware, so maybe you can compare results with stronger/fat client hardware. answered 05 Mar '15, 15:09 Jasper ♦♦ |
There are thre magic keywords/phrases:
I'll assume you are connecting through a VPN tunnel from a remote site to the central site and the central site is where the "considerable number" of users are browsing the web. If that assumption is correct, please think about a bandwidth consumption and/or RTT problem. What can you do:
Regards answered 05 Mar '15, 16:23 Kurt Knochner ♦ Super responses thank you very much (11 Mar '15, 01:46) Costello You're welcome. Any results based on the RTT analysis? (11 Mar '15, 03:38) Kurt Knochner ♦ I have taken an RTT graph and although its not related to the Citrix issue it does relate to the sites that Citrix runs over. In addition to running Citrix these sites also download AV updates and send logs to a central server that sits on the same network as the Citrix servers (its a branch office head office type scenario). I have run wireshark on the AV server in head office and set a capture filter for just the remote sites IP. The RTT graph would seem to indicate a device is queuing traffic? https://drive.google.com/file/d/0B5Av_KyDN-WVVnlxRVVBWUhXNW8/view?usp=sharing (12 Mar '15, 01:49) Costello
well, that's hard to tell by looking at just a single RTT graph. (12 Mar '15, 02:11) Kurt Knochner ♦ Not only is it hard to tell from a single RTT graph, as Kurt said, but Wireshark does not implement the RTT graph correctly. See https://ask.wireshark.org/questions/38607/rtt-graph-showing-values-higher-than-tcpanalysisack_rtt . The RTT graph values will not be correct if delayed ACK is in use. They should be correct if delayed ACK is not in use. To see correct round-trip times, use the I/O graph as mentioned at that link. (12 Mar '15, 09:42) Jim Aragon |
Apologies on the points I'm not fully up to speed yet on the site. How many points can be awarded? can they be split among responders. Thanks.
Generally we don't bother with awarding points, rather just accept the best answer using the check mark icon and vote up other good answers with the thumbs up icon.