How To Monitor Network Bandwidth On Linux

What Does Network Bandwidth Monitoring Measure?

Bandwidth monitoring usually focuses on the amount of data entering and leaving a network interface over a period of time. Linux exposes cumulative byte and packet counters for each interface. Monitoring tools sample those counters, calculate the difference between readings, and convert that difference into a rate such as kilobits, megabits, or bytes per second.

Useful measurements include:

• Receive rate: Data entering the interface.
• Transmit rate: Data leaving the interface.
• Total bytes: Cumulative traffic since boot or since a monitoring database began collecting data.
• Packets per second: The number of packets processed during each interval.
• Drops and errors: Packets the interface or networking stack could not process successfully.
• Connection and process activity: The hosts, ports, applications, or processes responsible for traffic.

Monitoring is different from running an internet speed test. A speed test attempts to measure maximum throughput to a remote service. Bandwidth monitoring shows what the system is actually using. One asks, “How fast could this connection go?” The other asks, “Who is currently driving it like a stolen rental car?”

Step 1: Identify the Correct Network Interface

Before monitoring anything, determine which interface carries the traffic you care about. Modern Linux interface names often look like enp1s0, ens5, wlp2s0, or eth0.

List available interfaces

The abbreviated output shows interface names and their current state. Ignore lo unless you specifically want to measure loopback traffic between local applications.

Find the interface used for internet traffic

Look for the word dev in the output. The name immediately after it is the interface Linux would use to reach that destination.

On systems with bridges, VPN tunnels, containers, VLANs, or bonded adapters, several interfaces may report related traffic. Always confirm whether you need to monitor the physical device, the virtual interface, or both.

Monitor Bandwidth With Built-In Linux Commands

You do not always need to install another package. The kernel already maintains network statistics, and standard Linux utilities can expose them with very little overhead.

Use ip to view interface counters

Replace enp1s0 with your interface name. The output contains RX and TX byte totals, packet counts, errors, dropped packets, and other interface statistics.

To refresh the counters every second, combine the command with watch:

This is excellent for quick troubleshooting. Start a download in another terminal and watch the RX byte counter climb. Upload a file and the TX side should become more enthusiastic.

Read counters from procfs

The file lists cumulative receive and transmit statistics for every interface. It is especially useful in scripts, minimal containers, recovery systems, and embedded Linux environments where full monitoring applications may not be installed.

Read individual counters from sysfs

These files provide simple numeric values that are easy to collect with shell scripts. To calculate bandwidth, record a byte counter, wait for a known interval, read it again, and divide the difference by the number of seconds.

Inspect socket activity with ss

This command summarizes TCP, UDP, and other socket activity. It does not directly show total interface bandwidth, but it helps explain why traffic exists.

The more detailed command shows TCP connections, queue information, process details, and additional transport statistics. Large send or receive queues may indicate congestion, a slow application, or a remote endpoint that cannot keep up.

Check protocol counters with nstat

Use nstat when raw throughput is not the whole story. Counters such as TCP retransmissions, IP discards, and UDP receive errors can reveal packet loss or network-stack trouble even when the bandwidth graph appears normal.

Install Linux Bandwidth Monitoring Tools

On Debian and Ubuntu systems, a practical toolkit can be installed with:

Fedora and other RPM-based distributions commonly use:

Package availability varies. Some enterprise distributions require an additional approved repository for third-party utilities. Install only the tools you actually need; collecting monitoring programs like decorative refrigerator magnets is not mandatory.

Watch Real-Time Bandwidth With nload

nload is one of the easiest tools for watching incoming and outgoing traffic in real time.

Its terminal interface displays separate incoming and outgoing graphs along with current, average, minimum, and maximum rates. It also reports the total amount of transferred data observed during the session.

Use nload when you need a fast answer to questions such as:

• Is the interface currently busy?
• Is traffic mostly inbound or outbound?
• Did the transfer rate change after a configuration adjustment?
• Is the backup actually moving data, or merely thinking deeply about it?

The limitation is that nload reports interface-level activity. It does not identify the remote host or local process responsible for that traffic.

Monitor Multiple Interfaces With bmon

bmon, short for bandwidth monitor, displays traffic rates and counters for multiple network interfaces in a terminal-based interface.

Use the arrow keys to select an interface. Depending on the build and terminal layout, additional panels can show graphs, detailed counters, packets, errors, drops, and rate history.

bmon is particularly helpful on hosts containing physical interfaces, bridges, container networks, VPN tunnels, and virtual Ethernet pairs. Seeing all of them together makes it easier to understand how traffic moves through the machine.

However, do not add every displayed interface rate together without thinking. The same packet may appear on a physical interface, a bridge, and a container-side virtual interface. Summing all three would count one journey several times.

Find Top Hosts and Connections With iftop

iftop is similar to the Unix top command, except it ranks network conversations instead of CPU-consuming processes.

The options in this example:

• -i enp1s0 selects the interface.
• -n disables hostname lookups, reducing DNS delays and visual clutter.
• -P displays port numbers.

The display shows source and destination endpoints, recent transfer rates, and traffic totals. It is ideal when a server is using unexpected bandwidth and you need to identify the remote systems involved.

Because iftop observes packets, it usually requires elevated privileges. It also shows flows rather than application names. If the top conversation connects to a content-delivery network, you may know where the traffic is going but still not know which local program ordered the buffet.

Find Bandwidth-Hungry Processes With NetHogs

NetHogs groups network traffic by local process instead of by host or protocol.

The display normally includes the process ID, user, program, interface, sending rate, and receiving rate. It is one of the quickest ways to answer, “Which application is consuming the bandwidth?”

Common discoveries include:

• A backup agent uploading far more data than expected.
• A package manager downloading updates.
• A browser tab streaming video in the background.
• A containerized service repeatedly fetching the same resource.
• A compromised or misconfigured process contacting unfamiliar systems.

NetHogs is primarily a live diagnostic tool. If a traffic spike occurred at 3:00 a.m. and the offending process has already exited, historical monitoring or flow logging will be more useful.

Track Historical Bandwidth Usage With vnStat

Real-time tools are useful only when you are watching. Network incidents, naturally, prefer to happen when you are making coffee. vnStat solves that problem by storing interface traffic totals over time.

Enable and start its service:

View the standard summary:

Select a specific interface:

Review daily and monthly totals:

Watch a live sample:

vnStat reads kernel interface counters rather than capturing packet contents. This keeps resource usage low and avoids storing payload data. It is a strong choice for VPS traffic accounting, home internet tracking, monthly transfer limits, and long-running servers.

Remember that vnStat begins building useful history only after installation. It cannot travel backward in time, no matter how politely you ask.

Analyze Current and Historical Traffic With sar

The sar command is part of the sysstat package. It can report live network activity and read previously collected system activity files.

Sample interface traffic every second

This produces 10 reports at one-second intervals. Important columns include received and transmitted packets per second, kilobytes per second, multicast traffic, and interface utilization where available.

Inspect network errors

The error report highlights receive and transmit errors, collisions, drops, overruns, and related problems. High throughput with no errors may simply mean the link is busy. Rising errors or drops suggest a more serious issue.

Enable historical collection

Service names and default collection settings vary among distributions. Once collection is enabled, archived activity files are commonly stored under /var/log/sa or /var/log/sysstat.

sar becomes especially valuable when investigating statements such as, “The server was slow yesterday afternoon.” Instead of staring into the middle distance, you can review what the network was actually doing.

Check Hardware-Level Statistics With ethtool

When interface counters show drops or errors, inspect the network adapter and driver statistics:

The exact counters depend on the driver and hardware. You may see CRC errors, missed packets, queue drops, timeout events, allocation failures, pause frames, or ring-buffer statistics.

Also check negotiated link settings:

A server expected to use a gigabit link but negotiating at 100Mb/s will have a very convincing bandwidth problem. Duplex mismatches, faulty cables, switch-port issues, and exhausted receive queues can also create poor performance without producing an obvious application error.

Build Long-Term Dashboards With Prometheus and Grafana

For one server, a terminal command may be enough. For dozens or hundreds of Linux hosts, use a time-series monitoring system.

Prometheus Node Exporter exposes host and kernel metrics, including cumulative network bytes, packets, errors, and drops. Prometheus stores those counters, while Grafana can turn them into dashboards and alerts.

Example Prometheus queries for bits per second are:

The rate() function calculates how quickly a cumulative counter is increasing. Multiplication by eight converts bytes per second into bits per second.

Useful alerts include:

• Sustained utilization above a chosen percentage of link capacity.
• A sudden increase in receive or transmit errors.
• Packet drops persisting for several minutes.
• A server whose traffic deviates sharply from its normal baseline.
• Unexpected traffic on a normally quiet interface.

For container-level monitoring, cAdvisor can expose network byte counters for individual containers. For deeper traffic visibility by host, flow, protocol, or application category, a platform such as ntopng may be more appropriate.

Understand Bits, Bytes, Rates, and Interface Utilization

One of the easiest ways to misread network monitoring data is to confuse bits and bytes.

• 1 byte equals 8 bits.
• MB/s usually means megabytes per second.
• Mb/s or Mbps means megabits per second.

A transfer running at 100MB/s uses roughly 800Mb/s before accounting for protocol overhead. That is already a substantial portion of a 1Gb/s link.

Also remember that advertised link speed is not identical to usable application throughput. Ethernet framing, TCP/IP headers, encryption, retransmissions, storage performance, congestion, and application behavior all affect the result.

When estimating utilization, use this basic formula:

A 700Mb/s transfer on a 1Gb/s interface represents approximately 70% utilization. On a 100Mb/s interface, the same attempted workload represents a small networking tragedy.

A Practical Linux Network Troubleshooting Workflow

1. Confirm the active interface. Use ip -br link and ip route get.
2. Check immediate utilization. Run nload, bmon, or sar -n DEV 1.
3. Identify remote endpoints. Use iftop or inspect connections with ss.
4. Identify local applications. Run NetHogs.
5. Check drops and errors. Review ip -s link, sar -n EDEV, nstat, and ethtool -S.
6. Review history. Consult vnStat, sar archives, or a time-series dashboard.
7. Compare against link capacity and normal behavior. A busy interface is not necessarily unhealthy.
8. Change one thing at a time. Repeat the same measurement after each adjustment.

Experience-Based Lessons From Monitoring Linux Bandwidth

The interface with the most traffic is not always the guilty one

On a simple laptop, selecting an interface is easy. On a server running Docker, Kubernetes, a VPN, or Linux bridges, the same traffic can appear in several places. A download may enter through ens5, pass through docker0, and continue through a virtual Ethernet pair. Looking at only one interface can hide part of the journey; adding every interface together can count it repeatedly.

A reliable investigation begins with the routing table and the system’s network topology. Monitor the external interface for total host traffic, then examine bridge or container interfaces when you need workload-level detail.

A full link and a broken link can look surprisingly similar

Applications often report both conditions as “the network is slow.” Monitoring reveals the difference. A healthy saturated link shows high throughput with relatively stable packet rates and few errors. A damaged or poorly configured link may show lower throughput accompanied by retransmissions, dropped packets, CRC errors, or growing queues.

This is why a bandwidth graph should never stand alone. Pair throughput data with errors, drops, TCP retransmissions, latency, and application response time. One graph tells you the road is crowded; the others tell you whether the road has potholes, missing signs, or a truck parked sideways across all lanes.

Short averages can exaggerate drama

One-second samples are excellent for observing bursts. They are less useful for deciding whether a link needs an expensive upgrade. A backup job may briefly fill a 10Gb/s interface and then remain quiet for the next hour. That peak matters for latency-sensitive workloads, but it does not automatically mean average capacity is insufficient.

Use several time windows. A one-second view reveals bursts, a five-minute view reveals sustained pressure, and daily or monthly reports reveal capacity trends. Alerting should normally require a condition to persist long enough to matter. Otherwise, the monitoring system becomes the digital equivalent of a smoke detector that screams whenever someone makes toast.

Historical data usually solves the mystery faster

Running iftop after a spike has ended is like arriving at a party after everyone has gone home and interrogating the furniture. Live tools cannot reliably identify a process that no longer exists.

For important servers, enable historical collection before an incident occurs. vnStat provides lightweight traffic totals, sar preserves broader system activity, and Prometheus supplies queryable time-series data. Add process, container, or flow-level telemetry where accountability matters.

A useful dashboard should answer four questions: when did traffic increase, which interface carried it, which host or workload caused it, and did errors or latency rise at the same time? When those answers are available in one place, troubleshooting becomes analysis rather than archaeology.

Baseline normal traffic before declaring an emergency

Every system has a personality. A web server may have strong outbound traffic, a backup target may be mostly inbound, and a database replica may produce predictable bursts throughout the day. Without a baseline, normal behavior can look suspicious simply because the numbers are large.

Collect at least several days of data, including busy periods and scheduled jobs. Record expected backup windows, synchronization tasks, software updates, and batch processing. Then alert on sustained capacity, unexpected timing, abnormal direction, or deviation from the usual pattern. Context turns raw bandwidth statistics into useful operational information.

Conclusion

Linux offers bandwidth monitoring options for every level of investigation. Start with ip -s link or /proc/net/dev for dependable kernel counters. Use nload or bmon for real-time interface activity, iftop for top network conversations, and NetHogs for process-level usage. Add vnStat or sar when historical evidence matters, and deploy Prometheus with Grafana when multiple systems need centralized dashboards and alerts.

The most effective approach combines throughput, errors, connections, processes, and history. Bandwidth alone tells you that traffic exists. A complete monitoring workflow tells you where it came from, whether it is healthy, and whether someone scheduled another giant backup during business hours.