TUTORIAL

How to Show Where a Network Slowdown is

by Erik Mikac

Choppy VoIP calls, slow websites, stalled downloads? These are all signs of a slow network. The tricky part is figuring out why it’s slow. This guide walks you through a simple, repeatable process to isolate the cause and get your network moving again.

Project Overview

EXPERIENCE LEVEL: Intermediate

TIME TO COMPLETE: 2-4 hours, depending on the network size and issue complexity

ESTIMATED COST: Free (using built-in OS tools); optional paid tools like SolarWinds (~$1,500/year for basic licenses) or Wireshark (free)

By the end of these eight steps, you’ll know whether the slowdown is in your local setup or somewhere upstream.

Step 1: Confirm the Slowdown Is Network-Related

Before blaming the network, rule out issues on the end-user devices. Start by checking the basics on the affected computer or device. 

• Open Task Manager on Windows (Ctrl + Shift + Esc) or Activity Monitor on macOS (Command + Space, search for "Activity Monitor") 

• Look at CPU, RAM, and disk usage. If the CPU is pegged at around 100% or RAM is maxed out, the slowdown might be local. 

• If so, close unnecessary apps or restart the device.

Here is an example of CPU at 60%. If it’s that high consistently, that could be a problem. At 100%, it’s absolutely a problem.

Next, test on multiple devices. If only one laptop is slow, but a phone or another computer on the same network is fine, it could be device-specific, like a faulty NIC or malware. Connect a different device to the same port or WiFi and compare. 

Finally, run a speed test for baseline data. Go to a site like speedtest.net in your browser. Note the download/upload speeds, as well as the ping time. Compare against your ISP's promised speeds—if it's way off, you have quantifiable proof.

This step ensures you're not chasing ghosts; it takes 10–15 minutes.

Step 2: Identify the Affected Scope

Now that you've confirmed it's network-related, narrow down if it's local (LAN), wide-area (WAN), or internet-wide. Ask users questions like: "Does it happen at specific times, like peak hours?" or "Is it worse in certain offices or rooms?" Patterns like these may indicate overloaded servers during backups or interference in a specific area. 

Test wired vs. wireless. Plug in an Ethernet cable if possible and re-run the speed test. If wired is faster, suspect WiFi issues (which we'll cover later). If both are slow, it could be due to a deeper issue in the network. 

To check scope, try accessing internal resources (like a local file server) vs. external ones (like cloud storage or Google Drive). If internal connections are fine but external connections lag, the problem might be at the gateway or ISP.

Document your findings in a notepad or spreadsheet; this will help you in later steps. Expect this to take 20–30 minutes and may involve user interviews. 

Step 3: Use tracert or traceroute

Traceroute tools map a packet’s path to its destination, highlighting delays at each hop. On Windows, open Command Prompt (search "cmd" in Start) and type: tracert google.com. On macOS/Linux, use Terminal and traceroute google.com. 

The output displays each router (hop) along with its response times in milliseconds. Look for hops where latency spikes (e.g., from 10 ms to 200 ms) or asterisks (*) indicating dropped packets. 

If high latency starts inside your network (first few hops), it's local—check your router. If it's after your ISP's gateway, escalate to them.

The asterisks are not packet losses in this case, it's probably control plane filtering or rate limiting.

Run it multiple times to spot inconsistencies. This step reveals the "where" quickly, usually in 5–10 minutes.

Step 4: Ping for Packet Loss and Latency

Ping sends test packets to check reachability and speed. In the Command Prompt or Terminal, ping your local router: ping 192.168.1.1 (replace with your router's actual IP address). Then ping an external site: ping 8.8.8.8 (Google DNS). 

Look at round-trip times (average under 50 ms is good for local) and packet loss (0% ideal). If the loss is high, cables or hardware might be faulty. For intermittent issues, use continuous ping: on Windows, ping -t 8.8.8.8; on macOS/Linux, ping 8.8.8.8. 

Press Ctrl + C to stop and review stats.

Compare local vs. remote pings. If local is fine but remote drops packets, the issue is upstream.

This takes 10–20 minutes of monitoring.

Step 5: Check Device Utilization and Uptime

Overloaded or faulty network hardware can cause slowdowns in network performance. Access your router or switch via web interface (If your ISP permits, type 192.168.1.1 in a browser. It should open) or CLI (SSH/Telnet if enabled). 

Check CPU and memory usage—anything over 80% sustained is a red flag. Use SNMP tools, such as SolarWinds NPM (if available), to monitor interface errors or utilization. In the CLI, commands like 'show interfaces' on Cisco devices reveal drops or CRC errors.

Then check uptime. If a device hasn't rebooted in months, restart it during off-hours. This clears temporary glitches.

Inspect logs for errors. This step might require admin access and takes 30–45 minutes.

Step 6: Monitor Bandwidth Usage

Next, you want to identify if something is hogging bandwidth. Install Wireshark (available for free from wireshark.org) and capture traffic on your interface. Filter for high-volume protocols, such as HTTP or UDP. 

Tools like ntopng (open-source) or SolarWinds provide dashboards that show top talkers by IP or application. Look for patterns: Is a backup server flooding the network at night? Or unauthorized streaming from a user?

This is on Mac, but this is roughly what you’ll see when running netstat -b.

I obfuscated a lot of data here (Behold, the power of stream editor). If, for some reason, you ever want to do the same on Mac, run this command in your Terminal:

ME=$(id -un)
sudo lsof -iTCP -sTCP:ESTABLISHED -n -P \
| perl -pe 's/\b((?:\d{1,3}\.){3}\d{1,3})\b/[IP]/g; s/:(\d{2,5})/:PORT/g' \
| perl -pe "s/\\b$ME\\b/[USER]/g" \
| column -t

Drill into specific IPs. Use the netstat -b command on Windows to view application connections. Mitigate by throttling or blocking. This analysis can take 45–60 minutes.

Step 7: Inspect Wireless Network Conditions

If WiFi is involved, interference or config issues are common culprits. Use inSSIDer or the WiFi Analyzer app on Android to scan channels. Look for overlap (e.g., multiple networks on channel 6) or weak signal (-70 dBm or worse is poor). 

Check the access point (AP) load by logging into your router and seeing connected devices. If an AP has 50 or more clients, it's overloaded; you'll want to redistribute or add more. 

Then test for interference. Move the AP away from microwaves or cordless phones. Switch channels if needed.

Reconfigure for 5 GHz if possible; it's faster and less crowded. This step, including scans, takes 20–40 minutes.

Step 8: Document and Report Your Findings

Compile everything into a report. Create a network diagram using tools like Visio or draw.io to map the network path, marking latency points (e.g., an arrow from the router to the ISP with "200 ms delay"). 

List affected areas: "Subnet 192.168.1.0/24 slow due to high utilization on switch port 5." If internal, fix it; if external, contact ISP with data like traceroute outputs.

Share this with stakeholders via email or ticket. This finalizes the process and typically takes around 30 minutes.

Final Thoughts

By following these eight steps, you’ll not only fix the current slowdown—you’ll also sharpen a repeatable troubleshooting playbook you can rely on in future incidents. Consider adding long-term monitoring tools to spot bottlenecks before users do, and maintain detailed documentation to build a knowledge base for yourself and your team.

Want to learn more? Deepen your network skills by checking out our Cisco Network Troubleshooting course. The hands-on labs are fantastic. For more guides, visit our tutorials page.