Linux Networking

Why Networking Skills Matter

In DevOps, many “application problems” are really networking problems. A service may be healthy but unreachable, a DNS name may resolve incorrectly, or a firewall may block the expected port.

Linux includes strong networking tools for checking addresses, routes, listening ports, remote connectivity, and file transfers.

Inspecting Interfaces with ip addr

The modern command for viewing network interfaces and addresses is ip.

ip addr
ip addr show eth0

This tells you what IP addresses are assigned to each interface.

If a server has no expected address, that is your first clue something is wrong.

Viewing Routes with ip route

Routing decides where traffic goes.

ip route

Example output may show a default gateway such as:

default via 10.0.0.1 dev eth0

Without a correct default route, the host may reach the local subnet but not the internet or remote networks.

Testing Reachability with ping

ping checks whether a host responds to ICMP echo requests.

ping 8.8.8.8
ping example.com

If ping 8.8.8.8 works but ping example.com fails, the issue may be DNS rather than raw network connectivity.

Note: Some hosts block ICMP, so a failed ping does not always mean the service is down.

Fetching Data with curl and wget

curl is a versatile tool for making HTTP requests and testing APIs.

curl https://example.com
curl -I https://example.com
curl -X GET https://api.example.com/health

-I fetches headers only, which is great for quick checks.

wget is commonly used to download files.

wget https://example.com/archive.tar.gz

Use curl for flexible request testing and wget when your main goal is downloading.

Inspecting Listening Ports with ss and netstat

ss is the modern tool for socket statistics.

ss -tuln
ss -tulpn

Useful flags:

• -t TCP sockets
• -u UDP sockets
• -l listening only
• -n numeric output, no DNS lookup
• -p process info

netstat may still appear in older guides:

netstat -tulnp

On newer systems, ss is usually preferred.

Basic Port Scanning with nmap

nmap helps discover open ports and services.

nmap localhost
nmap -p 22,80,443 example.com

Beginners should use it responsibly and only on systems they are authorized to scan.

Tip: Even a basic nmap scan can quickly confirm whether a port is reachable from your current machine.

Remote Access with ssh

ssh is the standard tool for secure remote shell access.

ssh devops@server.example.com
ssh -i ~/.ssh/id_rsa devops@server.example.com

It is the backbone of Linux server administration.

If SSH fails, common causes include DNS issues, firewall rules, wrong keys, or the service not listening on the expected port.

File Transfer with scp and rsync

Use scp for straightforward secure copies.

scp app.conf devops@server:/etc/myapp/
scp devops@server:/var/log/app.log ./

Use rsync for more efficient sync behavior, especially on repeated transfers.

rsync -av ./site/ devops@server:/var/www/site/

rsync copies only changed data, which makes it great for deployments and backups.

/etc/hosts and DNS Resolution

DNS translates names like api.example.com into IP addresses. Linux can also use /etc/hosts for local name overrides.

Example entry:

10.0.0.15 internal-api.local

This is useful for testing or temporary overrides, but it can also create confusion if it points to an outdated address.

A good troubleshooting habit is checking whether a name resolves the way you expect.

A Practical Troubleshooting Flow

Suppose a service is “down.” You could check:

ip addr
ip route
ping api.example.com
curl -I https://api.example.com/health
ss -tulpn | grep 443

That sequence answers key questions:

• does the host have an IP?
• can it route traffic?
• does DNS work?
• does the web endpoint respond?
• is anything listening on the expected port?

Test Your Understanding

Exercise 1: Diagnosing a name-resolution failure

Scenario: ping 8.8.8.8 works, but ping example.com fails.

Question: Based on the lesson, what is the most likely category of problem?

Exercise 2: Inspecting listening services

Question: Which command from the lesson is best for seeing listening TCP and UDP sockets with process information?

Exercise 3: Efficient repeated file syncs

Question: Why might rsync be a better fit than scp for sending a site directory to a server again and again?

---

Key takeaways

• ip replaced ifconfig and route. ss replaced netstat. Learn the new ones.
• ss -tlnp is the workhorse: which ports are listening and which process owns each.
• ping failing does not mean "down". Plenty of hosts drop ICMP while serving traffic normally.
• curl -v distinguishes DNS, TCP and TLS failures by showing exactly which stage did not complete.
• A service bound to 127.0.0.1 is unreachable from anywhere else, no matter what the firewall says.
• /etc/hosts wins over DNS, which makes it both a useful override and an easy thing to forget about.
• Prefer rsync over scp for anything repeated. It resumes, it is incremental, and scp is deprecated.

---

Frequently Asked Questions

What replaced ifconfig and netstat on modern Linux?

The iproute2 suite. ip addr replaces ifconfig for viewing and configuring interfaces, ip route replaces route, ip neigh replaces arp, and ss replaces netstat. The old tools come from net-tools, which is unmaintained and not installed by default on many current distributions, including most container base images, which is why ifconfig: command not found is so common inside a container. ss is also significantly faster on a busy host, since it reads kernel socket data directly.

How do I see which ports are open and listening?

sudo ss -tlnp, t for TCP, l for listening only, n for numeric ports rather than service names, p for the owning process. Add u for UDP. The sudo matters: without it you still see the ports but not which process owns them. Read the local address carefully, because 127.0.0.1:5432 means only that machine can connect while 0.0.0.0:5432 means anything that can route to the host can.

Why can I ping a server but not connect to its service?

Because they test different layers. ping uses ICMP and confirms the host is reachable; a service needs a TCP port open, something listening on it, and no firewall in between. Work up the stack: ss -tlnp on the server to confirm something is listening and on which address, then curl -v telnet://host:port or nc -zv host port from the client to test the port, then check ufw status or the cloud security group. The most frequent cause is the service bound to 127.0.0.1 rather than 0.0.0.0.

Why does ping fail when the server is clearly up?

ICMP is frequently blocked, by a firewall, a cloud security group, or as policy, and none of that affects normal traffic. AWS security groups, for instance, do not permit ICMP by default, so a perfectly healthy EC2 instance serving HTTPS will not answer a ping. Test the port you actually care about instead: nc -zv host 443 or curl -I https://host. A failed ping is weak evidence either way.

How do I troubleshoot a DNS resolution problem?

dig +short example.com asks DNS directly and shows the answer, and dig @8.8.8.8 example.com compares against a public resolver to distinguish a broken local resolver from a genuine DNS problem. resolvectl status shows which servers systemd-resolved is actually using. Check /etc/hosts too. It takes precedence over DNS entirely, so a stale entry there overrides whatever DNS says and is easy to forget. Inside containers, check /etc/resolv.conf, which the runtime writes.

What is the difference between scp and rsync?

scp copies files over SSH and copies everything, every time. rsync compares source and destination first and transfers only the differences, resumes interrupted transfers with --partial, can delete files that no longer exist at the source with --delete, and reports progress. For a one-off small file either is fine; for anything repeated or large, rsync -avz is substantially faster. OpenSSH has also deprecated the scp protocol on security grounds, which is another reason to standardise on rsync or sftp.