Latency Issues with ZTNA segment based applications using RCP/SCP
Article ID: 412732
Updated On:
Products
Issue/Introduction
Enterprise users using ZTNA segment applications to access internal servers/services via WSS Agent.
One group of developers, located in the UK, are seeing latency issues when trying to sync up code using RCP (user sees 1MBps download speed) and occasional hangs.
When using the ZTNA service, the RCP traffic is sent into London GGBLO1 POP and the ZTNA connector is installed in Amsterdam, Netherlands. This implies that the traffic goes from user location to London, then upstream to a ZTNA connector in Amsterdam (via GCP network) and back to the origin server in the UK.
A VPN client, being decommissioned, can connect to a server in Amsterdam and no latency issues visible (user sees 3.5MBps download speed).
Environment
ZTNA segment based applications.
WSS Agent.
Performance concerns.
Cause
ZTNA tenant incorrectly provisioned to the US, and not EMEA.
Resolution
Re-provisioned the ZTNA tenant to the EU region.
When the ZTNA tenant is provisioned to the US, the connector interfaces with the ZTNA service in the US, increasing the round trip time for any communication.
In the above example, the users traffic would go from the
- local network into the Cloud SWG London GGBLO POP via WSS Agent
- Cloud SWG London POP into the ZTNA service in the US where the tenant was provisioned
- ZTNA service in the US to the connector in Amsterdam
- ZTNA connector in Amsterdam to the application server in UK and all the way back ... quite a world tour!
By switching the tenant to be an EU based tenant, the route from the Cloud SWG POP into the ZTNA service is local to the EU and the round trip time, and hence latency hugely diminished.
Feedback
