Service provider maintains our server services in two geographically distributed data centres. Our WAN infrastructure has a high concentration of DMVPN users and we are experiencing some random issues whereby users can take up to 20-mins to logon whilst others are very quick. Users utilise thin-client Wyse devices.
Not had much help from the service provider and we ourselves cannot narrow down a common issue. So we are about to get Wireshark to monitor but wondered if there are any other similar experiences out there as we suspect that the issue is with the provider but we have to prove it.
I have seen articles about MTU/MSS which indicates fragmentation might be issue although our routers and switches are set to MTU 1400.
So any experience out there, advice for things to look for given that ICA is new to us and looks to be not a pretty protocol?
The ICA protocol is not in play here if you are having long login times. Assuming you are using roaming profiles or some sort of profile management service like Citrix UPM, you should take a look at the traffic from you profile server to your XenApp servers (assuming terminal servers). Are your users logging into servers in one datacenter but profiles are in the other? This will cause the profile to be copied across the WAN. Also take a look at the domain controllers and profile servers themselves to make sure resources are free.
Re: Citrix ICA, DMVPN, slow logon - how to prove it!
Apologies for delay in responding to your kind reply but I have been investigating.
Currently from WAN router to XENAPP is ~30-50ms , switch is not much different yet client to XENAPP is pushing ~150ms. Clients are 100/Full and it's all looking good.
[toc:faq]The ProblemOn traditional switches whenever we have a trunk
interface we use the VLAN tag to demultiplex the VLANs. The switch needs
to determine which MAC Address table to look in for a forwarding
decision. To do this we require the switch to do...
[toc:faq]Introduction:Netdr is a tool available on a RSP720, Sup720 or
Sup32 that allows one to capture packets on the RP or SP inband. The
netdr command can be used to capture both Tx and Rx packets in the
software switching path. This is not a substitut...
IntroductionOSPF, being a link-state protocol, allows for every router
in the network to know of every link and OSPF speaker in the entire
network. From this picture each router independently runs the Shortest
Path First (SPF) algorithm to determine the b...