Introduction
I'll start by saying that I probably would have published this article a long time ago. But I did not because I do not usually get this question twice a year ... and it was fairly easy to dig up the last of my email archives and send it to the person who asked about the reliability session this time. But then last week, I asked twice about it. And that's when I take my "public" answer and write an article about it. So here goes ... the purpose of this article is to talk about Common Gateway Protocol (CGP aka session reliability), when it should be activated when it should be disabled and why you hate probably watch hourglasses and frozen screens.
history CGP
I still like to understand the history of things in order to understand them, so I thought a brief trip down memory path was in order before we dive in CGP. As Jeff Muir describes in his "Two ICA Port" section, we have developed CGP more than a decade ago when Citrix was originally looking to extend the ICA protocol. Specifically, we need a way to wrap ICA traffic and maintain session if a network link fails. As it happens, network speeds and connections were there pretty crappy over 10 years and our customers were tired of being constantly disconnected from their session and have to reconnect every time there was a kind of blip network. We asked for a port IANA, they gave us in 2598, we wrote CGP (and Secure Gateway) and the rest is . history
How CGP works
the intention of this article is not to explain how or CGP session reliability work - we do a very good job explain how it works in this technote that has been around for 9 years. So I review this article, but I will also give you the quick version. When the SR is enabled, the ICA or ICA traffic inside tunnels Receiver CGP via TCP 2598. The "Citrix XTE Service" is the infamous piece side code server that acts as a relay, then removing the layer CGP shipping ICA traffic the listener 1494. ACI on the XTE Service is responsible for the traffic "buffer" if the network link between the client and server XA or XD is broken or temporarily interrupted. And when the network link is down and dab us traffic, we indicate to the end user by showing an hourglass or a blocked screen. (This was probably a mistake on our part, but we are beginning to change that now with the latest versions of receiver using messages or pop-up tooltip information. - Later) Finally, once the network connection is restored , stop showing that wonderful "hourglass of death" (as I lovingly known for years), we empty the buffer and the end user can continue working as usual. So we solve the problem of dropped sessions and having to constantly reconnect if a network blip, but what we do in the process by allowing CGP? If you still allow CGP because it is a default setting? Or should it be used sparingly when it makes sense? What are the scenarios where it makes sense to allow? These are the questions I get most often and what I really want to talk about in this article.
Disadvantages of CGP and why you may disable the
Don 't get me wrong - there is a time and a place for SR and I will talk these scenarios in a minute. But I'll let you know that there are some disadvantages (largely) undocumented using SR or to CGP. And our consulting team eventually disable (or recommend to disable it) from time to time. Why?
- Activation SR increases network traffic sending keep-alive packets more frequently compared to the keep-alive function ICA standard. My colleague, Brendan Lin and I are trying to capture some Wireshark traces with various receptors and XA and XD versions and we will follow up article once we have all the data. But the last time we took a track it a few years ago, we found that activation of CGP did send keep-alive every 4 seconds against 60 seconds (default setting ICA keep-alive) . Of course, these keep-alive are not huge and it's not much traffic if you have 100 users. But if you have 5000 users that can really add up and we saw it in the end ... not Mb Kb range as expected. We also saw overhead CGP introduce more events reconnect on high latency networks with her disabled! I also want to reiterate that things are changing in the latest versions of receiver and XD (where we re-wrote the XTE Service), so this overload network traffic is negligible - stay tuned for the follow item Brendan more detail but we are rather surprised by the initial results.
- the XTE Service consumes extra CPU cycle s on the host or workstation when CGP is enabled and especially when it is "buffer". I've seen several cases where the XTE Service has virtually pegged a box by itself, and after looking into it, CGP was the culprit (which leads me to my next point). We also published technotes in the last two years after XD began with advice like "use 2 vCPUs instead of 1 vCPUs if CGP / SR is enabled on the ADV", etc. The bottom line is it adds a little overhead and these additional CPU cycles can lead to decreased scalability and poor performance in certain situations.
- users do not like pop-ups, hourglasses or frozen screens. 😉 And while I joke around about it, the real point here is that, by allowing CGP we often end up masking problems REAL network . I've seen people mistakenly TcpMaxDataRetransmissions too high and it is almost impossible to detect when CGP is enabled. I saw also "bulletproof" network with redundant links and several Internet service providers have problems that are ridiculously difficult to resolve or detect when CGP is enabled. The fact of the matter is Citrix often gets a bad rap because users complain of "freezing" and they are watching while hourglasses CGP is a kick in (and working with the design!). And most of the time it is not a Citrix issue at all - well maybe a REAL network problem that must be supported. Disabling CGP generally exposes the problem much faster and results in a quick and appropriate resolution. God thank you, we are moving away from frozen screens and spinning wheels with tooltips more information messages in the latest versions of receiver!
So in general, if a customer has a seemingly stable network and most users are on the local network, it might be best to disable CGP. And if you use an older version of XA customers and legacy of ICA (ie XA 4.5 with 10.x, etc.), I could also feel stronger about off. We did that for years some of our most important customers without problems. But this does not mean that there are no scenarios where it is beneficial or we would not recommend it active. What are some of these scenarios?
Benefits of CGP and specific scenarios where it must be enabled
- Mobile users on reliable wireless / 3G / 4G connections . Such is the case of the most obvious use or scenario and why we invented it - for police offers who roam between different cellular networks while driving ... or nurses who use COWs in hospitals to move to different rooms with different WiFi networks. Have the data on the screen at any time is important in these scenarios (although there is an hourglass covering part of the screen). And overhead CGP prevails constantly disconnected and reconnected for these users. NOTE / UPDATE: Before you say to yourself, "I WAN or wireless scenarios, so I have to allow CGP", please read my response to Shawn Low below in the comments section. Shawn brings a good point about WWAN is becoming increasingly common, and even if I agree, I think there are some things you can do before just failing to CGP.
- anonymous access . This is a use case of my colleague, Dan Allen, higher that is quite interesting. He allowed CGP when he had to use anonymous published applications in some environments. Without CGP, reconnections are not possible because connections were anonymous. But with PMC, we can identify a previously disconnected session and reconnect to the right session.
- AGED Seamless failover. This was a hotly debated internally about it a few months ago ... but the bottom line is if you want it to be uninterrupted when a NetScaler fails on, you need to cushion CGP connections. Without CGP, users are proxies via the gateway will reconnect. I must say that this is a rare event when you have your top NetScalers and running in production, but it does happen from time to time, and if this is very important, so CGP can be for you.
- multi-stream ICA. Perhaps one of the worst names we've ever come up with because it requires CGP (without repeater anyway). It should be called "Multi-Stream CGP" instead! But if you use this new feature to connect the virtual channels and provide true QoS, then PMC is required. This may change in the future, but for now, it does not work with regular CIA unless you have Repeater.
- the latest versions of Receiver and XenDesktop. More details will be available in Brendan article, but we really improved the protocol in the latest versions of XD and receiver - ie XD 5.6, 7 and 4. Receiver If you use our latest products, we believe that the costs general is almost negligible and informative tooltips provide a better user experience, if there is a network problem.
So, if you are in one of the above situations, then CGP offers some value and you should probably keep it on (remember, it is enabled by default on both XA and XD, so you must explicitly disable!). But if you do not find in any of these scenarios, it might be better to eliminate the "middle ... and go directly to the source," as Jeff Muir said, and off CGP to save valuable resources.
Conclusion / Wrap-up
I hope this helps clear up confusion around session reliability. I am also (selfishly) happy to have finally captured all this information on paper, so I just can not point to a URL instead of digging through my email archives in the future. But please let me be clear, let me make an end - I do not recommend disabling CGP . In fact, one of the other reasons why I wanted to write this article is because I have seen many of our consultants in the field recommending "blind" to disable CGP. And I would always respond to them and say that we should not preach that, especially without adequate justification. There is a time and a place for CGP as I said earlier (and as many of you have already noted in the Comments section below). And we have really improved CGP in the last year in particular. I hope this creates some awareness and makes people think about whether CGP should be used or not. I also like making more of our customers with and without TEST CGP to see how it works and if it makes sense to allow in their particular environment. That's my dream anyway - a world where people think critically and to test properly. 😉
Thanks for reading and stay tuned for a follow-up article where we dig in with some traces CGP enabled vs disabled ... I had originally planned to publish this information in the context of this article, but after our first few traces, things have changed a bit and CGP looks a bit different than it did just a few years. Much of this has to do with the architecture XD IMA-less (5.x +) where we have completely re-written the XTE Service and support protocols
Cheers, Nick
Nick Rintalan
senior Architect, Citrix Consulting
0 Komentar