nstat is a Linux network-statistics command from the iproute2 toolset. It reads kernel networking counters and helps technicians answer questions such as: Are TCP retransmissions increasing? Are ICMP errors accumulating? Is the host seeing failed connection attempts? Did a network fault begin before or after a configuration change?

This lesson follows Linux Command #57 – nmcli. nmcli manages NetworkManager connections and interfaces; nstat looks deeper into the Linux kernel’s accumulated TCP/IP statistics.

KeepItTechie demonstrates Linux network-statistics troubleshooting with ss, another modern iproute2 tool. ss shows sockets and sessions, while nstat shows kernel protocol counters.

What nstat Reads

The nstat manual describes the command as a tool for monitoring kernel SNMP counters and network-interface statistics. The counters come from the Linux networking stack and include groups such as IP, IPv6, ICMP, TCP, UDP, and extended TCP statistics.

Unlike a packet capture, nstat does not show every frame or packet. It gives you counters: totals or changes in events the kernel has already observed. That makes it lightweight and useful for baselining a server before and after a suspected network event.

Start With a Read-Only Snapshot

The simplest command is:

nstat

By default, nstat normally shows counters that changed since the previous invocation. The output can include names such as TcpRetransSegs, TcpExtTCPTimeouts, IpInReceives, UdpInDatagrams, or ICMP-related counters depending on what changed.

This behavior is important: the first reading and the next reading are not necessarily equivalent to a simple lifetime total. nstat maintains history so technicians can focus on increments.

Show Absolute Counter Values

Use -a when you want absolute values instead of changes:

nstat -a

This is useful when recording a baseline before maintenance. Capture the absolute state, perform the controlled test, then compare later values to see which kernel counters moved.

Filter to the Counters You Need

nstat accepts counter-name patterns. For example:

nstat 'Tcp*'
nstat 'Udp*'
nstat 'Icmp*'
nstat '*Retrans*'

The manual documents case-insensitive wildcard matching with * and ?. Filtering is often better than dumping everything because it keeps the troubleshooting question narrow.

TCP Retransmissions

TCP retransmission counters are among the most useful signals on a Linux host. A retransmission occurs when TCP sends data again because the original segment was not acknowledged as expected. A rising TcpRetransSegs value can be associated with packet loss, congestion, damaged links, queue drops, bad wireless conditions, overloaded devices, or a broken return path.

Do not treat one retransmission as proof of a failing network. TCP is designed to recover from loss. The useful question is whether retransmissions are increasing materially during the same period users report poor performance.

Pair nstat with ethtool when you suspect physical or NIC-level faults. ethtool -S can expose interface and driver counters, while nstat exposes protocol-stack counters. Together they help separate Layer 1/2 symptoms from Layer 3/4 symptoms.

This English iproute2 overview explains the family of Linux networking tools that includes commands such as ip, ss, traffic-control utilities, and nstat.

ICMP Counters

ICMP is used for network-control and diagnostic messages. Filtering with nstat 'Icmp*' can reveal changes in echo requests, unreachable messages, redirects, time-exceeded messages, and other ICMP events depending on kernel support and traffic.

These counters can add context to traceroute and ping testing. A failed ping alone does not identify the root cause, but a simultaneous rise in ICMP unreachable or error counters can provide stronger evidence.

UDP Counters

UDP does not establish a TCP-style session or retransmit lost application data automatically. nstat 'Udp*' can help reveal datagrams received, datagrams sent, packets delivered to no listening application, and receive errors.

This can be useful when troubleshooting DNS, monitoring traffic, telemetry, or other UDP-based services. The counter only tells you that an event occurred; use a packet capture or application log when you need packet contents or transaction details.

Show Zero Counters

By default, zero-valued counters may be omitted. Use:

nstat -z

This is useful when building a checklist and you need to confirm that a specific counter exists even when its value is zero.

Reset nstat History

The -r option resets nstat’s stored history:

nstat -r

Use this carefully when collecting evidence. Resetting nstat history does not reset the Linux kernel’s underlying lifetime network counters; it resets the history nstat uses to calculate its change-oriented output.

Do Not Update the History

Use -s or --noupdate to display counters without updating nstat’s history state:

nstat -s

This can be valuable when another troubleshooting script depends on the next normal nstat reading representing the full accumulated change.

JSON Output for Automation

nstat can emit JSON:

nstat -j
nstat -j -p

The -p option pretty-prints JSON when used with -j. Structured output is much safer for automation than trying to parse changing columns of human-readable text.

A monitoring script can collect selected counters before and after a network event, store the JSON, then compare retransmissions, timeouts, UDP receive errors, or ICMP failures programmatically.

This English Linux networking tutorial covers the modern iproute2 command family and provides context for why contemporary Linux troubleshooting relies on iproute2 tools instead of only legacy net-tools.

nstat vs. ss vs. ethtool vs. nmcli

• nstat: kernel protocol counters and changes over time.
• ss: sockets, listening ports, TCP states, and active connections.
• ethtool: NIC link negotiation, driver information, hardware statistics, and offload settings.
• nmcli: NetworkManager devices, profiles, IP configuration, Wi-Fi, and persistent connection settings.

No single command replaces the others. A strong Linux technician moves between layers instead of forcing every problem into one tool.

This Linux community discussion shows a common troubleshooting need: finding interface and protocol statistics when older netstat workflows do not match modern Linux tooling. Community advice is practical experience, not a substitute for the man page or distribution documentation.

Practical Troubleshooting Workflow

1. Record the symptom and exact time.
2. Confirm interface and connection state with nmcli.
3. Check speed, duplex, link, and NIC counters with ethtool.
4. Run nstat -a and save the baseline.
5. Filter the protocol family relevant to the symptom, such as nstat 'Tcp*'.
6. Reproduce the problem in a controlled way.
7. Run nstat again and identify which counters changed.
8. Use ss, logs, traceroute, or packet capture to investigate the counters that moved.
9. Make one controlled change.
10. Repeat the same measurement and compare the result.
11. Document the before-and-after evidence.

Common Mistakes

• Reading one large number as proof of a current failure: lifetime counters can be old. Measure changes during the incident.
• Resetting history before saving a baseline: this destroys useful comparison state.
• Assuming retransmissions always mean bad cabling: congestion, wireless loss, remote systems, queue drops, and return-path problems can also cause them.
• Using nstat as a packet analyzer: it exposes counters, not packet payloads.
• Ignoring the physical layer: pair protocol counters with ethtool and switch-port evidence.
• Changing several settings at once: you lose the ability to identify which change improved or worsened the counters.

Hands-On Exercise

On a Linux system you control, run nstat -a and save the output. Then run nstat 'Tcp*' and identify TcpRetransSegs if present. Generate ordinary network traffic by opening several websites or transferring a test file. Run the same command again and record which counters changed.

Next run nstat -j -p 'Tcp*' and save the JSON output. Compare the human-readable and JSON forms. Do not intentionally create packet loss or change production network settings for this exercise.

Knowledge Check

1. What type of information does nstat display?
2. What is the difference between normal nstat output and nstat -a?
3. What does nstat 'Tcp*' do?
4. Why can TcpRetransSegs be useful?
5. Does a retransmission automatically prove the Ethernet cable is bad?
6. What does nstat -r reset?
7. Does nstat -r reset the kernel’s lifetime TCP/IP counters?
8. Which option produces JSON?
9. Why would you use nstat with ethtool?
10. When would a packet capture be more useful than nstat?

Answers

1. Kernel network protocol and related statistics counters.
2. Normal output emphasizes changes since previous use; -a displays absolute values.
3. It filters output to counter names matching the TCP pattern.
4. It shows TCP segments that had to be retransmitted and can help identify loss or transport instability.
5. No. Many network conditions can cause retransmissions.
6. The history nstat uses to calculate incremental output.
7. No. It resets nstat history, not the underlying kernel lifetime counters.
8. -j.
9. nstat shows protocol-stack behavior while ethtool can show link, NIC, driver, and hardware-level evidence.
10. When you need packet-by-packet details, headers, timing, conversations, or payload-level evidence.

Primary References

• Linux man-pages — nstat(8)
• Linux man-pages — iproute2 ip(8)

BitcoinVersus.Tech Editor’s Note:
We volunteer daily to ensure the credibility of the information on this platform is Verifiably True. If you would like to support to help further secure the integrity of our research initiatives, please donate using the QR code provided

For best QR-code scanning results, please scan this donation code from a desktop or larger screen. Mobile screens may prevent camera recognition.

BitcoinVersus.Tech provides technical education and analysis for informational purposes only.