Download as pdf or txt
Download as pdf or txt
You are on page 1of 3

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 is 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.
=== ====== ===== ====== ====== ===== =======

Some More:
Mostly This step is Missed ..
For Slowness Issues, Always understand Nature of Issue. This will entirely change the way you
need to troubleshoot
Nature of Issue
1. Slowness happens at some particular time
2. Slowness happens all the time throughout the day
3. Slowness happens quite randomly
4. Since when this Slowness is happening
5. What all is running Slow? Particular Application or All the applications
6. Wired users or Wireless users or Like everybody facing the slowness

You might also like