From a slow link to a named offender in an afternoon: confirm saturation with SNMP, then use flow data to find top talkers, no packet snooping.
The short version
- Before you blame anyone, confirm there's actually a problem at the wire.
- SNMP tells you that the link is full.
- Once you've named the offender — a user bulk-syncing a large cloud backup, a server running unscheduled updates, a video-conferencing room left on a persistent stream — you have three practical options.
01Confirm the Link Is Actually Saturated
Before you blame anyone, confirm there's actually a problem at the wire. Pull up your WAN interface in LibreNMS, PRTG, or even a basic SNMP poller and look at the last 24 hours of throughput graphs. What you're looking for is sustained interface saturation — periods where inbound or outbound traffic hugs the ceiling of your provisioned capacity. A momentary spike is normal; a plateau that holds for minutes at a time is what users feel as "slow." Note the times, note the direction (download-heavy suggests streaming or large file sync; upload-heavy often points to backup jobs or video calls), and note roughly how far over comfortable utilisation the link is running. That's your evidence. Now you can go hunting with something other than gut feeling.
02Drop to Flows and Find the Top Talkers
SNMP tells you that the link is full. It tells you nothing about who is filling it. For that, you need flow data — NetFlow, sFlow, or IPFIX records exported from your router or firewall. Most business-grade routers (Cisco, MikroTik, Juniper) and open-source firewalls like pfSense and OPNsense support at least one of these standards. The device summarises each conversation — source address, destination address, ports, bytes transferred — and ships those records to a collector, without ever copying a single byte of actual content. You're working with metadata: volumes and endpoints, not payloads. That's the right side of the privacy line for routine usage monitoring.
Feed those records into an analyser. ntopng, ElastiFlow, or even the built-in flow analysis in PRTG will rank your hosts by traffic volume inside the window you identified. Within a few minutes of query time you'll have a sorted list: your top talkers. The top of that list is almost always instructive. In most office networks, a handful of hosts — or even a single one — account for a disproportionately large share of total traffic during a congestion event. A private IP address, say 192.168.1.45, pulling down several gigabytes between 09:00 and 11:00 on a Tuesday morning is a lead worth following.
Cross-reference the IP against your DHCP leases or Active Directory to get a hostname and, usually, a username. Then look at the destination port and IP. Port 443 to a Google or Microsoft ASN is probably Drive or OneDrive sync; a large outbound stream to an unfamiliar IP on a high port might be a backup agent hitting cloud storage. Many flow analysers will attempt application identification using port heuristics or SNI data captured at the firewall — the hostname a device sends in the clear during a TLS handshake, before any encryption kicks in. That SNI field often resolves "mystery traffic on 443" into a recognisable service name without requiring you to decrypt anything.
Maximum visibility into how much and where to, zero visibility into what's inside. For routine bandwidth management, you never need the latter.
03Shape, Schedule or Leave It
Once you've named the offender — a user bulk-syncing a large cloud backup, a server running unscheduled updates, a video-conferencing room left on a persistent stream — you have three practical options.
Shape it. If the traffic type is identifiable (backup, video streaming, large file transfers), apply a QoS policy that deprioritises it during business hours. Most managed switches and firewalls let you set bandwidth limits per IP or per DSCP class. The link stays usable for everyone else while the heavy job still completes.
Schedule it. Many backup clients and sync tools let you restrict transfer windows to evenings or weekends. If the user or application is cooperative, this is often the lowest-friction fix — the data still moves, just when no one notices.
Leave it. Sometimes the investigation reveals that a "slow link" complaint coincided with a legitimate, one-off event: a large file sent to a client, a software deployment, a video all-hands. Saturation that is rare and explainable may not warrant any change at all. Document it and move on.
The whole workflow — SNMP graph, flow query, IP lookup, SNI inspection, decision — sits entirely in the metadata layer. No one's emails were opened, no packet contents were read. That's the discipline: maximum visibility into how much and where to, zero visibility into what's inside. For routine bandwidth management, you never need the latter.
| Option | When it fits | Effect |
|---|---|---|
| Shape it | Traffic type is identifiable (backup, streaming, bulk transfer) | QoS deprioritises it in hours; the link stays usable, the job still completes |
| Schedule it | The client or user is cooperative | Data moves to evenings or weekends — lowest-friction fix |
| Leave it | Rare, explainable, one-off saturation | Document it and move on; not every spike needs a policy |
