DEV Community

Arpit Mungone
Arpit Mungone

Posted on

🌐 Linux for DevOps #3: Understanding Linux Networking Through Hands-On Practice

#networking #beginners #devops #linux

Welcome back to my DevOps learning journey! 👋

For the past two weeks, I've been building my Linux foundation.

In Week 1, I learned how to navigate Linux and work with essential commands.

In Week 2, I explored users, groups, file permissions, and process management.

This week, I decided to move one step further and understand something that I kept encountering everywhere in DevOps:

Networking.

At first, networking felt like a completely different world.

IP addresses, ports, DNS, TCP, UDP, routing, connectivity...

There were a lot of terms to remember.

But once I started practicing networking commands directly on Linux and connecting them with things I had already worked with in AWS, the picture started becoming much clearer.

I realized something important:

As a DevOps engineer, you don't need to become a network engineer, but you absolutely need to understand how systems communicate.

So, this week, I focused on the Linux networking commands that I believe every aspiring DevOps engineer should know.

🌐 What Exactly Is Linux Networking?

Before jumping into commands, I wanted to understand the basics.

Networking is essentially about communication between systems.

When I open a website, connect to an AWS EC2 instance through SSH, pull a Docker image, or make an API request, different systems are communicating with each other.

Linux provides several tools that allow us to inspect and troubleshoot this communication.

And that's where the command line becomes extremely useful.

🖥️ 1. Finding My IP Address

One of the first things I wanted to understand was:

"What is my machine's IP address?"

The command I used was:

ip addr
Enter fullscreen mode Exit fullscreen mode

It displays information about the network interfaces available on the machine.

For example, you might see something like:

inet 192.168.1.10/24
Enter fullscreen mode Exit fullscreen mode

Here, 192.168.1.10 is the IP address assigned to the interface.

Another simple command I found useful was:

hostname -I
Enter fullscreen mode Exit fullscreen mode

It gives the IP addresses assigned to the system in a much simpler format.

Why is this useful in DevOps?

When working with servers, especially AWS EC2 instances, knowing the server's IP address is fundamental.

For example:

ssh -i my-key.pem ec2-user@<IP_ADDRESS>
Enter fullscreen mode Exit fullscreen mode

Without understanding the IP address, it's difficult to understand how we're actually reaching the server.

🔁 2. Understanding Localhost

One concept I wanted to understand better was localhost.

You will often see:

127.0.0.1
Enter fullscreen mode Exit fullscreen mode

This is the IPv4 loopback address.

It refers to the machine itself.

For example, if I run a web application on:

127.0.0.1:5000
Enter fullscreen mode Exit fullscreen mode

the application is accessible from the same machine through port 5000.

I can test it using:

curl http://127.0.0.1:5000
Enter fullscreen mode Exit fullscreen mode

This became particularly interesting when I started working with applications, Docker, and web servers.

It helped me understand the difference between:

"Is my application running?"

and

"Can other machines reach my application?"

Those are two completely different questions.

📡 3. Testing Connectivity with ping

One of the first networking commands almost everyone learns is:

ping google.com
Enter fullscreen mode Exit fullscreen mode

The command sends ICMP echo requests to check whether the destination is reachable.

A typical response might look like:

64 bytes from ...
time=20 ms
Enter fullscreen mode Exit fullscreen mode

The time value gives an indication of the round-trip latency.

What can ping tell me?

It can help answer questions like:

  • Can I reach the destination?
  • Is there packet loss?
  • Is the network responding?
  • How much latency is there?

However, one important lesson I learned is:

A failed ping doesn't always mean the server is down.

Some servers and firewalls simply block ICMP traffic.

This is important when troubleshooting cloud environments.

🌍 4. Understanding DNS with nslookup

I used to think DNS was simply "the thing that converts domain names into IP addresses."

But while practicing, I started understanding how important it is.

For example:

nslookup google.com
Enter fullscreen mode Exit fullscreen mode

This allows us to query DNS and find the IP address associated with a domain.

Another useful command is:

dig google.com
Enter fullscreen mode Exit fullscreen mode

dig provides more detailed DNS information and is especially useful for troubleshooting.

Why does DNS matter in DevOps?

Imagine your application works when you access:

http://192.168.1.20
Enter fullscreen mode Exit fullscreen mode

but doesn't work when you access:

http://myapp.example.com
Enter fullscreen mode Exit fullscreen mode

The application might be completely fine.

The problem could simply be DNS.

This is why understanding DNS is important when deploying applications and services.

🌐 5. Using curl to Test Applications

curl quickly became one of my favorite networking commands.

For example:

curl https://example.com
Enter fullscreen mode Exit fullscreen mode

This sends an HTTP request and displays the response.

But curl is much more useful than simply opening websites.

I can use it to test APIs:

curl http://localhost:5000/api/users
Enter fullscreen mode Exit fullscreen mode

I can also inspect HTTP headers:

curl -I https://example.com
Enter fullscreen mode Exit fullscreen mode

This can help me understand:

  • HTTP status codes
  • Server responses
  • Redirects
  • Headers
  • Application availability

A practical DevOps scenario

Suppose I deployed an application behind Nginx.

Instead of immediately assuming the application is broken, I can test it step by step:

curl http://localhost
Enter fullscreen mode Exit fullscreen mode

If that works, I know the web server is responding.

Then I can investigate whether the issue is related to DNS, security groups, load balancers, or something else.

📥 6. wget – Downloading Files

Another command I practiced was:

wget https://example.com/file.zip
Enter fullscreen mode Exit fullscreen mode

wget is commonly used to download files directly from the command line.

This can be useful when working with Linux servers where there is no graphical browser.

For example, I might need to download:

  • Configuration files
  • Application packages
  • Scripts
  • Software archives

It's a simple command, but very useful when working on remote servers.

🔌 7. Understanding Ports

This was one of the concepts I found particularly important.

An IP address tells us which machine we're communicating with.

A port helps identify which service we're trying to communicate with on that machine.

Some common ports are:

Port Common Usage
22 SSH
80 HTTP
443 HTTPS
3306 MySQL
5432 PostgreSQL
8080 Common application/web port

For example:

192.168.1.10:80
Enter fullscreen mode Exit fullscreen mode

means we're trying to reach port 80 on that machine.

🔎 8. Checking Listening Ports with ss

One of the most useful commands I learned was:

ss -tuln
Enter fullscreen mode Exit fullscreen mode

This helps display listening network sockets.

The options mean:

  • t → TCP
  • u → UDP
  • l → Listening
  • n → Don't resolve service names

If Nginx is running, I might see port 80 listening.

This gives me a very useful troubleshooting question:

Is the application actually listening on the port I'm trying to access?

That's much better than randomly restarting services and hoping they work.

🧭 9. Understanding Network Routes

Another command I explored was:

ip route
Enter fullscreen mode Exit fullscreen mode

This shows the routing table used by Linux.

It helped me understand that packets don't simply "go to the internet."

Linux needs to know where traffic should be sent and which interface or gateway should be used.

For example, you might see:

default via 192.168.1.1 dev eth0
Enter fullscreen mode Exit fullscreen mode

The default route tells Linux where to send traffic when there isn't a more specific route available.

🛣️ 10. Tracing Network Paths

I also explored:

traceroute google.com
Enter fullscreen mode Exit fullscreen mode

This attempts to show the path packets take through the network to reach the destination.

This can be useful when troubleshooting where connectivity problems might be occurring.

Depending on the environment, traceroute may need to be installed first.

🧪 Putting Everything Together

This is where networking became much more interesting for me.

Instead of memorizing commands individually, I started thinking about them as a troubleshooting workflow.

Imagine I deploy a web application, but I can't access it.

Instead of immediately restarting everything, I can ask a series of questions.

Step 1 — Is the server reachable? 

ping <server-ip>
Enter fullscreen mode Exit fullscreen mode

Step 2 — Is the application listening? 

ss -tuln
Enter fullscreen mode Exit fullscreen mode

Step 3 — Can I reach the application locally? 

curl http://localhost:8080
Enter fullscreen mode Exit fullscreen mode

Step 4 — Is DNS resolving? 

nslookup myapp.example.com
Enter fullscreen mode Exit fullscreen mode

or:

dig myapp.example.com
Enter fullscreen mode Exit fullscreen mode

Step 5 — What routes are being used? 

ip route
Enter fullscreen mode Exit fullscreen mode

This way, troubleshooting becomes a process instead of guesswork.

And I think that's one of the biggest things I'm learning from DevOps:

Good troubleshooting starts with asking the right questions.

☁️ Connecting This to AWS

Learning Linux networking also made some AWS concepts easier to understand.

For example, when I work with an EC2 instance, several networking components come into play:

  • Private IP
  • Public IP
  • Security Groups
  • Ports
  • Routing
  • Internet Gateway
  • Subnets

If I can't connect to an EC2 instance through SSH, the problem might not be Linux itself.

It could be:

My Computer
     ↓
Internet
     ↓
AWS Security Group
     ↓
EC2 Network Interface
     ↓
Port 22
     ↓
SSH Service
Enter fullscreen mode Exit fullscreen mode

Understanding Linux networking gives me a much better foundation for understanding what happens inside the server.

🤔 What I Learned This Week

The biggest lesson for me wasn't actually learning ping, curl, or ss.

It was learning how to think about connectivity.

Before this week, if an application wasn't opening, I might have immediately assumed:

"The application is broken."

Now I try to break the problem down:

Can I reach the server?

↓

Is DNS working?

↓

Is the required port open?

↓

Is something listening on that port?

↓

Is the application responding locally?

↓

Is there a firewall, security group, or routing issue?

This way of thinking is something I want to carry forward into my DevOps career.

🛠️ Commands I Practiced This Week

Here's my Linux networking cheat sheet:

# Network interfaces
ip addr
hostname -I

# Connectivity
ping google.com

# DNS
nslookup google.com
dig google.com

# HTTP requests
curl https://example.com
curl -I https://example.com

# Download files
wget https://example.com/file.zip

# Listening ports
ss -tuln

# Routing
ip route

# Trace network path
traceroute google.com
Enter fullscreen mode Exit fullscreen mode

🚀 Key Takeaways

This week helped me understand that networking isn't just about memorizing protocols and port numbers.

It's about understanding how systems communicate and, more importantly, how to troubleshoot when they don't.

My main takeaways:

✅ IP addresses identify systems.

✅ Ports help identify services.

✅ DNS translates human-readable names into IP addresses.

✅ curl is extremely useful for testing applications and APIs.

✅ ss helps identify listening network services.

✅ ip route helps understand how Linux routes traffic.

✅ Troubleshooting should be systematic rather than based on guesses.

📚 Linux for DevOps Series

🐧 Part 1: Learning Linux from Scratch: My First Week in DevOps

🐧 Part 2: Users, File Permissions & Process Management

🌐 Part 3: Understanding Linux Networking (You are here)

🔜 Part 4: Bash Scripting — From Commands to Automation

What's Next?

Now that I have a better understanding of how Linux systems communicate, I want to take the next step:

Automation.

In the next part of this series, I'll start exploring Bash Scripting and see how I can turn repetitive Linux tasks into simple automated workflows.

I'm still learning, still making mistakes, and still figuring things out—but that's exactly what makes this journey interesting.

If you're also learning Linux, DevOps, or Cloud, I'd love to hear what you're currently working on.

Let's learn and build together. 🚀

linux #devops #networking #aws #cloudcomputing #bash #learninginpublic

Top comments (0)