Mastering ss and netstat for RHCSA Network Diagnostics (2026 Guide)

By LinuxCert.Guru Team·

Objective

This guide covers ss and netstat for network diagnostics on RHEL, specifically for RHCSA exam preparation and real production use. By the end, you will know:

  • Why ss replaced netstat on modern RHEL and what that means practically
  • The exact ss commands you'll use on the exam and in production
  • How to read the output and extract the specific information a task is asking for
  • When netstat is still relevant and how to install it if you need it
  • How network diagnostics connects to other RHCSA objectives like firewalld and services

A service won't start. A port isn't responding. You need to know what's listening, what's connected, and what's blocked, fast, from a terminal. These are the tools that answer those questions.

netstat Is Deprecated: What That Actually Means

netstat was the standard network diagnostics tool on Linux for decades. On modern RHEL systems, it is part of the net-tools package, which is no longer installed by default and is considered deprecated. It still works if you install it, but it pulls socket information from the /proc filesystem in an older, slower way.

ss ("socket statistics") is its direct replacement. It comes from the iproute2 package, which is installed by default on all current RHEL versions, queries the kernel directly through a netlink socket instead of /proc, and is significantly faster on systems with many open connections.

  • Is netstat gone completely? No. You can still install it with dnf install net-tools.
  • Should you learn it for RHCSA? Know it exists and understand its output format, since plenty of documentation still references it. But drill ss as your primary tool, since that's what's on a default RHEL system.
  • Does the exam test both? The exam gives you a running RHEL system. ss will be there by default. netstat may or may not be. Build your habits around ss.

The Flags You Need to Know

Both ss and netstat share a similar flag structure, which makes transitioning between them straightforward. The flags you'll reach for on almost every diagnostic task:

  • -t: show TCP sockets only
  • -u: show UDP sockets only
  • -l: show listening sockets only (services waiting for connections)
  • -a: show all sockets (listening and established)
  • -n: show numeric addresses and port numbers instead of resolving hostnames and service names
  • -p: show the process name and PID using each socket
  • -e: show extended information including the socket owner

In practice, you'll combine these into a handful of common patterns. The most useful combination on the exam is -tlnp: TCP, listening, numeric, with process info.

Core ss Commands for RHCSA

Show All Listening TCP Ports

# The most common diagnostic command you will use
ss -tlnp

# What each flag does:
# -t  TCP only
# -l  listening sockets only
# -n  numeric (don't resolve port names like 22 to "ssh")
# -p  show the process using the socket

Sample output:

State   Recv-Q  Send-Q  Local Address:Port  Peer Address:Port  Process
LISTEN  0       128     0.0.0.0:22         0.0.0.0:*          users:(("sshd",pid=1234,fd=3))
LISTEN  0       128     0.0.0.0:80         0.0.0.0:*          users:(("httpd",pid=5678,fd=4))

How to read this output:

  • State: LISTEN: the socket is actively waiting for incoming connections
  • Local Address:Port: what address and port this service is bound to
    • 0.0.0.0:22 means SSH is listening on all interfaces on port 22
    • 127.0.0.1:3306 would mean MySQL is only listening on localhost, not externally accessible
  • Peer Address:Port: for listening sockets this is always *, meaning any source
  • Process: the exact name and PID of what's holding this socket open

Show All Active TCP Connections

# Show all established connections (not just listening)
ss -tnp

# Show both listening and established
ss -tanp

Show UDP Sockets

# Listening UDP sockets (DNS, DHCP, NTP all use UDP)
ss -ulnp

# All UDP sockets
ss -uanp

Filter by Port or Service

# Show only sockets on port 443
ss -tlnp sport = :443

# Show sockets where the destination port is 80
ss -tnp dport = :80

# Show everything related to port 22
ss -anp | grep :22

Show Summary Statistics

# High-level socket count summary
ss -s

This is useful for quick situational awareness: how many TCP connections are in ESTABLISHED state, how many are in TIME-WAIT, and so on. Not something you'll use for specific task work, but useful during troubleshooting to get a feel for overall connection state before drilling down.

netstat: The Commands You Still Need to Know

Even though ss is the default tool, understanding netstat syntax matters for three reasons: a lot of existing documentation and runbooks still reference it, some older systems still in production use it, and some exam prep materials were written before ss was the obvious primary choice. The equivalent commands map almost directly:

# Install net-tools to get netstat
dnf install net-tools -y

# Show listening TCP sockets with numeric output and process info
netstat -tlnp

# Show all TCP connections
netstat -tanp

# Show UDP listening sockets
netstat -ulnp

# Show all sockets, all protocols
netstat -anp

# Show summary statistics
netstat -s

Side-by-side comparison of the most common task:

# These two commands show the same information, different tool
ss -tlnp
netstat -tlnp

The output format differs slightly but the data is the same. If you can read one, you can read the other.

How This Connects to the Rest of RHCSA

Network diagnostics on the RHCSA exam rarely appear as isolated tasks. They're almost always part of a larger troubleshooting or verification workflow. Understanding where ss fits in that workflow is what makes it genuinely useful rather than just a command you memorized.

  • After configuring a service: use ss -tlnp to confirm the service is actually listening on the expected port before trying to connect to it or open the port in firewalld
    • If ss shows nothing listening on port 80, the issue is the service itself, not the firewall
    • If ss shows it listening but connections fail externally, the issue is likely firewalld
  • With firewalld tasks: a port open in firewalld but with nothing listening behind it achieves nothing. Always verify both: ss -tlnp for what's listening, firewall-cmd --list-all for what's allowed through
    • This two-tool verification is the exam-day habit that catches misconfigurations before they cost you points
  • After SELinux blocks a port: a service may fail to bind to a non-standard port due to SELinux, meaning ss will show nothing listening even though the service config looks correct. That's your signal to check SELinux before assuming the service is broken.
  • Checking which process owns a socket: the -p flag tells you the PID and name. Cross-reference with systemctl status and ps aux to build a complete picture of what's running and on what port.

A Typical Exam-Style Diagnostic Task

Configure the Apache web server to listen on port 8080. Verify it is listening correctly after configuration. Ensure the port is open in the firewall and the configuration survives a reboot.

The verification steps in the middle of this task are where ss lives:

# After editing httpd.conf to Listen on 8080 and restarting:
systemctl restart httpd

# Step 1: Confirm Apache is actually listening on 8080
ss -tlnp | grep 8080

# If nothing shows here, the service failed. Check:
systemctl status httpd
journalctl -xe

# Step 2: If it's listening, open the port in firewalld
firewall-cmd --zone=public --permanent --add-port=8080/tcp
firewall-cmd --reload

# Step 3: Verify both are set correctly
ss -tlnp | grep 8080
firewall-cmd --zone=public --list-ports

This is the actual sequence. ss is the check between "I configured the service" and "I opened the firewall," making sure you're solving the right problem at each step.

Common Mistakes

  • Skipping the ss check and going straight to firewall rules. If the service isn't listening, no amount of firewall changes will make it work. Check what's actually running first.
    • The diagnostic sequence is always: is the service running? Is it listening? Is the firewall open?
  • Forgetting -n and misreading port names. Without -n, port 22 shows as "ssh" and port 80 shows as "http". When a task specifies a non-standard port like 8443, always use -n to see raw numbers.
    • What looks like nothing on port 8443 might be listed as "pcsync-https" without the -n flag
  • Not using -p and guessing which process owns a socket. Always include -p so you know exactly which process is responsible. On a system with multiple services, this is the difference between restarting the right service and the wrong one.
    • Note: -p requires root or sudo to show process information for all processes
  • Checking ss before the service has fully started. On slow systems or after a cold start, a service may still be initializing. Wait a second and run the command again before concluding the port isn't bound.
  • Assuming netstat is available. On a default RHEL 10 system, it isn't. If a task or runbook tells you to use netstat and you haven't installed net-tools, it will fail silently with command not found.

Quick Reference

  • Most used on exam day:
    • ss -tlnp: listening TCP sockets, numeric, with process
    • ss -ulnp: listening UDP sockets, numeric, with process
    • ss -tanp: all TCP sockets including established
    • ss -s: socket summary statistics
  • Filtering output:
    • ss -tlnp | grep :80: check if anything is on port 80
    • ss -tlnp | grep httpd: check if Apache specifically is listening
  • netstat equivalents (requires net-tools installed):
    • netstat -tlnp: same as ss -tlnp
    • netstat -anp: all sockets all protocols with process
    • dnf install net-tools: how to install it if needed
  • Diagnostic sequence for any service issue:
    • systemctl status SERVICE: is it running?
    • ss -tlnp | grep PORT: is it listening?
    • firewall-cmd --list-all: is the port open?
    • journalctl -xe: what does the log say?

ss vs netstat: Which to Practice

  • Practice ss as your primary tool. It's installed by default, it's faster, and it's what you'll find on any current RHEL system without extra packages.
  • Know netstat syntax well enough to read it when you encounter it in documentation, runbooks, or older exam prep materials.
  • Know how to install net-tools in case a task explicitly requires netstat or a system you inherit relies on it.
  • Don't spend equal time on both. The 80/20 split here is heavily toward ss. The flag structure is almost identical once you know one, so the transition is simple.

Conclusion

ss is the network diagnostic tool on modern RHEL. netstat still works if you install it, and knowing both is useful, but ss is what's on the system by default and what your troubleshooting workflow should be built around.

  • ss -tlnp is the command you'll run more than any other when verifying network configuration
  • The diagnostic sequence matters as much as the command: service running, port listening, firewall open
  • Always use -n to see raw port numbers, and -p to see which process owns a socket
  • Use ss output to confirm a service is actually working before touching firewalld
  • netstat is deprecated, not gone. Know the syntax, know how to install it, just don't rely on it being present

Build the diagnostic sequence into your practice habits now: check the service, check the socket, check the firewall. Do it in that order every time and the network troubleshooting tasks on the exam stop being guesswork.

Start practicing RHCSA networking and diagnostics at LinuxCert.Guru → https://linuxcert.guru

$_
Ready to go beyond reading?Practice with free, auto-graded RHCSA labs.
Start free →