Something is eating the link.
Nobody will admit to it.
This is the most-asked question in network operations, and it has a genuinely easy answer — right up until the moment the answer turns out to be "nothing much".
Flow records answer this directly. Every router and switch worth the name can export NetFlow, sFlow or IPFIX: one record per conversation, with source, destination, port, protocol and byte count. Collected and resolved against your device inventory, that becomes a ranked list of applications, users and servers by consumption, for any interface and any window. The harder case is when the list shows nothing unusual and the link is still slow — at which point the question was never really about bandwidth, and flow records cannot help.
Six things that turn out to be responsible.
A backup or replication job that moved
Someone changed a schedule, or a job that used to finish by 6am now runs into the working day. This is the single most common answer, and it is usually nobody's fault.
Look for: consumption with hard start and stop times that line up with the hour.
One host doing something unexpected
A misconfigured agent, a sync client pointed at the wrong share, a workstation that has become a file server for a team. Small in count, large in volume.
Look for: a single address well outside the normal distribution for its peer group.
Video, in both directions
Conferencing and streaming are elastic — they expand to use what is available and back off when it is not. That makes them look like the cause when they are frequently just the most visible symptom.
Look for: whether the video degraded too. If it did, it is a victim rather than a culprit.
Cloud sync nobody approved
Personal file-sync clients on managed devices, or a departmental SaaS tool that syncs continuously. Individually small, collectively significant, and invisible until someone looks.
Look for: many hosts talking to the same external destinations outside working hours.
East-west traffic nobody was watching
Server-to-server traffic inside the data centre is usually the largest volume on the network and the least monitored, because the WAN link is what everyone instruments.
Look for: whether your flow coverage includes internal paths, or stops at the perimeter.
Nothing. It is not bandwidth.
The list is unremarkable, the link has headroom, and it is still slow. This is the case where the question changes from "who is using it" to "why is it taking so long" — and the answer moves down to the packet layer.
Look for: retransmissions, latency and interface discards. If the link is not overloaded, capacity was never the problem.
Four steps, and one thing to do when they come up empty.
- 1
Turn on flow export where it matters
WAN links and the main junctions first. Universal coverage is unnecessary and expensive; the paths that carry contested traffic are what count.
- 2
Resolve addresses to names
A ranked list of IP addresses is barely more useful than no list. Joined against your device inventory and DNS, the same data becomes a list of people and applications.
- 3
Compare against the same hour last week
Absolute volume rarely means much on its own. Change does. The top talker that was not there last Tuesday is the interesting one.
- 4
If nothing stands out, stop looking at volume
An unremarkable list on a slow link is itself a finding: it rules out capacity and moves the question to latency, loss and errors.
Top talkers, and what the packets add.
Discovered devices
| DEVICE | TYPE | PORTS | LOAD |
|---|---|---|---|
| core-1 | Router | 48/48 | 62% |
| core-2 | Router | 48/48 | 55% |
| dist-3 | Switch | 96/96 | 71% |
| acc-3 | Switch | 46/48 | 94% |
| acc-4 | Switch | 48/48 | 38% |
Physical map
WAN-1 utilisation
38%
WAN-2 utilisation
41%
Response time
480ms
Conversations on this link
LINK ONLY 38% USED
- Backup replication10.4.18.2234%
- File share (SMB)10.4.2.5124%
- Video conferencing10.4.9.14017%
- Database sync10.4.31.812%
- Everything else—13%
- Retransmit storm on Gi0/3acc-3
Sniffer recording packets · +412% vs baseline · duplex mismatch suspected
9614:36 - Unusual east-west conversation10.4.18.22
NetFlow · new peer pair, 3.1 GB in 20 min, off-hours
7114:22 - Latency drift on WAN-2core-2
SNMP + sniffer recording packets · RTT trending up 6 hours
6411:08 - Baseline re-learneddist-3
Model updated after sustained topology change
1209:41
Recent configuration changes
142 DEVICES BACKED UP · 2 DRIFTED
- OFF BASELINE
interface Gi0/3 speed 100 → auto
acc-3 · n.levi · 14:31
ACL 120 — 2 lines added
core-1 · automation · 11:55
VLAN 340 created
dist-2 · m.cohen · Yesterday
- OFF BASELINE
SNMP community updated
acc-5 · n.levi · Yesterday
Illustrative views representing Net-Monitor output.
Where flow records stop
- Flow counts bytes; it does not measure time. It will never tell you why a transfer was slow, only how large it was.
- Sampling misses the small and the rare. sFlow scales beautifully and is the wrong tool for finding one short conversation that mattered.
- Net-Monitor collects flow and records the packets. When the ranked list explains it, the answer is one click away; when it does not, the layer that can explain it is already recorded.
Short answers.
How do I find what is using bandwidth on my network?
Enable NetFlow, sFlow or IPFIX on the routers and switches carrying the link in question, collect the records centrally, and rank conversations by volume for the window you care about. Resolved against your inventory this gives you application, user and server rather than a list of addresses.
Can I do this without NetFlow?
Partly. SNMP tells you how busy an interface is but nothing about who is on it. A packet capture gives you the same answer as flow and much more besides, but only at the points where you capture. In practice flow is the cheapest way to get broad coverage of the "who" question.
Why is the link slow when nothing is consuming much?
Because capacity and speed are different things. Retransmissions, a queue that fills in bursts, high latency or a physical error on a port all cost time without costing throughput. When the ranked list is unremarkable, that is a strong signal to stop looking at volume entirely.
Does this work for internal server-to-server traffic?
It does, provided flow export is enabled on the internal paths and not only at the perimeter. East-west traffic is usually the largest volume on the network and the most commonly unmonitored, which is why it produces so many surprises the first time anyone looks.
Want the ranked list for your own network?
We can usually produce it inside a demo, and it almost always contains one surprise.