Troubleshooting remote site/branch office application slowness issues

If you receive a complaint of slow performance from remote site, you may perform below steps:

   First of we will try to identify if the issue is with single user or multiple users in office.

1.        If it is for single user and working fine for everyone else in same vlan, we will identify the port where user machine is connected.

a.       Check for any errors on port which may indicate a physical layer problem, then will try to swap the connection to any other port

b.      if that doesn’t resolve, will replace the cable.

c.       If any hands and feet support engineer is available at site, we may ask onsite engineer to connect his laptop and test. If it works fine on his machine, then there may be issue with user machine. We will inform customer get his machine checked for any virus/malware/memory/NIC card issues.

2.       If the issue is with multiple users, then we will check for WAN link utilization.

3.       If WAN link utilization is normal, we will try to identify if the users belong to single vlan/switch/module/stack etc and try to isolate any local site hardware/cpu/layer-1 level fault.

a)   In parallel, we will also check for WAN links for any errors , ping/trace result for any packet drop/latency and if there are any, we will need to follow up with ISP.

b)                        If there are no WAN errors and utilization also normal, and users machines are not connected to single common hardware but still there are issues of performance, we will follow up with application owner /cloud provider to identify if there are any application or server side issues.

4.       If utilization is high and we have netflow enabled, we will try to identify which traffic is causing high utilization.

5.       If the traffic is legitimate, then it may require a bandwidth upgrade or QOS to be implemented to prioritize the traffic.

6.       If the traffic is not legitimate, then we may consider blocking some traffic.

7.       If the bandwidth utilization is normal, and there are no issue at application level but still performance is slow then we will ask users to provide trace/ping result to see which hop is causing latency.

8.       If the hop which is showing latency is our managed, we will try to isolate issues like CPU utilization, or any other factor like physical layer issue and try to resolve them.

9.       If that hop is ISP managed, we will follow up with ISP to troubleshoot this further.

10.   If application/cloud owner, ISP and we are unable to find any issue by above mentioned steps, then we may need to go traffic capture/debug with all stakeholders in a call to check for any Layer 4 troubleshooting like TCP retransmits/Handshake failure etc.