Meaning of GatewayRegion_s field in in WVDActivityV1_CL table in log analytics

Copper Contributor

I am trying to troubleshoot some disconnect issues with a customer in the Western Europe region. I used the following query to list all the connections (it's not the ARM release of WVD):

 

WVDActivityV1_CL
| where Type_s == "Connection"
| join kind=leftouter (
    WVDErrorV1_CL
    | summarize Errors = makelist(pack('Time', Time_t, 'Code', ErrorCode_s , 'CodeSymbolic', ErrorCodeSymbolic_s, 'Message', ErrorMessage_s, 'ReportedBy', ReportedBy_s , 'Internal', ErrorInternal_s )) by ActivityId_g
    ) on $left.Id_g  == $right.ActivityId_g 
| join  kind=leftouter (
    WVDCheckpointV1_CL
    | summarize Checkpoints = makelist(pack('Time', Time_t, 'ReportedBy', ReportedBy_s, 'Name', Name_s, 'Parameters', Parameters_s) ) by ActivityId_g
    ) on $left.Id_g  == $right.ActivityId_g
|project-away ActivityId_g, ActivityId_g1
 
What strikes me as odd is that the GatewayRegion fields shows values from all over Europe and not just the WEU gateway that would be logically be the closest one (customer is in the Belgium/Antwerp region and WEU is The Netherlands/Amsterdam). A short query shows this spread:
UKS23
GWC21
FRC17
WEU16
UKW14
NEU6
 
Suprisingly most of the connections travel via the UK South Gateway if I am understanding this correctly. I checked the same query with several different customers and they all show this spread.
 
I believe I have a solid grasp on how the RDGateway is selected; it depends on the DNS server used that actually makes the call to the Azure Traffic Manager but that wouldn't explain this result since most of the enduser either use the internet from the same office or probably use the automatic DNS server of one of our few ISP's.
 
Am I misunderstanding the meaning of GatewayRegion field in this context? I've also noticed that for the new ARM release this value is always empty so I couldn't double check there,
 
Thanks!
 
 
 
3 Replies
Thansk for your feedback! Good observation! This is expected. WVD gateways are distributed geographically in multiple Azure regions. Our attempt is to load-balance the traffic across nearby regions as to offer the best performance and experience for all users of WVD. Towards that, we make use of Azure FrontDoor with latency based traffic routing (https://docs.microsoft.com/en-us/azure/frontdoor/front-door-routing-methods#lowest-latencies-based-t...) and route users to gateways that are in the relative vicinity (not necessarily the one closest to them) without any negative impact on their user experience.

@Soo Kuan Teo 

Thank you for the reply! That would explain the results.

So my understanding of how the gateway is chosen does seem to be a bit off (I based this on a blog post about this topic somewhere). 

I assumed that running an nslookup of rdgateway.wvd.microsoft.com would correctly show the gateway that would be used if I was to start a WVD session.  For example at the moment is shows me:

 

Name: waws-prod-am2-f32c0796.cloudapp.net
Address: 51.136.28.200
Aliases: rdgateway.wvd.microsoft.com
rdgateway-prod-geo.trafficmanager.net
mrs-weur1c100-rdgateway-prod.wvd-ase-weur1c100-prod.p.azurewebsites.net
waws-prod-am2-f32c0796.sip.p.azurewebsites.windows.net

 

But running a capture with Wireshark does indeed show DNS entries such as afd-rdgateway-r1.wvd.microsoft.com which does imply that a Frontdoor service is at work.  

 

Thanks again for the explanation.

 

 

 

Hi

 

@Soo Kuan Teo Is there a list available of location names for the three letter codes ?

 

KR

Nick