📦 The Packet Delivery Story
Think of networking like delivering a parcel. This one mental model connects DNS, IP addresses, routing, ports, and the OSI model.
App asks
curl google.com wants a webpage.
DNS finds it
DNS resolves the hostname to one or more IP addresses so the client knows which network destination to contact.
Linux routes
The route table decides local delivery or gateway.
Bits travel
Frames and packets move through LAN, router, or Internet.
Port finds app
The destination port selects the service endpoint; ports 80 and 443 are commonly used for HTTP and HTTPS.
Server replies
The answer travels back to the client.
🧠 Visual Memory Anchors
These pictures are deliberately simple. They are meant to be remembered while troubleshooting at a terminal.
🏠 IP = House Address
🏘️ Subnet = Neighborhood
🚪 Gateway = Exit Gate
📖 DNS = Contact Book
→ IP address
🏢 Ports = Numbered Doors
SSH
DNS
HTTP
HTTPS
👂 Listener = Someone Waiting
Learning Objectives
Understand addressing
Identify what an IP address, subnet, and gateway do in a Linux network.
Understand name resolution
Explain why google.com needs DNS before the system can connect.
Test connectivity
Use ip, ping, ss, and curl for first-level checks.
Core Concepts
Before troubleshooting networking, trainees must understand these building blocks.
IP Address
An IP address is a logical address assigned to a network interface or endpoint. Example: 192.168.1.10.
System identificationIPv4: 192.168.1.10IPv6: fe80::1Subnet
A subnet defines which IP addresses are local to your network. Example: 192.168.1.0/24.
In beginner terms, systems like 192.168.1.10 and 192.168.1.20 are usually local to each other in a /24 subnet.
Gateway
A gateway is a next-hop router. For destinations without a more specific route, Linux commonly uses the default gateway/default route.
Example: Your laptop uses 192.168.1.1 to reach the Internet.
DNS
DNS resolves names to resource records, commonly IPv4 or IPv6 addresses. Example: google.com → one or more IP addresses.
If an IP ping works but ping google.com reports a name-resolution error, suspect DNS. If the name resolves to an IP but there is no echo reply, ICMP may simply be blocked.
Ports
A port number helps identify a transport-layer service endpoint. The IP identifies the host/interface; the transport protocol plus port helps deliver traffic to the correct socket/service.
| Port | Common / conventional service |
|---|---|
| 22 | SSH |
| 53 | DNS |
| 80 | HTTP |
| 443 | HTTPS |
Listening Services
A service is listening when it is waiting for network connections on a port.
Example: SSH server listens on port 22.
Animated OSI Flow: Client to Server
The animation below now runs automatically using CSS. The buttons are optional controls; the packet should move even if you do not click anything.
Client Sending Data
Data starts at the client application, moves down the client stack, crosses LAN/Internet, then moves up the server stack.
Server Receiving Data
Beginner explanation: what happens when you run curl google.com?
Application: curl wants to connect to google.com.
DNS: The system asks DNS for the IP address of google.com.
Transport: The client opens a TCP connection to a destination port, usually 80 or 443.
Network: Linux checks the route table to decide whether to send locally or through the gateway.
Data Link / Physical: Data leaves through the network interface using Ethernet or Wi‑Fi.
Server: The remote server receives the request and sends a response back.
Linux Networking Command Reference
These are the minimum commands a beginner should know before troubleshooting Linux connectivity.
Show IP addresses
Use this to see interfaces like lo, eth0, ens33, wlan0, and assigned IP addresses.
What to observe
Look for inet for IPv4, inet6 for IPv6, and interface state like UP or DOWN.
Show route table
Use this to find the default gateway and routing path.
What to observe
The line starting with default via shows the gateway used to reach other networks and the Internet.
Ping public IP
This tests ICMP reachability to one specific public IP address without depending on DNS. A failed ping does not by itself prove that Internet access is down.
What to observe
Success: replies show that IP connectivity likely works. Stop ping using Ctrl+C.
Failure: check the local interface/address, route table, gateway, host/network firewall rules, target filtering, or the upstream network. HTTP proxy settings do not control ICMP ping.
Ping domain name
This tests name resolution and then ICMP reachability to the resolved address. Distinguish a DNS resolution error from a resolved host that simply does not answer ICMP.
What to observe
If ping 8.8.8.8 works but ping google.com reports a resolver error such as Name or service not known, suspect DNS. If the hostname resolves but echo replies do not arrive, DNS may be fine.
Optional DNS-only check:
This asks the system name-service stack for address records without depending on ICMP echo replies.
Show listening services
Use this to see TCP/UDP ports that local services are listening on.
What to observe
t = TCP, u = UDP, l = listening, n = numeric, p = process.
Use sudo ss -tulnp if process details are hidden.
Test HTTP using curl
Use this to test whether an application-level HTTP request works.
What to observe
You may see HTML, redirect output, or a message telling you the site has moved. For headers only, use:
Hands-on Lab: Basic Network Inspection
Run these commands on a Linux VM. The goal is not to memorize output, but to learn what each command proves.
Lab 1: Check IP address
Task: Identify your active interface and write down its IPv4 address.
Lab 2: Check default gateway
Task: Find the default via line.
Lab 3: Test public-IP ICMP reachability
Task: Check whether your system receives ICMP echo replies from this public IP address.
Lab 4: Test DNS
Task: Compare this result with ping 8.8.8.8. If you need to separate DNS from ICMP behavior, also try getent ahosts google.com.
Lab 5: Check listening ports
Task: Identify at least two listening ports and the local addresses they bind to.
Beginner notes
127.0.0.1:port means local only. 0.0.0.0:port means all IPv4 interfaces. :::port usually means IPv6 interfaces.
Lab 6: Test web access
Task: Verify whether your system can make an HTTP request from the terminal.
Beginner Troubleshooting Flow
Use this simple decision path when a Linux machine cannot reach the network.
Scenario A: Internet not working
ip a — Does the interface have an IP?
ip r — Is there a default gateway?
ping 8.8.8.8 — Can the system reach a public IP?
ping google.com — Can the system resolve names?
curl google.com — Does HTTP work?
Scenario B: Service not reachable
Check service status or process list.
ss -tulnp — Is the expected port open?
127.0.0.1 means local only; 0.0.0.0 means all IPv4 interfaces.
Check host firewall and network firewall rules.
Try IP address directly, then hostname.
| Symptom | Likely Area | First Command |
|---|---|---|
| No IP address | Interface / DHCP / static config | ip a |
| No default route | Gateway / route config | ip r |
| IP ping works, hostname gives resolution error | DNS | ping google.com |
| Server reachable but app fails | Port / service / firewall | ss -tulnp |
| Browser fails but ping works | HTTP/HTTPS/proxy/application layer | curl -I https://example.com |
Trainer Notes
Recommended delivery sequence
Explain IP, subnet, gateway using a home Wi‑Fi or office LAN example.
Run ip a and ip r live on a Linux VM.
Compare ping 8.8.8.8 and ping google.com.
Use ss -tulnp to explain ports and listening services.
Use OSI animation to connect commands with networking layers.
Common beginner mistakes
Mistake: Thinking IP address and hostname are the same thing.
Mistake: Assuming ping failure always means Internet is down. ICMP may be blocked.
Mistake: Ignoring gateway when external connectivity fails.
Mistake: Seeing a service on 127.0.0.1 and expecting remote systems to connect to it.
🎯 Networking Field Missions
Run each mission on a Linux VM. Tick it only when you can explain what the result proves. Progress is saved locally in your browser.
🪪 Find your identity
Find the active interface and its IPv4 address.
🚪 Find the exit
Find the default route and gateway.
🌎 Test raw reachability
Observe replies, latency, and packet loss. Remember ICMP may be blocked.
📖 Test DNS
Compare this with the IP-only ping.
👂 Inspect listeners
Find one TCP listener and explain its bind address.
🌐 Test the application
Find the HTTP status line and headers.
🕵️ Real-World Troubleshooting Challenges
Choose the strongest next action based on the evidence — not a random command.
Ticket #1 — Name resolution failure
ping 8.8.8.8 works. ping google.com fails to resolve the name.
Ticket #2 — App works only locally
ss -tulnp shows 127.0.0.1:8080.
Ticket #3 — No external connectivity
ip a looks normal, but ip r has no default route.
Ticket #4 — Ping fails, web works
Browser and curl work normally, but the host does not reply to ping.
🧠 Click-to-Flip Recall Cards
Try to answer in your head first, then click the card.
Click to reveal
Also inspect interface state.
Click to reveal
Usually shown as default via.
Click to reveal
Hostname lookup before connecting.
Click to reveal
Common SSH server port.
Click to reveal
Remote systems normally cannot connect directly.
Click to reveal
curl can exercise DNS, TCP, TLS and HTTP.
Identity
Neighborhood
Exit path
Name lookup
App door
Waiting app
Knowledge Check
Click an answer to check understanding.
One-page Lab Sheet
Commands to practice:
Ask trainees to write what each command proves: IP configuration, gateway route, ICMP reachability to a public IP, DNS resolution, listening services, and application-level web access.