Most networking issues are not complex.
They are invisible.
You run a command… and it fails.
You blame the application… but the problem lives deeper.
Networking is not one thing. It’s a sequence of decisions.
Let’s break it down step by step.
Network Routing & Connectivity
The Local Neighborhood
Before anything else, systems must exist in the same network.
If two machines share the same subnet, they communicate through a switch.
Example:
ip addr add 192.168.1.10/24 dev eth0
ip addr add 192.168.1.11/24 dev eth0
Now both systems can talk directly.
As shown in the diagram on page 2, communication within a subnet doesn’t require routing at all. :contentReference[oaicite:0]{index=0}
Switching vs Routing
Switches keep communication inside a network.
Routers connect different networks.
If System A cannot reach System B across subnets, the issue is not connectivity — it’s missing routing.
The diagram on page 3 shows this clearly: switches isolate, routers connect.
Anatomy of a Routing Table
Every packet follows the routing table.
Key components:
- Destination → where traffic is going
- Gateway → next hop
- Interface → where it exits
Check it:
ip route show
The visual on page 4 explains how the kernel decides packet flow using these fields.
Forging the Path (Manual Routing)
Sometimes Linux doesn’t know where to send traffic.
You need to tell it.
Example:
ip route add 192.168.2.0/24 via 192.168.1.1
Now traffic for that subnet flows through the router.
But routing is always two-way.
As shown on page 5, both sides must understand the path for communication to work.
The Default Gateway
Instead of defining routes for everything, Linux uses a catch-all route.
ip route add default via 192.168.2.1
If no specific match exists, traffic falls into this funnel.
The diagram on page 6 calls this the “catch-all funnel” — and that’s exactly what it is.
Enabling IP Forwarding
Even with correct routes, Linux won’t forward packets by default.
That’s intentional.
To enable routing behavior:
Temporary:
echo 1 > /proc/sys/net/ipv4/ip_forward
Permanent:
/etc/sysctl.conf
net.ipv4.ip_forward=1
This shows as a “valve” — closed by default, open when enabled.
DNS & Name Resolution
The Local Address Book (/etc/hosts)
Before querying DNS, Linux checks local mappings.
192.168.1.11 db
192.168.1.11 test
This overrides DNS completely.
As shown on page 9, this acts as an “absolute authority” for name resolution.
The Scale Problem & Central DNS
Local files don’t scale.
Imagine updating /etc/hosts across 50 machines.
That’s why DNS exists.
The *diagram * shows how centralized DNS replaces manual mappings.
Resolution Order (The Switchboard)
Linux follows a strict order:
/etc/hosts- DNS (
/etc/resolv.conf)
The decision is controlled by:
/etc/nsswitch.conf
As shown on page 12, this file acts like a traffic controller for name resolution. :contentReference[oaicite:8]{index=8}
DNS Hierarchy
DNS is not flat.
It follows a hierarchy:
Root → TLD (.com) → Domain → Subdomain
The *diagram * explains how queries move through this chain until an IP is found.
Diagnostic Tools
When things break, use:
-
ping→ connectivity -
nslookup→ DNS query -
dig→ deep debugging
Important:
nslookup and dig bypass /etc/hosts.
As shown , they directly query DNS servers.
DNS Record Types
Core records you must know:
- A → IPv4 address
- AAAA → IPv6 address
- CNAME → alias
Example:
web-server -> 192.168.1.1
api -> web-server
The Complete Packet Journey
Let’s connect everything:
- System checks
/etc/hosts - Queries DNS if not found
- Resolves to IP
- Checks routing table
- Uses default gateway if needed
- Packet flows through network
The *final diagram * shows this entire journey end-to-end.
Final Insight
Networking is not a single command.
It is a chain of decisions.
If something breaks, debug in order:
- Name resolution
- Routing
- Gateway
- Forwarding
Most engineers debug from the top.
The best engineers debug from the bottom.
🎥 Visual walkthrough of this entire flow:
[https://youtu.be/THizu-hevLE]
If this helped, follow for more DevOps and system design breakdowns.
Top comments (0)