https://worldofeuc.com logo
Join Slack
Powered by
This message was deleted.
# citrix-vad
s
This message was deleted.
j
So it got slower when you bypass gateway service (workspace) and use storefront which will effectively give an ica file telling the igel to launch direct to the workload? Is there something between you endpoints and Workloads? Firewall, inspection, weird routing paths etc?
l
Exactly that, Most bizarre was that I watched a users connection for a good few hours when first testing, and the needle never moved latency-wise, bar locking and unlocking IGEL, which causes a normal little blip for a second or so. Network locations have been set up to reference the internal networks also. dont believe there is any funky FW stuff there as all basically sitting together, also IGELS still going through the gateway aren't seeing this..
j
Hrmm that’s a fun one Could it be MTU related here? An interesting test would be to call on those network locations you have configured for workspace, and see if you can get a direct connection to the VDA via that path (direct workload connection) That should (I would think) mirror the same latency problems @Shane Kleinert ring any IGEL bells for you?
👍 1
l
And just to clarify connections from the IGEL's are to get desktop launch only, so traffic would flow IGEL > CC > VDA
I did look at the MTU initially, but disregarded it as other IGEL's with no SF in the mix didnt show same symptoms..
j
Storefront doesn’t get in your path for connectivity though, it is just providing your IGEL with a direction on where to connect to So with gateway service and workspace, by default you will auth at workspace, then connect via gateway service and route through the CC If you have rendezvous configured, you will auth at workspace, connect via gateway service but not route through CC, gateway will go direct to VDA If you define network locations (DWC) you will auth at workspace and then direct connect to the VDA - pretty much the same model as storefront Hope I’ve got that right :-)
In your scenario, you have a completely different connection path when storefront comes in, not because of the fact storefront is in the path, but that it’s telling your IGEL to connect direct (this is all of course customisable with advanced storefront and gateway configs, but probably not relevant for here)
You could even be switching from a UDP connection to a TCP one (ctxsession -v will show you on the VDA)
l
Thanks, James, I did force TCP as the last test and thought it had cracked it. Unfortunately, it seems not.
😞 1
Rendezvous is enabled, and i did try disabling it, again thinking it wouldnt have any sway as internal shouldnt attempt to use rendezvous should it? I wonder if a valid test is forcing TCP and disabling redezvous?
j
Not if your connections aren’t traversing the gateway service - remember with storefront, your cloud workspace and gateway settings are now not in play at all
❤️ 1
Rendezvous is a gateway connection optimization flow, and DWC (via network locations) is aimed to bypass the gateway - so none of these things should be in the mix
Correct me if I am wrong, but you have storefront, storefront has your cloud connectors defined for farm enum, and you are pointing igel to storefront url?
l
yes that's how its currently wired James
j
Yah so that is going to be sending your igel direct to the VDA -> time to slap a network person :-)
😆 1
Not 100% sure on igel configs, maybe they have something that is making your gateway connections work, but is impacting your direct - it’s been a while since I’ve touched anything igel based @Matt Nation and @Shane Kleinert are both awesome with them
m
What do you see on a windows device taking the same path?
l
Sorry for a little delay, I utilised a windows device running video for 7 hours yesterday, no spike from 1ms that i could see at any point over the session..
m
l
Some bedtime reading right there, thanks Matt, ill check that out.
m
What igel firmware are you on? This smells of a local nic issue??
Can you run the igel trace route tool and look at latency for each hop in the path?
l
Current FW version is 11.08.255.01
m
That’s what we have in production. What kind of endpoint?
l
UD7-LX20's
will check with trace route tool when i can get on one
m
I'd def make a post in the IGEL community slack channel. great group of guys that i'm sure can provide more input.
l
Thanks Matt ill definitely do that as well
Guys sorry for being 'slack' 😆 in here, bet you've never heard that before, but seemingly all on the right track with TCP and UDP settings, eventually found what i was after, which was here: this then forced TCP on the IGEL, where as Citrix policy to disable didnt seem to do the trick properly? we are still in test, and no real buy in from the customer at the mo, but ive seen nothing but flat lines latency wise since, wanted to post in case it saved someone else (like me) a load of swearing to find 👍
j
Hooray! Thanks for closing the loop
👍 1
l
Cheers for your Input James, enjoying you site mate 👍
j
Bit of a fun soap box 😬
m
Yeah IGEL policies seem to override studio policies as they feel they know what’s best 🙄
😆 1
2 Views
Open in Slack
PreviousNext
Powered by