https://worldofeuc.com logo
Join Slack
Powered by
This message was deleted.
# citrix-vad
s
This message was deleted.
r
It does connect but the MTU size is wrong for those clients. You can check it with ctxsession -v on a session through ADC On linux or mac it will be 1500 On Windows with MTU Discovery around 1460
Also run Wireshark on the endpoint, you will see many fragmented packages when moving a window quickly in your session User experience sucks when fragmentation happens
n
That's good to know then.
And I just now realized that EDT MTU Discovery isn't even enabled by default in the VDA.
r
Upcoming version of RDAnalyzer will also show MTU Size. MTU Discovery is disabled by default due to specific version needs for ADC and the VDA was released before ADC
👍 1
n
I believe our Cisco VPN has an MTU size of 1300, so I was going to use 1272 in the Default.ica file.
Once I confirm that, of course.
r
Check with MTU discovery what size you need and put that in the default.ica So new clients use discovery, all other the static
n
Have you seen Adaptive Transport make a positive impact on video conferencing? That's one of the biggest concerns now.
The only way I know how to grab the MTU is using ping -f -l, waiting for packets to fragment. How do you make some clients use discovery, and others static?
r
Yeah with WAN I only recommend to use EDT as it performs way better than TCP on connections with latency. But without the correct MTU it is worse than TCP.
n
Citrix told us to basically follow that CTX article and enable every single setting, and roll with it... once we figured out the MTU size.
r
I use my windows device with latest CWA and enable MTU Discovery on vda. After I connect I check the MTU size and set that in default.ica So non discovery clients will use the default.ica mtu size
n
How are you checking MTU size? Your new RDA?
r
Yeah RDA or ctxsession -v, as RDA also uses that as a source
n
IcaBufferLength?
r
No there is a value now which just says MTU
n
Where in the registry? ctxsession -v doesn't show it.
r
Which VDA version?
n
1912 LTSR
r
Because if I run ctxsession -v in cmd it shows. I use 2003
Will test it tomorrow in 1912
n
Let's say I grab the MTU, either by this method or ping -f -l. Are you still subtracting 28 bytes from that value (for the header) and using that in the Default.ica file?
r
If you pick it from ctxsession than I use that exact value
That's how you can see it in RDA Pro Edition
n
I can't read German, but it looks like if I just enable EDT in QA and launch it, perhaps I'll actually see that value.
My version of RDA is 1911.
r
I've seen it in ctxsession also when MTU discovery was not yet enabled on VDA 2003
n
Ah, you know what? We would have to use the lowest value in our Default.ica. If Citrix shows 1400, but our Cisco VPN is 1300, I'd have no choice but to use the lower value to account for all users.
r
Yeah this version if RDA is still in alpha phase. Will roll out somewhere this month or next
Yeah you should test the MTU also trough the VPN to get the lowest one. That's why I like the discovery as it's dynamic
n
Citrix really doesn't make this easy.
I appreciate all of the help, Rody, that's for sure.
Okay, FWIW, if Adaptive Transport is enabled, you do get the MTU size:
And since I confirmed Cisco to be 1300, 1272 is my number.
I can't believe Citrix doesn't have that MTU Discovery setting available via GPO or something. I can all but guarantee that most of our XA servers will have it disabled, which will force everyone to use the value in the Default.ica file.
I'm seeing conflicting info on this. One Citrix article states to make that change and reboot the VDA, and another says to just make the change and that's it. If I can apply that key via computer GPO, that'd be optimal.
r
You need to set the value on your master image. GPO doesn't work. Saw that today when I was testing it on a project
n
Well, that's a bummer. Funny enough, Googling this only reveals a handful of pages, and one of them is a Twitter conversation between you and somebody else working on EDT issues.
r
Haha yeah it's still really new, but it's really cool piece of technology. And as there is no drawback for older clients I would enable it by default if the customer has the right ADC version
n
I have wanted to use it since it was still referred to as EDT. Stupid LTSR is the only reason it has taken this long... and NetScaler.
I'm not a fan of having to create GPO settings for older Windows Receiver clients, but if that's what it takes, so be it.
r
You don't need a GPO for older receivers. That GPO is for turning the feature of on new ones. To come back to EDT. I used it for more than 2 years now on projects and before that in an environment I was the admin off. It really works great but I learned the hard way that you need to look after MTU size
n
We still have some clients with Receiver 4.9 LTSR CU2, which is why I mentioned the GPO thing. I guess we could always use this as an opportunity to force their upgrade if they have issues.
r
So this is the behavior: - new client with mtu Discovery enabled will figure out MTU size automatically - new client with MTU discovery disabled will use default.ica if set or 1500 - old client will use default.ica or 1500 regardless of mtu discovery enabled or not
👍 2
n
Okay, that looks good. I plan on using this for all of Citrix - internal and remote connections.
r
Ah sorry, you use really old receiver. Then you need to update not apply policies😅
I've seen many performance issues with 1912 or later VDA with old receiver
n
We've been waiting for Citrix. Waited for Receiver 1912 LTSR only to find out that those clowns removed BCR from the agent, so we ended up being forced to go the Citrix Workspace App route anyway. I would have started with CWA 2002 long ago had we known.
We're testing CWA 2006.1 right now, and I anticipate the enterprise-wide rollout to begin in July.
r
Cool
n
@Rody Kossen: With Adaptive Transport enabled, do the Audio over UDP and Audio over UDP real-time transport policies in Studio even matter? They're enabled by default, but Citrix's documentation says that UDP audio is preferred to EDT. I'm a little lost on that one...
r
When you use EDT all the Virtual Channels will use UDP, so not only the Audio (which is the policy you are revering to )
n
That's what I assumed. I was just curious why Citrix would write that, because it doesn't make sense.
r
I'm reading the docs now. So from what I understand: • When you use UDP Audio you can create separate QoS rules for Audio traffic • UDP audio is preferred for connections with packetsloss as EDT will resend packets (which makes no sense with Audio)
But I have never enabled it or tested it..
n
"By default, Audio over User Datagram Protocol (UDP) Real-time Transport is allowed (when selected at the time of installation). It opens up a UDP port on the server for connections that use Audio over UDP Real-time Transport. If there is network congestion or packet loss, we recommend configuring UDP/RTP for audio to ensure the best possible user experience. For any real time audio such as softphone applications, UDP audio is preferred to EDT. UDP allows for packet loss without retransmission, ensuring that no latency is added on connections with high packet loss."
r
Yeah just read that part
r
This MTU situation, is a big deal. Its becoming more of a thing now
n
We're testing it all out in a few hours. Got my VDA image updated, and the policy in Studio is ready to go.
r
Let me know how it goes.
1. I take it we have to set both 
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\Wds\icawd
2. Name: MtuDiscovery 3. Type: DWORD 4. Data: 00000001 and update the default.ica faul with correct MTU size?
n
Yep
r
ok, right on
r
Yeah so: • MtuDiscovery for new Windows clients • default.ica for all clients (use value from option 1 to get the right MTU)
r
Sorry to keep asking. When you say MTUDiscovery for new clients is that the Dword?
r
Yes! So that's work Windows Workspace App
n
He means new Windows (Citrix Workspace App) clients that support MTU Discovery
r
Ok gothca
When the beta Pro verion for RDA coming out?
Here is the way I keep reading this. 1.Set this registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\Wds\icawd Name: MtuDiscovery Type: DWORD Data: 00000001 2. control EDT MTU Discovery on the client MtuDiscovery=on 3. C:\inetpub\wwwroot\Citrix\<StoreName>\App_Data\default.ica) OutBufLength=1480 edtMSS=1480
3. is a Example MTU value only
r
1. Correct 2. Not necessary, client side is enabled by default 3. Yes, but don't forget udtMSS=1480
r
ah ok, sorry, But thanks
r
👍
To answer your question regarding RDA, I hope before the end of the month
r
Ok cool. I would like to beta it if you offer that
Very great tool. Well worth the $$
r
Thanks! Good to hear you like it
We have some really cool stuff in the making just to tease you! 😉
r
Sweet man.
n
Our testing went well, for the most part. Performance in Skype and BlueJeans was basically the same on TCP and UDP. It's when we tested Webex did we have major isues in UDP. RTT went through the roof, and Webex was completely useless.
We were seeing RTT of 2000+ with EDT enabled and Webex in use. ICA RTT was crazy high, too.
r
Wow! Would not expect that.. Although, WebEx does suck (sorry)
n
Don’t be sorry, it’s absolute shit, and I think we already knew that. :)
I had never seen latency above 3000ms before, so that was fun.
r
Haha, let me see if I can reproduce it in my lab.. did you make a video or voice call?
n
Created a video meeting and didn’t share anything at all, just had 4 people in the meeting sharing video/audio.
r
That was why I had to go back to TCP. I couldnt get the latency and ICA RTT in control. I have a case of with Citrix, and its not going anywhere to be honest
r
Also due to WebEx?
r
Oh, well no. Sorry I missed that little detail
n
For us, it was definitely WebEx. Once we exited the app, latency went back to normal.
We’re going to test older receiver clients next week to see if our default.ica file looks good. Anything we should be looking out for? Not sure Director will really give us any detail on fragmentation.
r
Wireshark on the endpoint is the best solution
r
is this how you finding the correct MTU?
n
Yep, that was one method. You can also use ping w10vda -f -l 1500, lowering 1500 until the fragmentation stops.
Definitely prefer the ctxsession method.
r
Ok, I guess I need to understand how mtu fragmentation is occuring if 1500 is the right mtu for a base setup.
I'm so confused 😂
If I use ping w10vda -f -l 1500, how or what is telling me that the fragmentation is stopping I guess that is where I'm lost.
Nevermind I'm dumb. I'm tired not thinking
So I take it, this is my correct MTU? Dont mean to keep asking. Just triple checking things.
n
Using that method, yep. I think I'd still prefer using ctxsession -v, though/
There are no drawbacks to having MtuDiscovery set to 0x1 in the VDA even if you're not using EDT, correct?
r
Good question. I dont think so, The way I read it is MTU discovery. So I will discover it and change it right?
n
That's how I read it, as well. We have EDT explicitly disabled via policy, so I'm probably worried for nothing.
r
No, it doesn't matter. Have seen no issues with older clients and MTU Discovery enabled
👍 3
r
Citrix indentified the 64000ms latency issue around the incorrect ICA RTT times. They are stating this fixes it 1. nsapimgr -ys enable_ica_edtinsight=1 2. nsapimgr -ys enable_ica_l7_latency=0
Its just a workaround until they fix it for good
r
Ah! Good to know! Do you have a bug id?
r
I am waiting for that, once I get it I will update you guys
n
I assume it's a bug in whichever build of NetScaler you're running?
r
I was on 12.1.55 then went to 12.1.57. But It happned since 11.1. This is only when EDT is enabled and going through the gateway.
I assume you dont get this crazy values?
n
I have no access to our NetScalers, but I've never heard of that issue here.
5 Views
Open in Slack
PreviousNext
Powered by