Networking for DevOps (Senior-Level, Production-Focused)

Source: Dev.to

Core Knowledge (Must Be Automatic)

Network Basics (No Thinking Time)

• IP address – private vs. public
• CIDR – /32, /24, /16
• Ports – well‑known vs. ephemeral
• TCP vs. UDP
• DNS resolution flow
• Routing tables
• Default gateway

Linux Networking Commands (Must Know by Memory)

Interface & Routing

ip a        # show interfaces
ip r        # show routing table

Connections & Ports

ss -tulnp
netstat -tulnp

Reachability

ping 
traceroute 

Application Layer

curl 
wget 

Port Ownership

lsof -i :8080

Firewalls

ufw status
iptables -L -n

🔥 PROJECT 1 – “Service Is Running but Not Reachable”

(Classic Interview Question)

Scenario (Real Company Case)

• Backend service deployed on a Linux VM
• Process is running
• Port is open locally
• External users cannot access it

Goal

Systematically isolate the failure instead of guessing.

Architecture

Client → DNS → Network → Firewall → OS → Application

Step‑by‑Step Lab

Step 1 – Start a Service

python3 -m http.server 8080

Verify it’s listening:

ss -tulnp | grep 8080

Expected: Service listening on 0.0.0.0:8080 or 127.0.0.1:8080.

Step 2 – Test Local Access

curl http://localhost:8080

• ✅ Works → App is healthy
• ❌ Fails → App issue, not networking

Step 3 – Check Interface Binding

ip a

Key Insight: If the app binds to 127.0.0.1, it is NOT reachable externally.

Step 4 – Check Routing

ip r

Look for:

• Default route
• Correct gateway

❌ No default route → traffic cannot leave the VM.

Step 5 – Firewall Check (Very Common)

sudo ufw status
# or
sudo iptables -L -n

Fix (UFW example):

sudo ufw allow 8080

Step 6 – Verify Port Ownership

lsof -i :8080

Confirms:

• Correct process is listening
• No port conflicts

Step 7 – External Test

From another machine:

curl http://<VM_IP>:8080

Interview Mapping (Exact Words to Use)

“I troubleshoot layer by layer: Application → Port binding → OS firewall → Routing → DNS.”

🔥 PROJECT 2 – DNS Failure in Production

Scenario

• Service reachable via IP
• Not reachable via domain name

Steps

Step 1 – Resolve DNS

nslookup myservice.company.com
# or
dig myservice.company.com

Step 2 – Check /etc/resolv.conf

cat /etc/resolv.conf

Look for:

• Valid nameserver entries
• Corporate DNS vs. public DNS

Step 3 – Compare IP vs. DNS

curl http://10.0.2.15:8080
curl http://myservice.company.com:8080

Interview Answer

“If the IP works but DNS fails, the problem is DNS resolution, not networking or the application.”

🔥 PROJECT 3 – Routing Issue (Traffic Goes Nowhere)

Scenario

• Service runs
• Firewall open
• DNS OK
• Still unreachable

Steps

Step 1 – Check Routes

ip r

Common issues:

• Missing default route
• Wrong gateway after VPN or cloud mis‑config

Step 2 – Trace Packet Path

traceroute google.com

If the trace stops early → routing issue.

Interview Tip

“Traceroute tells me where the packet dies. That’s often faster than guessing.”

🔥 PROJECT 4 – Port Conflict & Ghost Services

Scenario

• Deployment succeeded
• App crashes immediately

Steps

Step 1 – Check Port Usage

ss -tulnp | grep 8080
# or
lsof -i :8080

Step 2 – Kill or Reconfigure

kill -9 <PID>

Interview Insight

“One of the first things I check is whether the port is already in use.”

🔥 PROJECT 5 – Firewall Lockdown Simulation

(Add your own steps here – e.g., enable a strict security group, verify connectivity, then roll back.)

---

Security Focus

Scenario

• Security team tightened firewall
• App broke

Step 1: Enable Firewall

sudo ufw enable

Step 2: Block Everything

sudo ufw default deny incoming

Step 3: Allow Only Required Ports

sudo ufw allow 22
sudo ufw allow 443

Learning Outcome

• Least‑privilege networking
• Zero‑trust mindset

Interview Answer

“I never open wide ports. I allow only what the application strictly needs.”

🎯 FINAL INTERVIEW MASTER ANSWER

Question:
“Service is up but not reachable. What do you check?”

Perfect Senior Answer:

“I troubleshoot layer by layer.

1. Service status – Verify the service is running and listening on the correct interface/port (systemctl status …, ss -ltnp).
2. Firewall rules – Check ufw/iptables policies to ensure the required ports are allowed.
3. Routing – Inspect the routing table (ip route) to confirm traffic can reach the host.
4. DNS resolution – Confirm the hostname resolves to the correct IP (dig, nslookup).
5. Connectivity tools – Use ping, traceroute, or tcptraceroute to locate where packets are dropped.
6. Application logs – Look for errors that might indicate binding or permission issues.
   By moving through these layers I can quickly pinpoint whether the blockage is at the host, network, or application level.”