Is anyone else having issues with accessing private storage through NPA (private access) becoming extremely slow? We are mostly a windows shop and a large portion of our end users are having an issue where when they move any file from one of our Netapp on prem storages or even a Windows based file server the speeds are insanely slow when users are using ZTNA. It seems like this mainly affects transfers of lots of small files vs large single files. With the client uninstalled and the user back on our traditional VPN we get about what we would expect (a few megabits a second depending on the end users internet speed). Enabling the client puts us down to ancient baud modem level speeds - sometimes as low as 300 bits a second!
Extremely Slow File Storage Access Speeds?
This topic has been closed for replies.
+8Thank you for reaching out, @chrisisinclair! Our community team is looking into this for you and will get back to you shortly! If anyone else has any ideas that you feel may help, please share them here.
Turns out the publishers in our DMZ are not connecting to the correct datacenter - with EDNS enabled they will connect to NYC or North Virginia and route all traffic all the way there from our Burbank, CA COLO. We worked with support and have temporarily mitigated this by disabling EDNS on all publisher servers and then manually pointed each server to the San Jose datacenter by editing the host file.
We also recently did further testing by deploying a brand new v95 Ubuntu publisher in Burbank and it had the same behaviour. We then deployed a brand new v95 Ubuntu publisher in our Phoenix datacenter and it too also connected to NYC.
+3Hi. Any new updates regarding this concern. We are also experiencing extreme slow down when via file share so users ends up going back to traditional VPNs.
+5Access thru the Private access is slower than our traditional VPN. We installed enough Publisher in our data center but I can't get more than 2mb/sec.. Most of the time it is about 1-2 MB/sec. Is there a way to increase the speed or is this by design?
+9@thoang3 has anyone from Support looked into this? NPA Publishers can support up to 500 Mbps, so the observed rate looks really low. If not done yet, I recommend opening a Support case, so we can have someone review the performance issues.
+1I know I may be late, but I am still having this issue with our recent deployment of Netskope. Has anyone found a solution to this? Our traditional VPN works as expected, over PA, we are experiencing the same issues as @noelnoguera. Any insight would be great.
+4We’ve just enabled NPA for a large user group and almost immediately started seeing tickets on users reporting similarly poor SMB/DFS performance of down to 2MB/s, so it would seem this is still an issue.
In our case, waiting for Local Broker seems the only option for on-premises users, but this performance will also be unacceptable for our off-premises users.
+4
- One of the older posts referenced EDNS as a potential issue. If you are an older Netskope customer, I would recommend reaching out to support, CSM, or your SE and ensure the Global Server Load Balancing (GSLB) is enabled for your tenant. This will ensure the that the clients and publishers are choosing the most performant Netskope PoPs based on packet round trip times as opposed to physical locations.
- One of the earlier posts by
@elawaetz mentioned SMB/DFS performance issues. In this case, we need to know if the SMB shares are distributed across multiple physical locations. If that is the case, private apps should be created for each SMB server so they can be tied to their local publisher. For example: SMB server A should be mapped to publisher A at site A. SMB server B should be mapped to publisher B at site B. If this isn’t done, you may be running into a scenario where Publisher A is trying to access SMB server B at site B. This will cause unintended latency. You can find greater detail on this configuration here - https://docs.netskope.com/en/netskope-private-access-for-smb-and-dfs-services/ - If you have configured GSLB and specific apps for your SMB/DFS shares and are still experiencing slow performance, contact support or an SE so we can validate the location of your egress IP addresses is correct in the IP databases used by GSLB.
+4
We’re running GSLB since the start, SMB/DFS servers are configured individually with local publishers, and we still see a significant reduction in the speed of SMB across NPA due to the increased RTT.
We have worked at length both with the product team, and with support on this, since we saw the first reports on SMB taking a performance hit.
In our case we have deployed Local Broker at our major sites to work around the issue.
I ran a series of tests to verify Local Broker performance, using iperf3 to baseline, and “robocopy” to/from a single SMB share over 1Gbps wired LAN:
With Iperf3 we saw an average thru’put across all tests:
- LAN:938Mbps
- Local Broker: 402Mbps
- Cloud Broker: 210Mbps
With SMB we saw:
- LAN: 786Mbps
- Local Broker: 348Mbps
- Cloud Broker: 114Mbps
--Erik
Sign up
Already have an account? Login
Sign in or register securely using Single Sign-On (SSO)
Employee Continue as Customer / Partner (Login or Create Account)Login to the community
Sign in or register securely using Single Sign-On (SSO)
Employee Continue as Customer / Partner (Login or Create Account)Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.