How to identify and control bandwidth hogs on your network

The five steps below help you find the cause quickly and fix it without disrupting legitimate work.

Step 1. Confirm that a link is actually full

Before hunting for a culprit, check the utilization of the link users depend on, measured against its real capacity. If the internet or WAN link is running near its limit, you are looking for a hog. If it is well below capacity and applications are still slow, the cause is more likely distance, packet loss, Wi-Fi, or the application itself, and removing traffic won't help. Our guide on what bandwidth management cannot fix covers those cases.

Step 2. Find the top talkers

Once you know which link is congested, look at the flow data for that interface over the window when users noticed the slowdown. Sort it three ways, because each view answers a different question.

• Top applications show what kind of traffic is filling the link.
• Top hosts show which devices are sending or receiving the most.
• Top conversations pair a source with a destination, which usually points straight at the cause, such as one workstation exchanging gigabytes with a single cloud storage address.

If the spike has already passed, the same views over the earlier time window show what happened, as long as your tool keeps detailed historical flow data. Keep that window narrow and centered on the slowdown. Sorting top talkers by total volume over a whole day often puts the overnight backup server at the top, which says nothing about what users were struggling with at 11 a.m. Narrow the time range to the minutes when the problem occurred, and the real cause becomes much easier to spot.

Step 3. Identify who is behind it and why

An IP address is rarely enough to act on. Map it to a username or device owner through your directory or DHCP records, then find out what the traffic is. Flow data tells you what is moving and where, but not the reason. A quick conversation often reveals a scheduled job that drifted into business hours, a sync client re-uploading a whole folder, or a large transfer that simply needs a later start time.

Step 4. Control it with the lightest fix that works

Blocking traffic is rarely the right first move, because the traffic may be legitimate work running at the wrong time or speed. Start with the least disruptive option and escalate only if needed.

1. Reschedule. Move backups, large syncs, and bulk transfers outside business hours.
2. Cap the application or host. Apply a rate limit or traffic shaping policy to the specific application, user, or device, so it can keep running without filling the link. For the difference between the two, see traffic shaping vs bandwidth throttling.
3. Protect everything else. Make sure voice, video, and business applications have priority, so that whatever is left over goes to bulk traffic.
4. Block only as a last resort, for traffic that is clearly unauthorized.

Step 5. Stop it from happening again

Fixing today's hog is half the job. The other half is making sure the next one is caught before users notice.

• Set alerts on share, not just totals. An alert that fires when a single application takes more than a set share of a link, for example 40% during business hours, catches a runaway transfer early without firing on every busy afternoon.
• Let baselines catch the unusual. Pattern-based alerts that learn normal usage flag a spike that is out of character for that link or time of day, even when it stays below a fixed threshold.
• Review repeat offenders. A weekly report of top hosts and applications shows which jobs, teams, or devices keep reappearing, so you can fix the cause rather than the symptom.
• Put it in writing. If the same type of traffic keeps causing trouble, add it to your network bandwidth policy, so expectations are clear before the next incident.

Frequently asked questions