# Teaching Sequence and Analogies

How to teach this material to an 18–55 year old with no networking background, in sixty minutes, without lying to them. This note is the course design argument, not the content.

## The promise

By the end, a learner should be able to:

1. Describe what actually happens when they open a website, in the right order.
2. Read an IP address, a subnet mask and a port, and say what each one does.
3. Say why the internet is built from independent networks instead of one big one.
4. Name the three or four places a connection usually fails, and the first command they would run.
5. Explain one security decision (segmentation, TLS, zero trust) in terms of what it prevents.

That is achievable in an hour. "Understand networking" is not, and promising it is how courses lose people.

## The sequence, and why each step is where it is

| # | Module | The one question it answers | Why here |
|---|---|---|---|
| 1 | What a network is | Why can't everything just be one cable? | Motivation before mechanics |
| 2 | Packets and layers | How does one message survive the trip? | Gives the mental model everything else attaches to |
| 3 | Addresses | How does anything know where to go? | The vocabulary of every later module |
| 4 | Switching and the local network | How do neighbours talk? | The first hop, which is where most failures are |
| 5 | Routing | How does a packet cross the world? | Explains the internet as a system of networks |
| 6 | DNS and DHCP | How do you find and join a network? | The two services that make the rest usable |
| 7 | TCP, ports and TLS | How does a conversation stay reliable and private? | Ties transport to the user's experience |
| 8 | Wireless and the edge | Why is Wi-Fi different? | Their daily reality, and a different failure model |
| 9 | Security and segmentation | What stops one compromised machine taking everything? | Consequence of the architecture they now know |
| 10 | When it breaks | How do professionals diagnose this? | Turns knowledge into capability |

Notice what is late: BGP, OSPF, VXLAN, NAT rules. All are real and none are necessary to understand the first hour. They belong in the appendix and in the "what's next" list.

## One analogy per module, used consistently

| Concept | Analogy | Where the analogy breaks (say it out loud) |
|---|---|---|
| Packets | Letters in envelopes, in bags, on vans | Letters do not arrive out of order and get re-sorted |
| Layering | A shipping container: contents, box, manifest, truck | Layers do not need to be the same size |
| IP address | Postal address | Addresses get reused; houses do not move |
| MAC address | The name on the doorbell | A doorbell never changes when you move house |
| Subnet | A street with a numbering range | Streets cannot be split by arithmetic |
| Gateway | The only exit from the street | There is usually more than one exit in a city |
| Routing | Road signs at each junction, not a map of the country | Signs can be wrong, and are |
| DNS | A phone book, with many editions and caches | Phone books do not go stale in 30 seconds |
| DHCP | A hotel assigning rooms at check-in | Rooms are reserved; addresses are leased |
| TCP | A phone call with "did you get that?" | Calls do not have windows or congestion control |
| UDP | Postcards | Postcards usually do arrive |
| Ports | Flat numbers in a building | One flat can have many simultaneous conversations |
| TLS | A sealed, tamper-evident envelope with a notarised stamp | Sealing does not hide who is writing to whom |
| NAT | A receptionist with one outside phone line | The receptionist can be exhausted by too many calls |
| VLAN | Floors in a building with separate key cards | Floors cannot be moved without rewiring |
| BGP | Postal treaties between countries | Treaties are verified; BGP announcements mostly are not |
| Anycast | Several shops with the same name, nearest one serves you | Shops share inventory; anycast servers do not |
| Zero trust | Every door needs a key card, checked every time | Buildings do not check your device posture |

Rule: **one analogy per concept, reused verbatim**. Switching metaphors mid-course is what makes learners feel lost even when each explanation was fine.

## The four teaching moves that make it stick

1. **Start from a failure, not a definition.** "You type a name and nothing happens — where would you look?" teaches faster than "the OSI model has seven layers".
2. **Name the layer, then the tool.** Every module ends with one command the learner can run (`dig`, `ip route get`, `curl -v`, `ss -ltnp`, `tcpdump`).
3. **Show the number.** 1,500 bytes, 254 hosts, 3 packets in a handshake, 40 ms of latency. Concrete numbers are memorable; abstractions are not.
4. **Repeat the same walkthrough.** One website load, revisited in every module at a deeper level. By module 10 the learner has seen it six times from six angles.

## What to cut

- Classful addressing history (one sentence, then move on).
- Full OSI layer-by-layer trivia (the model is a debugging tool, not a syllabus).
- Cisco-specific CLI verbs before the concept is understood.
- Binary subnetting by hand for more than one example — teach block sizes instead.
- BGP attribute order (a reference, not a lesson).
- Any acronym without its failure mode attached.

## What to include even though it is hard

- **Subnetting arithmetic.** It is the one skill that makes everything else concrete, and it is learnable in ten minutes with block sizes.
- **The three-way handshake.** It is four words and it explains most latency and timeout behaviour.
- **Certificate expiry.** The single most common real outage; a two-minute explanation pays for itself.
- **Default deny.** The one security idea that changes how someone builds.

## Assessment that measures understanding

| Instead of | Ask |
|---|---|
| "Define a VLAN" | "Two PCs on different floors can ping each other but not the file server. What are the three most likely causes?" |
| "List the OSI layers" | "A user says the site is down. Which layer do you test first, and why?" |
| "What is NAT?" | "Why can't a customer connect to a server behind NAT without a rule?" |
| "Explain BGP" | "Why can one misconfigured network take down a country's internet?" |

Scenario questions expose the difference between memorisation and a model.

## Where this goes wrong

- **Teaching the map instead of the journey.** Seven layers, then forty protocols, then the learner has no idea what happens when they click.
- **Assuming prior knowledge of one specific vendor.** "Just `show run`" means nothing to someone who has never seen a switch.
- **Analogies that are load-bearing.** If the analogy breaks and the learner does not know where, they build a wrong model that survives for years.
- **Rushing the last module.** Diagnosis is the part they will actually use; it deserves a full sixth of the time.
- **No hands-on.** Sixty minutes of reading produces recognition, not capability. One `tcpdump` beats three diagrams.

## Related Notes

- [[Pedagogy/Where-It-Goes-Wrong.md]] — the misconceptions this sequence is designed to prevent
- [[Foundations/Network-Terminology.md]] — the vocabulary budget per module
- [[Labs/Home-Lab-Setup.md]] — the hands-on half
- [[Labs/Troubleshooting-Scenarios.md]] — assessment material