Files
rootnode-academy/content/root/root-02-linux-administration-networking/m03-networking-mental-model/01-lesson-networking-mental-model.md
T
ced4568andClaude Sonnet 5 e007bcf000 feat(root02): author Linux Administration & Networking
Adds all 6 ROOT 02 modules (Linux system administration, storage & filesystems, the
Networking Mental Model, Linux network inspection, DNS & HTTP, Linux troubleshooting) — 37
activities, each with a real lesson, demonstration/guided exercise, knowledge check, hands-on
Lab, and reflection. The Networking Mental Model module (M3) gets deliberately extra depth per
its "critical module" designation, with no lab by design — conceptual mastery via knowledge
check and guided exercise, matching root-05-m00's own precedent.

Adds 6 new hands-on Linux/networking scenarios plus 2 MCQs: linux-service-inspection (inspects
the platform's own real nginx without touching it — a genuinely safe, real service-inspection
target that avoids ever risking the Lab's own connectivity), linux-service-lifecycle (start/
verify/stop a fully controllable service), linux-storage-inspection, linux-network-inspection
(ip/ss/getent/curl, each framed as answering one specific diagnostic question),
linux-dns-http-diagnosis (a genuine DNS-resolves-but-wrong-port failure, diagnosed and fixed),
and linux-troubleshooting-framework (a real missing-config-file failure, resolved via the
RootNode Observe/Evidence/Hypothesis/Test/Repair/Validate/Prevent framework). All tested
end-to-end via the real scenario-validation API, including negative tests confirming they fail
when unsolved.

Wires rootnode-linux-networking-assessment (2 required + 4 random-draw scenarios) using the
existing Phase 3B assessment engine.

Co-Authored-By: Claude Sonnet 5 <[email protected]>
2026-08-26 17:07:46 -05:00

5.2 KiB

Networking Mental Model

Why this module gets extra attention

Nearly everything you'll do for the rest of ROOT_ — container networking, Kubernetes Services, Ingress, NetworkPolicy, DNS, cloud infrastructure — is a variation on the SAME small set of ideas this module introduces. Get this model solid now, and every later networking topic becomes "the same thing again, one layer up." Skip it, and every later module will feel like memorizing unrelated facts. The goal here is operational REASONING, not subnet arithmetic — you will not be asked to calculate a subnet mask by hand.

The chain, layer by layer

Think of reaching another machine as passing through a fixed sequence of layers, each of which can independently succeed or fail:

Host
  ↓
Network interface       (this machine's connection to a network)
  ↓
IP address               (this machine's address on that network)
  ↓
Subnet                   (which other addresses are "local" to reach directly)
  ↓
Default gateway           (where to send anything NOT local)
  ↓
Routing                   (the actual path traffic takes)
  ↓
DNS                       (translating a name into an IP address)
  ↓
Port                      (which specific service on that IP)
  ↓
TCP / UDP                 (how the connection itself behaves)
  ↓
Application protocol      (HTTP, etc. — the actual conversation)

Each layer, briefly

  • Network interface — your machine's actual network connection (eth0, etc.). No interface, no networking, full stop.
  • IP address — this machine's address on a given network. IPv4 addresses look like 172.17.0.2. 127.0.0.1 (aka localhost) is special: it always means "this same machine," never anywhere else. 0.0.0.0 is different again — when a SERVICE binds to it, it means "listen on every interface this machine has," not a real destination address.
  • Subnet — a range of addresses considered "local" to each other, expressed as CIDR (172.17.0.0/16 means every address starting 172.17.). You don't need to calculate subnet math by hand — you need to recognize that two addresses in the same subnet can talk directly, while addresses outside it need a gateway.
  • Default gateway — the address your machine sends traffic to when the destination ISN'T in its own subnet — effectively "ask this router to figure out the rest."
  • Routing — the actual decision-making about which path traffic takes; ip route shows your machine's routing table (Module 4 makes this hands-on).
  • DNS — translates a human-readable name (example.com) into an IP address, since IP addresses aren't what humans want to remember or type.
  • Port — a single IP address can host MANY services simultaneously; the port number is what distinguishes "which one." Port 80 conventionally means HTTP, 443 HTTPS, 22 SSH — conventions, not hard rules.
  • TCP vs. UDP — TCP is connection-oriented and guarantees delivery/order (most web traffic, SSH); UDP is connectionless and faster but delivers no guarantees (DNS queries themselves, video streaming). Client/server: one side (the server) listens on a fixed port waiting for connections; the other (the client) initiates them.

The reasoning skill: "where is the failure?"

Given this chain, a real diagnostic question decomposes into a sequence of yes/no checks, each isolating ONE layer:

  • Does the host have an IP address at all?
  • Is the destination local (same subnet) or remote?
  • Is there a valid route to it?
  • Can the name resolve to an IP?
  • Can the destination PORT actually be reached?
  • Is a service actually listening there?
  • Does the application itself respond correctly?

Module 4 makes each of these a real command. Module 5 walks the complete request path end to end. Module 6 formalizes this into RootNode's troubleshooting framework, applied to networking specifically.

Instructor Notes

Lesson goal: This module gets outsized weight for a reason — it's the single highest- leverage conceptual investment in ROOT 02. Do not rush it to "cover the topics"; depth here pays off across ROOT 04, ROOT 05-10, and beyond.

Approximate timing: 25 minutes read; 15-20 minutes live with discussion — longer than a typical lesson, deliberately.

Common misconception to watch for: treating 0.0.0.0 as a real destination address rather than a "listen on every interface" bind convention — this genuinely confuses students later when they see it in a container's own listening-port output.

Discussion question: Walk through a real failure narrative live: "You curl a URL and get 'Connection refused.' Which layers does that rule OUT, and which remain suspects?" (Answer: rules out DNS entirely — you got FAR enough to attempt a TCP connection — and rules out "nothing is listening at all" being the ENTIRE problem elsewhere; "refused" specifically means something actively rejected the connection, most often nothing listening on that exact port.)

Optional extension: contrast "Connection refused" vs. "Connection timed out" vs. "Could not resolve host" as three DIFFERENT failure signatures pointing at different layers — worth a full discussion pass if time allows, since Module 5 depends on students already sensing this distinction.