How to Monitor Ethernet Traffic Linux Like an SRE

At 3 a.m., an alert reports high database latency. The host's interface graphs look ordinary, byte counters are moving, and no obvious link error appears in the dashboard. Yet the application is failing. The problem may not be bandwidth saturation at all. It may be a burst of broadcasts, malformed ARP behavior, retransmissions, or a workload hidden behind a shared bridge.

That's why reliable Linux traffic inspection needs more than a single command. Counter-based tools explain how much traffic crossed an interface, packet capture shows what those frames contain, and eBPF telemetry provides a lower-overhead way to observe busy production systems. The right choice depends on the incident question, the traffic rate, and how much overhead the host can tolerate.

Table of Contents

• The 3 a.m. Interface Mystery
  • What counters miss
• Prerequisites and Picking the Right Interface
  • Find the interface that carries the traffic
• Capturing Packets With tcpdump and tshark
  • Use tshark for repeatable dissection
• Counters, Statistics and Live Bandwidth Tools
  • Match each tool to the incident question
• When Capture Is the Wrong Tool eBPF and Kernel Telemetry
  • Start with a narrow probe
• Continuous Ethernet Monitoring and Alerting
  • Export rates, not just totals
• Picking the Right Tool for the Job
  • A practical incident checklist

The 3 a.m. Interface Mystery

At 3 a.m., ip -s link show dev eth0 reports ordinary received and transmitted bytes. The operations dashboard, built from SNMP interface counters, looks calm too. Meanwhile, database connections stall and application requests time out.

The missing evidence sits at layer two. Interface counters expose packet and byte totals, drops, and errors, while Linux also provides protocol-specific views and driver-defined statistics through ethtool. Those views describe the NIC from different angles, but aggregate counters cannot show whether the traffic is ordinary application data, repeated ARP requests, unexpected broadcasts, or frames sent to an unfamiliar MAC address.

A short capture changes the diagnosis. It shows a stream of broadcast ARP requests arriving from a virtualized segment. The byte rate is too small to make the graph look alarming, yet the traffic consumes host processing time and competes with the database workload. Counters answered “how much moved?” Packet inspection answered “what was moving?”

What counters miss

Packet capture preserves details that sampled or aggregate telemetry discards:

• MAC-level behavior, including Ethernet frame sender and destination addresses.
• Broadcast and multicast patterns, which can indicate storms or misconfigured services.
• ARP activity, including repeated requests that produce little useful application-level signal.
• Protocol symptoms, such as TCP retransmissions, resets, and failed handshakes.
• VLAN context, which matters when logical networks share one physical interface.

SNMP IF-MIB counters and RMON-style history provide a durable model for sampled interface monitoring. Administrators can query values such as ifInOctets and ifOutOctets, while RMON history retains periodic utilization, error, and packet information for later trend analysis (SNMP interface accounting and RMON history). That model supports capacity planning and alert thresholds, but it cannot replace forensic visibility.

Practical rule: Use counters to identify an unhealthy interface. Use packets to establish the cause.

Production monitoring needs both layers, plus a clear boundary for eBPF. Continuous counters supply inexpensive history and alerting. Targeted capture provides incident evidence, but packet capture can become expensive at high rates because each frame reaches userspace. eBPF telemetry observes selected kernel and network events with less per-packet overhead, making it a better fit for busy hosts when full payload inspection is unnecessary. No single approach answers every question. Capture explains content, counters show sustained volume, and eBPF helps monitor production behavior without turning an investigation into another outage.

Prerequisites and Picking the Right Interface

Capture commands fail for simple reasons before they fail for interesting ones. tcpdump and tshark generally need root privileges or suitable capabilities, especially CAP_NET_RAW and CAP_NET_ADMIN. On Debian-family systems, a restricted capture setup may also place the operator in the wireshark group, but group membership alone doesn't guarantee access to every interface or namespace.

Check the current identity and capabilities before starting:

id
getcap "$(command -v tcpdump)"
getcap "$(command -v tshark)"

If the tools aren't installed, use the distribution's package manager and follow the local security policy. Avoid making packet capture permanently run as root when a narrower capability or controlled administrative workflow is sufficient.

Find the interface that carries the traffic

Interface names aren't interchangeable. A physical NIC may appear as eth0, ens5, or eno1; a bonded device may be bond0; a bridge may represent the path used by virtual machines. Start with compact listings:

ip -o link show
ip -br addr

The address listing helps identify where the relevant service is attached. The link listing shows devices that may not carry an IP address, including lower-level members of a bond or bridge. For a physical port, ethtool --identify can blink the corresponding hardware indicator when the driver supports it:

sudo ethtool --identify ens5

Loopback traffic requires -i lo. VLAN subinterfaces need the VLAN device or an appropriate parent capture. When the path is uncertain, -i any offers a broad first look, though explicit interfaces produce cleaner evidence and more predictable packet visibility. Container traffic may live in another network namespace, so the host operator may need nsenter against the relevant process before inspecting its interfaces.

Finish with a small sanity check rather than launching a large capture immediately:

sudo tcpdump -i eth0 -c 5 -nn

If that returns nothing, the result may be correct, or the selected interface may be wrong. Confirm the path before changing filters.

Capturing Packets With tcpdump and tshark

tcpdump is most useful when the capture filter reflects a concrete incident question. A focused capture keeps files manageable and avoids collecting unrelated payloads:

sudo tcpdump -i eth0 -nn -s 0 \
  -w capture.pcap \
  'host 10.0.0.5 and port 443'

The -nn option prevents name and service lookups, -s 0 preserves the full packet where supported, and -w writes a file for later analysis. The filter restricts capture at the BPF layer, before the output becomes a wall of terminal text.

Ethernet filters are valuable when the symptom looks like a switching or addressing problem:

sudo tcpdump -i eth0 -nn \
  'ether src host aa:bb:cc:dd:ee:ff'

sudo tcpdump -i eth0 -nn \
  'ether broadcast or ether multicast'

sudo tcpdump -i eth0 -nn \
  'vlan 100'

ARP and broadcast filters are particularly useful for suspected storms:

sudo tcpdump -i eth0 -nn \
  'arp and broadcast'

Promiscuous mode lets a capture see frames that aren't addressed to the host, subject to the switch and virtualization path. It isn't the same as wireless monitor mode. Monitor mode is a wireless-driver capability used to receive raw 802.11 frames, and standard Ethernet capture with tcpdump doesn't provide it.

Use tshark for repeatable dissection

Once a capture exists, tshark can apply display filters without collecting another file:

tshark -r capture.pcap \
  -Y 'tcp.analysis.retransmission'

tshark -r capture.pcap \
  -Y 'tcp.flags.reset == 1'

tshark -r capture.pcap \
  -Y 'tls.handshake'

tshark -r capture.pcap \
  -Y 'dns.time > 1'

Display filters operate after capture, so they differ from the BPF expressions used by tcpdump. A useful workflow is to retain a narrowly scoped original file, then create a smaller evidence package:

tshark -r capture.pcap \
  -Y 'tcp.analysis.retransmission or tcp.flags.reset == 1' \
  -w transport-symptoms.pcap

Operators can open the resulting file in Wireshark for stream reconstruction, protocol inspection, and visual analysis. tshark also supports field extraction and I/O analysis, which makes it easier to turn a one-off investigation into a repeatable incident procedure. Guidance on selecting between command-line monitors and deeper inspection is available in this Linux network traffic monitoring guide.

Packet capture has a hard operational boundary. A pcap may contain credentials, tokens, personal data, or application payloads, even when the original filter looked harmless. Store files with restrictive permissions, define retention, encrypt transfers, and delete them when the investigation no longer requires them.

Counters, Statistics and Live Bandwidth Tools

Counter tools answer questions quickly without retaining packet content. Start with the kernel's interface view:

ip -s link show dev eth0

The output separates receive and transmit totals and exposes packet, byte, error, drop, and related fields. For a more detailed view, repeat the statistics flag:

ip -s -s link show dev eth0

These are cumulative counters. A rising number isn't itself an incident. The useful signal is the change over an interval, correlated with service behavior and link capacity.

ethtool -S moves closer to the NIC and its driver:

sudo ethtool -S eth0

Names vary by driver, but fields such as rx_bytes, tx_errors, rx_dropped, rx_missed, and rx_fifo can separate a kernel-level symptom from a hardware or receive-queue problem. The Linux telemetry model deliberately combines kernel counters, protocol views, and driver statistics, so one command should never be treated as the complete state of the interface (Linux Ethernet statistics through ethtool).

Match each tool to the incident question

For trend sampling, sar -n DEV 1 reports interface deltas at a regular interval. nicstat provides another compact view of throughput and interface errors. These tools are better for observing movement than for explaining packet contents.

iftop shows active host-to-host flows and is useful when an operator needs to identify the current bandwidth consumer. nethogs shifts the question from remote endpoint to local process, although attribution can become ambiguous with containers, namespaces, and shared proxy processes.

A throughput investigation benefits from understanding the distinction between cumulative counters and rate calculations. The practical considerations are outlined in this Linux throughput measurement guide.

iptraf-ng sits between raw counters and flow inspection. It provides an interactive ncurses view of Ethernet load, TCP, UDP, and ICMP statistics, checksum errors, and node information, which makes it useful for live triage rather than long-term retention (iptraf-ng monitoring and analysis). Its display is still constrained by the host's ability to sample and render updates, so it shouldn't be treated as a durable production telemetry system.

When Capture Is the Wrong Tool eBPF and Kernel Telemetry

A packet capture can become part of the incident. tcpdump and libpcap normally move selected packet data toward userspace, where filtering, formatting, buffering, and storage consume CPU and memory. On a host already processing several million packets per second, that extra work can change scheduler behavior, increase contention, and cause the capture itself to drop packets. The high-rate tooling discussion around pktstat-bpf highlights this production gap and describes eBPF-based packet statistics for traffic volumes that overwhelm many interactive approaches (high-rate Ethernet monitoring with pktstat-bpf).

eBPF changes the location of the aggregation. A probe can count, classify, or attribute events in the kernel and export compact summaries instead of copying every packet into a userspace analyzer. That doesn't make overhead disappear, and a poorly designed BPF program can still hurt a host, but the architecture is better suited to continuous telemetry.

Start with a narrow probe

A simple bpftrace experiment can count packets by interface, provided the kernel, BTF data, permissions, and tracepoint names support the script:

sudo bpftrace -e '
tracepoint:net:netif_receive_skb {
  @packets[str(args->name)] = count();
}'

This is a diagnostic example, not a complete exporter. A production implementation should control map cardinality, sampling, probe lifetime, and export frequency. pktstat-bpf is designed for packet statistics using eBPF hooks including TC, XDP, KProbe, and cgroup attachment points, which also makes it relevant to container and workload attribution.

BCC supplies a broader toolkit for kernel-assisted tracing. Network-oriented tools such as tcplife can expose connection lifetimes and process context, while other BCC tools can connect system behavior to network symptoms. The exact tool should follow the question, not the novelty of the framework. A low-rate edge host needing packet evidence doesn't need an elaborate BPF pipeline. A busy service requiring sustained, low-overhead attribution may.

Production rule: Capture packets for evidence. Use counters for history. Use eBPF when the act of observing packets would distort the workload.

BPF isn't automatically available everywhere. The program may require a supported kernel, BTF metadata, privileges, and compatible helper functions. Teams should validate probes on a staging kernel and keep a fallback based on ordinary counters. Background on diagnosing adjacent kernel resource problems is available in this memory leak detection guide.

Continuous Ethernet Monitoring and Alerting

A command run during an incident provides a snapshot. Continuous monitoring needs a repeatable collection path, clear retention, and alerts based on changes rather than raw cumulative values. A small systemd service can collect interface counters, while a timer invokes it on a controlled schedule.

A rolling capture can preserve short forensic context without allowing files to grow indefinitely:

sudo mkdir -p /var/lib/ethermon
sudo tcpdump -i eth0 -nn -s 0 \
  -G 3600 -W 24 -C 200 \
  -w '/var/lib/ethermon/ethermon-%Y%m%d-%H%M%S.pcap'

The rotation settings limit file age and size, but they don't solve access control or sensitive-data handling. The service account should own the directory, permissions should be restrictive, and retention should match the organization's incident and privacy requirements.

Export rates, not just totals

A collector can read ip -s link, retain the previous sample, calculate byte and packet deltas, and publish a small JSON document. The remote endpoint can receive it with:

curl --data-binary @metrics.json 

The endpoint above is illustrative and shouldn't be copied as a real destination. The important design is the payload: interface identity, receive and transmit deltas, errors, drops, and a timestamp. A counter alert on rx_errors fires when the rate changes meaningfully over a window, not just because the cumulative field is nonzero.

Alert conditions should reflect operational symptoms:

• Receive errors or missed packets: investigate the NIC, driver, queue pressure, or physical path.
• Transmit drops: check egress contention, shaping, queue behavior, and downstream availability.
• Sustained bandwidth pressure: compare the rate with the interface's expected operating envelope and application behavior.
• Broadcast or multicast changes: trigger targeted packet inspection rather than paging on a single noisy sample.

A platform such as Fivenines can ingest Linux network telemetry, show per-host and per-interface dashboards, and route alerts to collaboration or incident channels. Teams comparing hosted monitoring approaches can also use this pricing and TCO analysis on SubmitMySaas to evaluate the cost and operational burden of assembling separate metrics, dashboards, and alerting components.

SNMP remains useful for network devices and interface history. The practical details of MIB-based collection and interface metrics are covered in this SNMP and MIB monitoring guide. A solid setup combines host-side counters with device-side views when the fault could exist anywhere between the server and the switch.

Avoid paging on every short-lived spike. Rate-of-change windows, consecutive evaluations, and maintenance suppression reduce false alarms while preserving context. The page should identify the host, interface, direction, error family, recent rate, and a direct next command, not merely announce that “network traffic is high.”

Picking the Right Tool for the Job

The right Linux command follows the question.

If the question is “Is this link saturated?”, begin with ip -s link, then inspect ethtool -S for driver and NIC evidence. If the question is “Which process is transmitting?”, use nethogs where process attribution is available. If it is “Which remote endpoint is consuming bandwidth?”, use iftop for a live flow view.

A practical incident checklist

• What is happening now? Use ip -s link, sar -n DEV 1, or iftop for immediate rates and active flows.
• What happened inside the frames? Use a narrowly filtered tcpdump capture, then dissect it with tshark.
• How is the problem trending? Export counter deltas to a time-series or monitoring platform rather than relying on terminal snapshots.
• Is this a layer-two issue? Filter for Ethernet broadcast, multicast, ARP, and VLAN traffic.
• Is workload ownership unclear? Inspect namespaces and cgroups, then consider eBPF-based attribution.
• Will observation change the workload? Avoid broad packet capture on a busy bottleneck host and prefer kernel aggregation.

A capture on a heavily loaded server can become a self-inflicted performance problem. Conversely, counters can hide microbursts and cannot explain the contents of a frame. eBPF provides a scalable middle path, but it depends on kernel support, BTF, permissions, and carefully bounded programs.

The operational loop is straightforward: retain low-cost counters continuously, capture selectively when evidence is required, and use eBPF when sustained visibility must survive production load. Centralized dashboards and alerts should preserve the local interface context, so the responder can move from a page to the relevant host, counter, flow, namespace, or packet filter without rebuilding the investigation from scratch.

Fivenines provides centralized infrastructure monitoring for Linux servers and network devices, including interface traffic telemetry, dashboards, and alert routing that can complement command-line inspection. Visit Fivenines to connect local Ethernet visibility with continuous monitoring and actionable incident alerts.