Networking course
OSI and TCP IP without vague explanations
- AccuracyExact terms, careful definitions, and clear boundaries.
- TroubleshootingA method you can apply on real systems.
- SecurityLayer aware controls without unsafe attacking.
This course uses OSI and TCP IP as models. They are not competing religions. They are tools for thinking. The goal is that you can explain a network problem using evidence and a small number of correct terms.
⏱️CPD timing
CPD timing
Time estimate (transparent)
I publish time estimates because CPD needs to be defensible. The goal is honesty, not marketing.
Guided learning
40h
Core levels, structured learning
Practice and consolidation
2h
Summary, drills, revisits
Notional range
28 to 60 hours
Quick: core concepts + one exercise per module. Standard: exercises + reflections for CPD evidence. Deep: extra drills and portfolio artefacts.
How I estimate time
I use a notional learning hours approach and I keep the assumptions visible. Where modules are content heavy, I add practice so the hours are earned, not claimed.
- Reading: 225 words per minute, multiplied by 1.3 for note taking and checking understanding.
- Labs and practice: about 15 minutes per guided activity, including at least one retry.
- Reflection for CPD: about 8 minutes per module for a short defensible note and evidence link.
- Assessments: about 1.4 minutes per question for reading, thinking, and review.
If you study faster or slower, your hours will differ. What matters is that the method is consistent and the activities are real.
🧪Assessment blueprint
Assessment and practice assessment
Network models assessment blueprint
This assessment checks layered reasoning and troubleshooting discipline. It is not a vendor exam, but it prepares you for the style of thinking those exams expect.
Foundations
mixedCorrect vocabulary and correct layering. Encapsulation and flows explained cleanly.
Applied
scenarioProve behaviour with evidence. TCP, UDP, NAT, routing, TLS, and common failure modes.
Practice and Strategy
scenarioOperational reasoning, monitoring signals, and layer-aware security controls.
Design rules
- Questions must force the learner to place the fault in the stack and justify the evidence.
- Where OSI and TCP/IP differ, the marking must accept correct real world interpretations, not only diagram answers.
📚Standards and certifications
Standards and certifications
The map we anchor to
I map each course to reputable standards so your learning is defensible at work. I also show common certifications and how their language differs.
Important: This content aligns with these standards and certifications for learning purposes. This is guidance, not endorsement. We are not affiliated with certification providers unless explicitly stated.
Primary anchor standards
- Core Internet RFCs (DNS, TCP/IP, TLS)IETF
The most honest anchor for networking. We can point to the mechanism, not just the diagram.
Official reference
Certification routes
This course is not endorsed by certification bodies. It is built to prepare you honestly, including where exams simplify reality.
- foundationCompTIA Network+CompTIA
A clear baseline for people new to networking terms and troubleshooting thinking.
- practitionerCisco CCNACisco
A widely recognised practical route that forces you to learn how networks actually behave.
Organisations and resources
These are the kinds of organisations professionals reference. If you learn how to use them properly, you become harder to mislead.
- IETF
What it is: The Internet Engineering Task Force, publisher of RFCs.
Why it matters: If you want accuracy, you eventually have to read the source material.
- ICANN and IANA
What it is: Organisations that coordinate naming and numbering on the Internet.
Why it matters: Helps you understand who controls what in DNS and IP allocation.
🧾Terminology translation
Terminology translation
DNS and trust
DNS is simple until it breaks. Then it becomes a chain of responsibility and caching decisions.
Authoritative versus recursive resolver
Plain English
Authoritative servers know the answer for a zone. Recursive resolvers find answers on your behalf and cache them.
How standards use it
DNS (RFC 1034 and RFC 1035)
Defines how name resolution works and how roles differ across the system.
Common mistake
Blaming DNS as one thing when the failure is in caching, recursion, or authority.
My take
DNS is a chain of responsibility. Debug it like a chain, not like a mystery.
Quick check
Where does caching happen in DNS resolution and why does it matter?
TTL
Plain English
How long a resolver should cache an answer.
How standards use it
DNS caching behaviour
TTL drives propagation delays and how quickly changes take effect.
Common mistake
Setting TTL too high and then being confused when changes do not show up.
My take
TTL is not a suggestion. It is the waiting time you asked for.
Quick check
Why might you lower TTL before a planned DNS change?
DNSSEC
Plain English
Adds authenticity checks for DNS responses. It does not encrypt DNS.
How standards use it
DNSSEC (RFC 4033 to RFC 4035)
Adds signature based validation so clients can detect tampering.
Common mistake
Thinking DNSSEC hides which domains you visit.
My take
DNSSEC is integrity, not secrecy.
Quick check
What does DNSSEC prove and what does it not prove?
🧭Core path
Core path
OSI and TCP IP Foundations
Encapsulation, addressing, and the purpose of layers, explained with exact terms and safe labs.
Applied OSI and TCP IP
Layer by layer behaviour with TCP, UDP, routing, NAT, and TLS, with realistic troubleshooting.
Network Models for Security and Operations
Security, monitoring, and operations thinking built on correct network foundations, without unsafe attacking.
Summary and practice
Recap the models, test your understanding, and practise troubleshooting without guesswork.
🧩What you will build
🧩Module coverage matrix
Coverage matrix
Module-level coverage
This matrix makes the course defensible: each module is tied to an outcome focus, the anchor standards, and the evidence you can produce.
| Level | Module | Outcome focus | Domains | Alignment | Assessment | Evidence |
|---|---|---|---|---|---|---|
| Foundations | Models Exist net-foundations-why-models-exist Anchors: Core Internet RFCs (DNS, TCP/IP, TLS) | Use OSI/TCP-IP as reasoning tools and avoid treating them as religions. | models | Other: Layered reasoning | Practice + timed | Template + rubric |
| Foundations | And Pdus net-foundations-encapsulation-and-pdus Anchors: Core Internet RFCs (DNS, TCP/IP, TLS) | Explain encapsulation correctly and use PDUs to locate problems. | layers | Other: Layering and encapsulation | Practice + timed | Template + rubric |
| Foundations | And Tcpip Mapping net-foundations-osi-and-tcpip-mapping Anchors: Core Internet RFCs (DNS, TCP/IP, TLS) | Translate between OSI and TCP/IP without losing real-world correctness. | models | Other: Model mapping | Practice + timed | Template + rubric |
| Foundations | Layers Detail net-foundations-osi-layers-detail Anchors: Core Internet RFCs (DNS, TCP/IP, TLS) | Place behaviours and controls at the correct layer and justify why. | layers | Other: Layer responsibilities | Practice + timed | Template + rubric |
| Foundations | And Names net-foundations-addressing-and-names Anchors: Core Internet RFCs (DNS, TCP/IP, TLS) | Reason about names, addresses, and identifiers across layers (DNS, IP, MAC). | addressing | Other: Addressing and naming | Practice + timed | Template + rubric |
| Foundations | Basics net-foundations-subnetting-basics Anchors: Core Internet RFCs (DNS, TCP/IP, TLS) | Use subnetting concepts to reason about reachability and blast radius. | addressing | Other: Network boundaries | Practice + timed | Template + rubric |
| Foundations | From Browser To Server net-foundations-requests-from-browser-to-server Anchors: Core Internet RFCs (DNS, TCP/IP, TLS) | Explain end-to-end flows from browser to server with evidence and correct terms. | flows | Other: End-to-end flow reasoning | Practice + timed | Template + rubric |
| Foundations | Capstone net-foundations-foundations-capstone Anchors: Core Internet RFCs (DNS, TCP/IP, TLS) | Produce a clear encapsulation storyboard that you can defend. | layers, communication | Other: Evidence-friendly explanation | Practice + timed | Template + rubric |
| Applied | Reliability And Flow net-applied-tcp-reliability-and-flow Anchors: Core Internet RFCs (DNS, TCP/IP, TLS) | Diagnose TCP reliability and flow behaviour with evidence rather than guesses. | transport | Other: Transport reasoning | Practice + timed | Template + rubric |
| Applied | Resolution In Practice net-applied-dns-resolution-in-practice Anchors: Core Internet RFCs (DNS, TCP/IP, TLS) | Debug DNS resolution with the resolver path, caching, TTLs, and timings. | dns | Other: DNS evidence discipline | Practice + timed | Template + rubric |
| Applied | And Real World Trade Offs net-applied-udp-and-real-world-trade-offs Anchors: Core Internet RFCs (DNS, TCP/IP, TLS) | Choose UDP/TCP based on real trade-offs and application constraints. | transport | Other: Protocol trade-offs | Practice + timed | Template + rubric |
| Applied | And Forwarding net-applied-routing-and-forwarding Anchors: Core Internet RFCs (DNS, TCP/IP, TLS) | Locate faults in routing/forwarding and prove where packets stop. | routing | Other: Routing and forwarding | Practice + timed | Template + rubric |
| Applied | And State net-applied-nat-and-state Anchors: Core Internet RFCs (DNS, TCP/IP, TLS) | Understand NAT state and its failure modes for troubleshooting. | nat | Other: Stateful translation | Practice + timed | Template + rubric |
| Applied | Where It Sits net-applied-tls-where-it-sits Anchors: Core Internet RFCs (DNS, TCP/IP, TLS) | Place TLS correctly in the stack and avoid incorrect layer explanations. | tls | Other: Security placement | Practice + timed | Template + rubric |
| Applied | Method net-applied-troubleshooting-method Anchors: Core Internet RFCs (DNS, TCP/IP, TLS) | Use a repeatable layer-wise troubleshooting method under pressure. | troubleshooting | Other: Method and evidence | Practice + timed | Template + rubric |
| Applied | Capstone net-applied-applied-capstone Anchors: Core Internet RFCs (DNS, TCP/IP, TLS) | Produce a layer-wise troubleshooting worksheet for repeatable practice. | troubleshooting | Other: Evidence artefact | Practice + timed | Template + rubric |
| Practice | By Layer net-practice-security-by-layer Anchors: Core Internet RFCs (DNS, TCP/IP, TLS) | Map security controls to layers where they work and where they can be observed. | security | Other: Layer-aware security | Practice + timed | Template + rubric |
| Practice | And Signals net-practice-observability-and-signals Anchors: Core Internet RFCs (DNS, TCP/IP, TLS) | Choose operational signals that prove behaviour and detect failures early. | observability | Other: Operational signals | Practice + timed | Template + rubric |
| Practice | Without Hacking net-practice-captures-without-hacking Anchors: Core Internet RFCs (DNS, TCP/IP, TLS) | Use captures for evidence without unsafe offensive behaviour. | observability | Other: Safe evidence practice | Practice + timed | Template + rubric |
| Practice | Segmentation net-practice-enterprise-segmentation Anchors: Core Internet RFCs (DNS, TCP/IP, TLS) | Reason about segmentation and blast radius in enterprise environments. | security, segmentation | Other: Segmentation and controls | Practice + timed | Template + rubric |
| Practice | Practice Capstone net-practice-capstone Anchors: Core Internet RFCs (DNS, TCP/IP, TLS) | Produce a security-by-layer map and the signals you would monitor. | security, observability | Other: Defensible practice output | Practice + timed | Template + rubric |
📚How to use this course
2. Use one lab to confirm the idea.
3. Write down what you observed and what you assume.
🛠️Quick practice
Checkpoint
What does encapsulation mean
What is a useful way to use OSI
What is the danger of layer talk