Forum Discussion

YannickJanssens's avatar
YannickJanssens
Copper Contributor
Sep 17, 2020

Meaning of GatewayRegion_s field in in WVDActivityV1_CL table in log analytics

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!
 
 
 
  • Soo Kuan Teo's avatar
    Soo Kuan Teo
    Icon for Microsoft rankMicrosoft
    Oct 06, 2020
    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-traffic-routing) 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.
    • YannickJanssens's avatar
      YannickJanssens
      Copper Contributor
      Oct 07, 2020

      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.

       

       

       

Resources