Chapter 25 — Laboratory I

Lesson map

Lesson 25 published. Map, example, EX073.

flowchart TD
  N0["Learning outcomes"]
  N1["25.1 Why a lab"]
  N2["25.2 Designing tests"]
  N3["25.3 Running and recording"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX073"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["25.1 Why a lab"]
  N2["25.2 Designing tests"]
  N3["25.3 Running and recording"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX073"]

[Learning outcomes]
    |
    v
[25.1 Why a lab]
    |
    v
[25.2 Designing tests]
    |
    v
[25.3 Running and recording]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX073]

Learning outcomes

You will (1) build a lab network; (2) test rules safely; (3) record results.

25.1 Why a lab

Changing a live clinic network to test ideas would risk disrupting patient care. A lab reproduces the important parts on spare equipment or virtual machines: four groups, a firewall with the proposed rules and test devices in each group. Priya's lab runs entirely on university equipment, uses invented addresses and has no connection to the clinics. Mistakes in a lab cost only time, so it is the right place to learn how rules behave and to make the errors that would be serious elsewhere.

25.2 Designing tests

Tests come from requirements. For R1, Priya tries connections from a test device in the guest group to each other group and expects all to fail; she also checks guest can still reach the internet, so the test catches over-blocking. For each needed flow, she tests that it works. For a few flows, she tests neighbouring ports to confirm rules are not broader than intended. Every test has an expected result written in advance, so outcomes are judged against predictions rather than explained afterwards.

25.3 Running and recording

Priya runs the tests and records each result with the date, the rule set version and the outcome. Two tests fail: clinical carts cannot reach the lab results server because she forgot the server listens on a second port, and guest devices can reach the management group's web page because of a typo in a subnet. Both are fixed and the full set is rerun. Recording failures, not just final passes, shows how the design improved and helps her tutor see her reasoning.

25.4 Limits of the lab

A lab is not the real network. It has fewer devices, simpler traffic and no forgotten equipment hidden in a cupboard. Passing lab tests is necessary but not sufficient. Priya lists differences between lab and clinics, such as the real clinics having a printer shared between groups, and plans checks in the real environment for each difference. Being honest about lab limits prevents overconfidence when the design is finally deployed. She also records which lab results she expects to differ in the clinics and how she will check them on site.

Worked example

Of twenty lab tests, eighteen pass at first; after two fixes, all twenty pass.

Synthetic case. Lab results are synthetic.

Errors and limits

Testing only that permitted flows work misses rules that allow too much.

Exercises

• EX073 — Over-blocking check. Why test that guests can still reach the internet?
  Show marking criteria

  Rubric: 3 = detect over-blocking as well as under-blocking;; 2 = both;; 1 = unnecessary;; 0 = none.
• EX074 — Typo failure. What did the guest-to-management failure reveal?
  Show marking criteria

  Rubric: 3 = subnet typo allowing access;; 2 = typo;; 1 = vague;; 0 = none.
• EX075 — Lab limits. Name one difference between the lab and real clinics.
  Show marking criteria

  Rubric: 3 = shared printer, more devices, hidden equipment;; 2 = one;; 1 = vague;; 0 = none.

Synthesis

A safe lab with requirement-based tests catches errors before they reach a live network.

Continue studying — chapter 25 of 40

← Chapter 24 (draft) · Course chapter index · Chapter 26 (draft) →