Whenever a website doesn’t open, a server becomes unreachable, or an API stops responding, the issue is often not the application — it’s the network path between systems.

So today I didn’t just read theory. I learned how networking works in layers and practiced the exact commands engineers use in real production incidents.

🧠 Part 1 – Understanding Networking Models (Without Complicated Theory)

When data travels from my laptop to a website, it doesn’t just “go.”
It passes through layers, where each layer has a job.

Think of it like sending a courier package:

• One team packs it

• Another labels it

• Another decides the route

• Another transports it

🔹 The OSI Model (7 Layers – Detailed View)

The OSI model explains networking in 7 steps:

🔹 TCP/IP Model (Real Internet Model)

The internet simplifies OSI into 4 layers:

🔹 Real-Life Example

When I run:

curl https://example.com

This is what happens:

1. Application Layer → HTTP request is created

2. Transport Layer → Sent using TCP port 443

3. Internet Layer → Packet routed using IP

4. Link Layer → Sent through Wi-Fi or Ethernet

Each layer adds its own information, like adding labels to a package.

🛠️ Part 2 – Hands-On Networking Commands

Theory is good. But DevOps is about diagnosing real problems.

I picked one target: google.com
Then I ran all the essential troubleshooting commands.

🖥️ 1. Identify My Machine’s IP Address

hostname -I

or

ip addr show

What this command does:

Shows the IP address assigned to my system.

What I learned:

I saw something like 192.168.1.10.
That’s a private IP, meaning my system is inside a local network (like home Wi-Fi).

If I didn’t see an IP, it would mean:
🚨 My network interface is down.

📡 2. Check Reachability Using ping

ping google.com

What ping does:

Sends small packets to check if the target responds.

Output tells us:

• Time (ms) → Network latency

• Packet loss → Connection stability

My observation:

I got replies in ~20ms with 0% packet loss → Network path is healthy.

If ping fails:

• Internet may be down

• Firewall blocking ICMP

• Target server unreachable

🛣️ 3. Check the Route Using traceroute

traceroute google.com

What this shows:

Every router between me and Google.

Each line = one hop.

Why it matters:

If a connection is slow or failing, traceroute shows where the delay or drop happens.

My observation:

I saw:

• First hop = my router

• Next hops = ISP network

• Final hops = Google network

Timeouts (* * *) may mean:

• Router blocking traceroute

• Network congestion

🔌 4. See Which Services Are Listening

ss -tulpn

What this shows:

All open ports and services running on my machine.

Example:

LISTEN 0 128 0.0.0.0:22

This means SSH is running on port 22.

Why this matters:

If an app isn’t accessible, first check if it’s even listening on a port.

🌍 5. Check DNS Resolution

dig google.com

or

nslookup google.com

What this does:

Converts domain name → IP address.

My observation:

I received multiple IPs, meaning Google uses load balancing.

If DNS fails:
The issue is at the Application layer (DNS service).

🌐 6. Check Web Server Response

curl -I https://google.com

What this does:

Requests only HTTP headers, not the full webpage.

What I saw:

HTTP/2 200

Meaning: Server is working fine.

If I saw:

• 404 → Page missing

• 500 → Server error

• Timeout → Network or firewall issue

🔄 7. View Active Connections

netstat -an | head

What this shows:

Active and listening connections.

States I noticed:

• LISTEN → Waiting for connection

• ESTABLISHED → Active communication

This is useful to see if a server is overloaded or idle.

🎯 Mini Task – Port Testing

First, I found a listening port:

ss -tulpn | grep LISTEN

I saw SSH on port 22.

Then I tested it:

nc -zv localhost 22

Result:

Connection succeeded → Port is reachable.

If it failed, next steps would be:

1. Check if service is running

2. Check firewall rules

💭 Reflection

Fastest command to detect problems?

👉 ping — quickly tells if a system is reachable

If DNS fails?

Check DNS server (Application layer)

If HTTP 500 appears?

Problem at Application layer (server-side issue)

Two real incident follow-ups:

• Check firewall rules

• Check application/service logs

🚀 Final Thoughts

Today I moved from “I know networking terms” to
“I can actually test and troubleshoot real network issues.”

Now, if something breaks, I know how to check:

✔ Is the host reachable?
✔ Where does the path fail?
✔ Is DNS resolving?
✔ Is the port open?
✔ Is the service responding?

That’s real DevOps troubleshooting.