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]>
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(akalocalhost) is special: it always means "this same machine," never anywhere else.0.0.0.0is 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/16means every address starting172.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 routeshows 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.