ZIA High Packet Loss for Many Users

,

Hi All,
I’m currently working with Zscaler support on this but also hoping someone can shed some light on what I am seeing. My company is currently deploying ZCC to our employees, most of which are working remotely - concentrated in the US but also spread throughout Europa and Asia. A large number of our users are showing poor performance scores in ZDX and I can see large amounts of packet loss when looking at the Cloud Path metrics in ZDX.

In some cases, I am seeing large packet loss at the ZIA Public Service edges. In the example below there is 36% packet loss after hitting the ZIA service edge. Additionally, there is a high loss when hitting the TeliaCompany servers. I find this odd since this user is based out of Austin, Texas USA but appears to be routing through Telia servers in Warsaw, Poland. I have been seeing this pattern with almost all of our users that have poor scores in ZDX.

Does anyone have any ideas as to what is going on or can help me better understand what I am looking at here?

Additional info: our users are all macOS-based, running ZCC version 3.6.1.27 on Tunnel 2.0

Hopefully you’ve already got this solved, but here’s a couple of things:

  1. I personally find the packet loss stats in MTR (what Cloud Path uses) to be a bit misleading because some routers and servers rate limit ICMP and thus some packets will miss
  2. Telia is a very large, global telco based in Sweden that also owns a fair amount of infrastructure in the US (like many European telcos), so just because you see their name in your path doesn’t mean your traffic went to Europe and back. In fact, in your case, the IP 65.115.113.85 is a former Qwest/CenturyLink router in the DC area and the next one is in Allentown, PA. Here’s the info from ipinfo.io’s CLI:

Since we see that second IP again after it hits the ZIA edge, we can surmise that this is probably part of Zscaler’s backbone. Now, I’m not sure why the path would take you from a Dallas CEN to routers in DC and back unless something is virtualized or the info on ipinfo.io is wrong (which is unlikely but not impossible), but if correct, that is a highly inefficient path to go from Austin to a Google server in Keller.

Hey @benjmars,

Were you able to uncover any additional information? Dan provided some insights, was this helpful?

Thanks!