Networking Fundamentals for DevOps

week-1 of my 90-days of DevOps journey.

Content

1. Understanding the OSI Model 🧱

While the TCP/IP model is what we mostly deal with in practice, understanding the OSI (Open Systems Interconnection) Model helps clarify how networking works under the hood. It's a 7-layer conceptual framework that breaks down the communication process between two systems.

I found it super helpful when troubleshooting networking issues across different layers — from physical connections to app-level bugs.

---

🧩 The 7 Layers of OSI (Top to Bottom):

---

🧠 Real-Life Analogy: Sending a Letter

Imagine sending a letter through a postal system. Here's how the OSI layers relate:

• Layer 7 (Application): You write the letter and choose a language (English, Spanish…).

• Layer 6 (Presentation): You encrypt it with a secret code.

• Layer 5 (Session): You call the recipient to let them know it’s coming.

• Layer 4 (Transport): You choose regular mail (UDP) or certified mail with tracking (TCP).

• Layer 3 (Network): The postal system figures out the best route.

• Layer 2 (Data Link): The local post office sorts it for delivery.

• Layer 1 (Physical): The mail truck physically moves it to the destination.

---

2. The TCP/IP Model — The Backbone of Modern Networking 📡

When I started learning networking as part of my DevOps journey, the TCP/IP model made more sense to me than the OSI model. It's simpler (only 4 layers) and more practical since it’s what the internet and most real-world systems are based on.

So, let’s break down each layer of the TCP/IP model with DevOps use cases, relatable analogies, and a real-life data flow example.

📦 The 4 Layers of the TCP/IP Model

1. Application Layer

This is the top-most layer where user-facing applications interact with the network. It includes protocols like:

• HTTP/HTTPS (web browsing)

• FTP (file transfer)

• SSH (secure shell access)

• DNS (domain resolution)

🛠️ DevOps Example: Running curl https://myapi.dev or pulling a Docker image over HTTPS.

🧠 Real-world analogy: It's like ordering food using a restaurant’s mobile app.

---

2. Transport Layer

This layer ensures that data gets from one system to another reliably (TCP) or quickly (UDP). It’s responsible for:

• Error detection

• Flow control

• Sequencing

🔁 TCP: Reliable, ordered delivery (e.g., Git push/pull, SSH)
⚡ UDP: Fast but connectionless (e.g., DNS, live monitoring)

🛠️ DevOps Example: Jenkins connects to GitHub using TCP to fetch commits.

🧠 Real-world analogy: The delivery person making sure your order is complete and intact.

---

3. Internet Layer

This layer handles addressing and routing. It’s where IP (Internet Protocol) operates.

Main responsibilities:

• Assign IP addresses

• Route packets across networks

🛠️ DevOps Example: Your EC2 instance communicates with an external API using its public IP address.

🧠 Real-world analogy: The GPS system finding the best route to deliver your food.

---

4. Network Access Layer (Link Layer)

This is the lowest layer and involves the actual hardware or network interface — Ethernet, Wi-Fi, MAC addresses, etc.

🛠️ DevOps Example: Docker containers get virtual Ethernet interfaces to communicate via bridge networks.

🧠 Real-world analogy: The road and delivery truck that physically brings the order to your doorstep.

---

---

🔄 Real-Life Example: Data Flow Through the TCP/IP Model

Let’s say I open a browser and type: https://devops-blog.io
Here’s how that request flows through the TCP/IP stack:

1. Application Layer:

   • The browser prepares an HTTPS request.

   • DNS resolves devops-blog.io to an IP address.

2. Transport Layer:

   • A TCP connection is created on port 443 (HTTPS).

   • Data is broken into segments and numbered.

3. Internet Layer:

   • Each TCP segment is packed into an IP packet.

   • The destination IP is set.

   • Routing is determined based on IP tables.

4. Network Access Layer:

   • IP packets are turned into Ethernet frames.

   • Sent over Wi-Fi or Ethernet to the default gateway.

👉 This process reverses at the destination server, with the server responding via the same layered approach.

---

3. Some Important Protocols & Ports DevOps 📡

I'm new to DevOps, and understanding protocols felt tricky at first. But once I saw how they connect to real tasks like SSH access, API calls, and deployments, it all started making sense. Here's a simple breakdown of the most common protocols, grouped by TCP/IP layers, with practical examples I came across.

---

🧠 Application Layer

(TCP/IP Layer 4 / OSI Layer 7)

🌐 HTTP / HTTPS
Ports: 80 (HTTP), 443 (HTTPS)
Purpose: Web communication — browser-to-server or service-to-service.
Where it shows up: APIs, monitoring dashboards, GitHub webhooks, frontend deployments.
In action: When your app fetches data from an external API securely, it uses HTTPS.

🔐 SSH
Port: 22
Purpose: Secure remote shell access.
Where it shows up: Connecting to Linux servers (e.g., EC2), Git over SSH, provisioning infrastructure.
In action: You SSH into an EC2 instance to deploy or debug your app manually.

📁 FTP / SFTP
Ports: 21 (FTP), 22 (SFTP via SSH)
Purpose: File transfers across systems.
Where it shows up: Uploading backups, config files, or logs to remote locations.
In action: Automating secure file uploads from Jenkins to a remote backup server.

🧭 DNS
Port: 53
Purpose: Resolving domain names to IPs.
Where it shows up: Every time your app or CI tool reaches api.something.com.
In action: DNS resolution must work for your pipeline to pull a container image from Docker Hub.

📨 SMTP
Ports: 25, 465, 587
Purpose: Sending emails and alerts.
Where it shows up: Alerting systems, incident notification tools like PagerDuty or custom apps.
In action: Your monitoring tool sends email alerts via an SMTP server when CPU spikes.

🕰️ NTP (Network Time Protocol)
Port: 123 (UDP)
Purpose: Synchronizing time across servers.
Where it shows up: All production servers, logs, distributed systems.
In action: Keeping your EC2 logs and app servers synced to avoid timestamp mismatches.

📡 SNMP (Simple Network Management Protocol)
Ports: 161/162 (UDP)
Purpose: Network device monitoring and management.
Where it shows up: Routers, switches, hardware-level monitoring.
In action: Infrastructure monitoring dashboards pull metrics from network gear using SNMP.

---

🚚 Transport Layer

(TCP/IP Layer 3 / OSI Layer 4)

🔁 TCP (Transmission Control Protocol)
Ports: Dynamic (based on service)
Purpose: Reliable, ordered data transmission.
Where it shows up: Git, HTTPS, SSH, MySQL — anything critical and stateful.
In action: Ensures your container image is uploaded completely and correctly to a remote registry.

⚡ UDP (User Datagram Protocol)
Ports: Dynamic — often 53 (DNS), 123 (NTP), etc.
Purpose: Fast, connectionless data delivery.
Where it shows up: Real-time monitoring, DNS requests, SNMP.
In action: Prometheus or Telegraf sends real-time metrics pings without overhead.

---

🛰 Internet Layer

(TCP/IP Layer 2 / OSI Layer 3)

🌍 IP (Internet Protocol)
Ports: N/A (Protocol-based)
Purpose: Addressing and routing packets between nodes/networks.
Where it shows up: VPC subnet design, firewall routing, Kubernetes pod communication.
In action: Your pod in GKE routes a request to another microservice using its internal IP.

🧪 ICMP
Ports: N/A (used by tools like ping)
Purpose: Diagnostics and reachability checks.
Where it shows up: ping, traceroute, Kubernetes node health probes.
In action: You ping an EC2 instance to confirm it's reachable before deploying.

---

🧷 Network Access Layer

(TCP/IP Layer 1 / OSI Layers 1 & 2)

🔍 ARP (Address Resolution Protocol)
Purpose: Resolves IP addresses to MAC addresses.
Where it shows up: Local subnet communication, Docker bridge networking, VM-to-VM traffic.
In action: Your host uses ARP to find the MAC address of another container on the same network before sending data.

🧱 Ethernet / Wi-Fi
Ports: N/A
Purpose: Actual transmission over cables or air.
Where it shows up: Local VMs, containers using bridge networks, cloud instances with virtual NICs.
In action: Your Docker container communicates via a virtual Ethernet bridge to another container.

---

4. Important Linux Networking Commands 🧪

These are the commands I keep in my toolbox — from checking connectivity to digging into DNS and inspecting network traffic in real-time. Whether you’re deploying to the cloud or debugging locally, these tools are essentials.

---

🛰️ ping — Check basic network reachability

Purpose: Sends ICMP echo requests to test if a remote host is up.
Command:

ping example.com

DevOps Use: Test if your service, database, or API endpoint is online before deployment.

---

🧭 traceroute / tracert — Trace packet hops

Purpose: Shows the route taken by packets to reach the destination.
Command:

traceroute google.com    # Linux

DevOps Use: Diagnose network slowness or packet loss across hops in the delivery path.

---

🌐 curl — Make HTTP requests

Purpose: Sends HTTP requests to test APIs and services.
Command:

curl -I https://example.com       # Get headers  
curl -X POST -d '{"x":1}' -H "Content-Type: application/json" https://api.example.com

DevOps Use: Test API endpoints, webhook URLs, microservices, and load balancer behavior.

---

📡 netstat / ss — Check open ports and connections

Purpose: Show active TCP/UDP ports and process bindings.
Command:

netstat -tulnp       # Legacy  
ss -tuln             # Preferred

DevOps Use: Find which process is using port 80 or confirm your backend is listening.

---

🔍 dig / nslookup — DNS queries

Purpose: Query DNS records and name resolution.
Command:

dig github.com  
nslookup api.myapp.dev

DevOps Use: Debug DNS misconfigurations, check domain propagation.

---

🌍 ip — View or configure IP, routing, and interfaces

Purpose: Replace old ifconfig for IP address and route management.
Command:

ip a           # Show IP addresses  
ip route       # Show routing table  
ip link show   # Show interface status

DevOps Use: Inspect pod interfaces, container bridges, custom routes.

---

🔎 tcpdump — Packet sniffer for network traffic

Purpose: Capture network packets at the interface level.
Command:

sudo tcpdump -i eth0 port 443

DevOps Use: Analyze traffic between services, debug SSL negotiation, find anomalies.

---

🔐 nmap — Network scanner and port mapper

Purpose: Scan hosts for open ports and services.
Command:

nmap -sT 192.168.1.1  
nmap -p 22,80,443 myserver.dev

DevOps Use: Audit open ports on cloud instances or internal services before hardening.

---

🧰 hostname — View or set system hostname

Purpose: Shows or changes the system hostname.
Command:

hostname        # View  
hostnamectl set-hostname web-node-1

DevOps Use: Useful when provisioning infrastructure and tagging instances.

---

🌐 route / ip route — Show network routing

Purpose: Displays or modifies the system routing table.
Command:

ip route show

DevOps Use: Check how your system routes packets — especially in multi-subnet setups like VPCs.

---

🧪 lsof -i — List open files by network port

Purpose: Show which processes are using network ports.
Command:

sudo lsof -i :3000

DevOps Use: See what’s holding onto a port before your app fails to bind.

---

🧮 ethtool — Ethernet interface statistics

Purpose: Show or change low-level NIC settings.
Command:

ethtool eth0

DevOps Use: Check NIC speed, duplex, or drop issues on physical servers.

---

📉 watch — Monitor command output live

Purpose: Run any command at intervals and watch changes.
Command:

watch -n 1 ip a  
watch -n 2 ss -tuln

DevOps Use: Watch network status during deployments or scaling events.

---

—————————————————————— Happy Learning ————————————————————