Capstone 2: Build and Configure

Capstone 2: Build and Configure

What you'll learn

• Build a five-VLAN, two-switch, one-router network in stages, verifying at every gate
• Configure VLANs and a trunk that actually carries them, on both switches
• Configure inter-VLAN routing on router subinterfaces (router-on-a-stick) with 802.1Q encapsulation
• Deliver addresses from a central server across VLANs with DHCP relay — and know why the guest segment cannot use it
• Translate an entire studio to one public address with PAT, while deliberately excluding one segment
• Enforce guest isolation and camera egress denial with access lists, and prove both with evidence
• Read the three verification artifacts that finish any build: the ping matrix, the lease list, and the translation table

This lesson synthesizes Chapters 4 through 8 of Dr. Tahseen Al-Doori's Network Essentials: the components chapter's switches and routers, the addressing and routing chapters' subnets and gateways, the Ethernet chapter's links and speeds, and the wireless chapter's access points and security. The book teaches each of them separately, as it must. Real networks are all of them at once — which is exactly the difficulty this lesson exists to give you.

The rule of this lesson: stage, verify, then continue

There is one professional habit that matters more than any command in this lesson, so it goes first.

Never build past a broken stage. A network build is a stack of dependencies: addressing depends on VLANs, DHCP depends on addressing, translation depends on routing, policy depends on everything. If you configure all nine stages and then test, a single mistyped digit in stage 2 will produce a symptom in stage 8 — and you will spend an hour hunting in the wrong place. If instead you verify at the end of every stage, that same mistyped digit is caught while it is the only thing that has changed since the last known-good state.

This is not merely lab hygiene; it is how professional changes are made. Each stage below ends with a gate: two or three checks with an expected result. Pass the gate, save the file with the stage's name, continue. Fail the gate, fix it now. The saved file at each stage is also your rollback, which Module 8's method insisted on before you touch anything.

Budget your two hours roughly like this: forty minutes to place, cable and configure the switches and the router; forty minutes for services (DHCP, DNS, wireless); twenty minutes for translation and policy; twenty minutes for the verification checklist and evidence capture. If you fall behind, the stage to protect is the last one — a build without verification evidence is not finished, it is merely quiet.

A convention for this lesson. Where a command needs a value from your design, it appears in braces: {VLAN 10 network}, {VLAN 20 gateway}. Braces and all are replaced by your own number; nothing in braces is ever typed literally. Values that are the same for everyone — VLAN numbers, interface names, and the public-side addresses of the simulated Internet — are written out in full.

What the simulator does differently

Three honest notes before you build, because a good engineer knows where the model departs from the world.

One SSID per access point. Real small-business access points broadcast several SSIDs from one radio, each mapped to a different VLAN — that is exactly how you get a staff network and a guest network out of two physical devices. Packet Tracer's access point object carries a single SSID. So in the simulator you will place four access-point objects to represent the studio's two physical access points: a staff SSID and a guest SSID on each floor. Note that substitution in your dossier; it is a modelling decision, not a design change, and the bill of materials from Lesson 1 still says two access points.

Wireless security options lag the standard. Your design says WPA3-Personal, or WPA2/WPA3 transition mode, because that is 2026 practice and Module 6 explained why. The simulator's access points offer WPA2-PSK with AES as their strongest realistic option. Configure WPA2-PSK/AES in the build, and record in your dossier that the production requirement is WPA3 — with the transition-mode fallback and its justification. Building to the simulator's limit while documenting the real requirement is precisely what you would do with any hardware that lagged a standard.

Power over Ethernet is invisible here. The simulator will happily run an access point or a camera with no thought about watts. Your bill of materials still has to be honest about PoE, because the real installation will not be.

Stage map

Lab: Packet Tracer Capstone — the Meridian build

Objective. Implement your Lesson 1 design in Packet Tracer, stage by stage, and produce three verification artifacts — a completed ping matrix, a DHCP lease record, and a NAT translation table — that together prove every requirement in your register.

Setup. Packet Tracer (installed back in Module 3). Your Lesson 1 design document, open. Download: Capstone Verification Checklist, printed — you will be ticking it as you go, not afterwards. Start a new blank file and save it immediately as m9-capstone-stage0.

---

Stage 0 — plan on screen.

1. Put your addressing table, reachability table and wiring schematic where you can read them without switching windows. Every value you type for the next two hours comes from those tables. If you find yourself inventing a number mid-build, stop: that number belongs in the design document first.

---

Stage 1 — place and cable.

2. Place these devices: one 1941 router (the studio's router/firewall, name it MERIDIAN-RTR), two 2960 switches (SW1-FLOOR1, SW2-FLOOR2), one Server-PT (the studio server), one more Server-PT or PC to stand in for the NAS, one printer, two PCs to stand in for the cameras, and enough PCs to represent at least two design workstations and two business laptops. Wireless devices come in stage 7.
3. Place the simulated Internet: a second 1941 router named ISP, and one Server-PT named PUBLIC-WEB behind it.
4. Cable, and write every connection into a port map as you go — the wiring schematic from Lesson 1, now becoming real. Use Copper Straight-Through for unlike devices (end device to switch, switch to router, router to server) and Copper Cross-Over for the two like-to-like links, marked below. Real gigabit ports negotiate the pinout themselves (Module 3's auto-MDI/MDI-X), but the simulator models the wiring literally — a useful reminder that the model is not the world. If in doubt, the lightning-bolt "Automatically Choose Connection Type" picks for you.
   • Each end device → an access port on its floor's switch.
   • SW1-FLOOR1 Gig0/1 → SW2-FLOOR2 Gig0/1 (the inter-floor joint) — cross-over.
   • SW1-FLOOR1 Gig0/2 → MERIDIAN-RTR Gig0/0 (the trunk to the router).
   • MERIDIAN-RTR Gig0/1 → ISP Gig0/0 (the fiber handoff) — cross-over.
   • ISP Gig0/1 → PUBLIC-WEB.
5. Wait out the amber lights. You have known what they are since Module 3, and you will see them again every time you touch a trunk.

Gate 1. Every cable shows green at both ends, and your port map on paper matches what is on screen, device by device. Save as m9-capstone-stage1.

---

Stage 2 — VLANs and access ports.

6. On each switch — both of them, this is the step people half-do — open the CLI tab and create all five VLANs. A VLAN that exists on one switch and not the other is a VLAN that dies at the trunk.

   codeCopy

   enable
   configure terminal
   hostname SW1-FLOOR1
   vlan 10
    name DESIGN
   vlan 20
    name BUSINESS
   vlan 30
    name SERVERS
   vlan 40
    name GUEST
   vlan 50
    name CAMERAS
   exit
   

7. Assign every access port to the VLAN your design gives it. Use interface range where ports are contiguous:

   codeCopy

   interface range fastEthernet 0/1 - 8
    switchport mode access
    switchport access vlan 10
   interface range fastEthernet 0/9 - 14
    switchport mode access
    switchport access vlan 20
   end
   

   Those ranges are illustrative; use your port map. Repeat for VLANs 30, 40 and 50 on the ports your plan assigns, on both switches.

8. Shut the ports you are not using. An enabled, unassigned port in a wiring closet is an open door, and Lesson 3's security review will ask about it:

   codeCopy

   configure terminal
   interface range fastEthernet 0/20 - 24
    shutdown
   end
   

Gate 2. On both switches, show vlan brief lists all five VLANs by name, with exactly the ports your plan assigns in each. Nothing you intended to use is still sitting in VLAN 1. Save as m9-capstone-stage2.

---

Stage 3 — trunks.

9. Configure the inter-floor joint as a trunk on both ends, and be explicit about which VLANs it carries. Explicit allow-lists are slightly more work and considerably easier to troubleshoot:

   codeCopy

   configure terminal
   interface gigabitEthernet 0/1
    switchport mode trunk
    switchport trunk allowed vlan 10,20,30,40,50
   end
   

10. Configure the link to the router as a trunk on the switch side, with the same allow-list:

    codeCopy

    configure terminal
    interface gigabitEthernet 0/2
     switchport mode trunk
     switchport trunk allowed vlan 10,20,30,40,50
    end
    

Gate 3. On both switches, show interfaces trunk shows the trunk ports in trunking mode, with all five VLANs in the allowed list and in the "VLANs allowed and active" list. If a VLAN appears on one switch's trunk and not the other's, fix it before you go near the router. Save as m9-capstone-stage3.

---

Stage 4 — inter-VLAN routing and the WAN link.

11. The router carries five networks over one physical link, using one subinterface per VLAN. The physical interface must be brought up first — it carries the tagged traffic for all of them:

    codeCopy

    enable
    configure terminal
    hostname MERIDIAN-RTR
    interface gigabitEthernet 0/0
     no shutdown
    interface gigabitEthernet 0/0.10
     description DESIGN
     encapsulation dot1Q 10
     ip address {VLAN 10 gateway} {VLAN 10 mask}
    interface gigabitEthernet 0/0.20
     description BUSINESS
     encapsulation dot1Q 20
     ip address {VLAN 20 gateway} {VLAN 20 mask}
    exit
    

    Repeat the pattern for subinterfaces .30, .40 and .50 with VLAN tags 30, 40 and 50 and their gateway addresses. Two rules make this stage nearly foolproof: keep the subinterface number equal to the VLAN tag (nothing requires it; every technician who ever inherits your router will thank you), and take each address straight from your addressing table rather than from memory.

12. Configure the WAN side. The public addresses here are reserved documentation ranges, so they are safe to use in any teaching build:

    codeCopy

    interface gigabitEthernet 0/1
     description WAN to ISP
     ip address 203.0.113.2 255.255.255.252
     no shutdown
    end
    

13. Configure the ISP router: Gig0/0 as 203.0.113.1 255.255.255.252, Gig0/1 as 198.51.100.1 255.255.255.0, both with no shutdown. Configure PUBLIC-WEB with the static address 198.51.100.10, mask 255.255.255.0, gateway 198.51.100.1. On its Services tab leave HTTP on and switch DNS on, adding at least one A record (say public.example → 198.51.100.10). This server stands in for the public Internet, and stage 6 will hand every guest its address as their resolver — a resolver you never switched on is the commonest self-inflicted fault in this whole build.

14. Temporary test host: pick one PC in the Design segment, open Desktop → IP Configuration, and give it a static address from your Design range with the correct mask and gateway. DHCP arrives in stage 6; right now you need one machine whose configuration you can trust completely.

Gate 4. show ip interface brief on MERIDIAN-RTR shows Gig0/0 up, all five subinterfaces up with your gateway addresses, and Gig0/1 up with 203.0.113.2. show ip route shows five connected networks plus the WAN link. From your test host: ping its own gateway (succeeds), then ping the gateway of a different VLAN (succeeds — that is inter-VLAN routing working, and it is the first genuinely satisfying moment of the build). Save as m9-capstone-stage4.

---

Stage 5 — static devices.

15. Configure the studio server with the static address, mask, gateway and DNS setting your address policy specifies. On its Services tab, turn DNS on and add A records for the names your design uses — at minimum the NAS and the server itself. Leave HTTP on; it gives you something to browse for later tests.
16. Configure the NAS, the printer and the two cameras with their static addresses from your plan. Each one must be outside every DHCP pool you are about to create — the disjointness check from Lesson 1, applied with your fingers rather than your eyes.
17. Record every static address in your documentation as you assign it. Not afterwards. Afterwards never happens.

Gate 5. From the Design test host: ping the server's address (succeeds — traffic crossing from your Design VLAN to your Servers VLAN through the router). Ping the NAS (succeeds). Save as m9-capstone-stage5.

---

Stage 6 — DHCP, and the guest exception.

The brief says the studio's server provides DHCP. That produces a genuine design consequence worth understanding rather than working around: DHCP clients find their server by broadcast, and broadcasts do not cross a router. A client in the Design VLAN therefore cannot reach a server in the Servers VLAN by itself. The standard answer is DHCP relay — the router listens for those broadcasts on each subinterface and forwards them, as unicast, to the server's address, adding the information the server needs to pick the right pool.

And here is the exception that your own policy forces. The guest segment must not reach any internal segment — which includes the server. So the guest segment cannot be served by relay to that server; the router serves it locally instead, with a public resolver for DNS. One requirement, two different implementations, and the reason is policy rather than technology. Write that sentence in your dossier; it is the kind of thing interviewers ask about.

18. On the server's Services → DHCP tab, create one pool per internal VLAN (Design, Business, Servers if your design leases there, and any others your policy includes). For each pool set the default gateway, the DNS server, the starting address and the maximum number of users, all from your address policy. Turn the service On and save each pool.

19. On the router, point each internal subinterface at the server:

    codeCopy

    configure terminal
    interface gigabitEthernet 0/0.10
     ip helper-address {server address}
    interface gigabitEthernet 0/0.20
     ip helper-address {server address}
    exit
    

    Repeat for every internal subinterface that should receive leases. Do not add a helper address to the guest subinterface.

20. Create the guest pool on the router itself, with a public resolver so guests never query an internal server:

    codeCopy

    ip dhcp excluded-address {VLAN 40 gateway} {last excluded guest address}
    ip dhcp pool GUEST
     network {VLAN 40 network} {VLAN 40 mask}
     default-router {VLAN 40 gateway}
     dns-server 198.51.100.10
     lease 0 4
    exit
    

    The lease length is a policy decision from your design — guests turn over constantly, staff do not.

21. Switch your Design test host back to DHCP, and set every other wired client to DHCP as well.

Gate 6. On a client in each segment, ipconfig /all shows an address inside that segment's pool, the correct mask, the correct gateway, and the DNS server your policy specifies. No client shows a 169.254.x.x address. From a client with a leased address, ping {server address} succeeds and nslookup {a name you created} returns the right address. Save as m9-capstone-stage6.

---

Stage 7 — wireless.

22. Place four Access Point-PT devices: a staff AP and a guest AP for each floor (the modelling substitution explained above). Cable each one's Ethernet port to an access port on its floor's switch — the staff APs into your staff-facing VLAN, the guest APs into VLAN 40.
23. On each access point's Config → Port 1 tab, set the SSID (one name for staff, a different one for guests — and neither should reveal the hardware model, per Module 6), choose WPA2-PSK with AES encryption, and set a long passphrase. Staff and guest passphrases are different secrets; if they are the same, the guest network is not a guest network.
24. Enable client isolation on the guest access points if your simulator version offers it, and record the requirement in your dossier regardless — on real hardware it is a checkbox, and it is the difference between guests who cannot reach your network and guests who cannot reach each other either.
25. Add wireless clients: a Tablet-PT or Smartphone-PT as a visiting client's device (these have wireless built in), and one Laptop-PT for staff — remembering that a laptop needs its Ethernet module swapped for a wireless one on the Physical tab before it can join. Represent each meeting room's wireless display with a tablet in whichever segment your design assigned it; the simulator has no wireless-display object, and what matters is that it is a wireless client in the right VLAN.
26. Join each client to the appropriate SSID with its passphrase, and set it to DHCP.

Gate 7. The staff wireless client holds an address from the staff segment's pool; the guest client holds an address from the guest pool with the public DNS resolver. Both associate without warnings. Save as m9-capstone-stage7.

---

Stage 8 — the single public address.

The studio has one public IP. Everything internal that reaches the Internet does so by port address translation, and one segment must be deliberately left out.

27. Give the router its way out — one default route pointing at the ISP:

    codeCopy

    configure terminal
    ip route 0.0.0.0 0.0.0.0 203.0.113.1
    

28. Define which internal ranges may be translated. This access list is the only place where the camera exclusion lives at translation level, so read it twice before you type it:

    codeCopy

    ip access-list standard NAT-ALLOWED
     permit {VLAN 10 network} {VLAN 10 wildcard}
     permit {VLAN 20 network} {VLAN 20 wildcard}
     permit {VLAN 30 network} {VLAN 30 wildcard}
     permit {VLAN 40 network} {VLAN 40 wildcard}
    exit
    

    Four permits, and the camera range appears nowhere. The wildcard mask is the subnet mask inverted — a /24 becomes 0.0.0.255, a /26 becomes 0.0.0.63, a /23 becomes 0.0.1.255. Compute each one from your own plan.

29. Mark the interfaces and enable overload translation to the WAN interface's single address:

    codeCopy

    interface gigabitEthernet 0/0.10
     ip nat inside
    interface gigabitEthernet 0/0.20
     ip nat inside
    interface gigabitEthernet 0/0.30
     ip nat inside
    interface gigabitEthernet 0/0.40
     ip nat inside
    interface gigabitEthernet 0/0.50
     ip nat inside
    interface gigabitEthernet 0/1
     ip nat outside
    exit
    ip nat inside source list NAT-ALLOWED interface gigabitEthernet 0/1 overload
    end
    

    Mark the camera subinterface ip nat inside too. It costs nothing, and it makes the exclusion visible in one place — the access list — rather than scattered across interface configuration where a future engineer will miss it.

Gate 8. From a Design client, ping 198.51.100.10 succeeds, and browsing http://198.51.100.10 loads the simulator's page. On the router, show ip nat translations lists entries whose inside global address is 203.0.113.2 with varying port numbers — many private conversations wearing one public identity, exactly as Module 4 promised. From a camera host, ping 198.51.100.10 fails. Save as m9-capstone-stage8.

---

Stage 9 — policy.

Translation is not policy. A camera that cannot be translated still has a route toward the Internet and can still reach anything internal; a guest still reaches every internal segment because the router is doing its job. Policy is written explicitly, and it is written at the edge of each segment.

30. Guest isolation — deny the whole internal block first, then permit everything else, applied inbound on the guest subinterface so guest traffic is judged the moment it arrives:

    codeCopy

    configure terminal
    ip access-list extended GUEST-POLICY
     permit udp host 0.0.0.0 host 255.255.255.255 eq bootps
     permit udp {VLAN 40 network} {VLAN 40 wildcard} host {VLAN 40 gateway} eq bootps
     deny   ip {VLAN 40 network} {VLAN 40 wildcard} {studio block} {studio block wildcard}
     permit ip {VLAN 40 network} {VLAN 40 wildcard} any
    exit
    interface gigabitEthernet 0/0.40
     ip access-group GUEST-POLICY in
    exit
    

    Order is everything: the deny must come first. An access list is read top to bottom and stops at the first match, so a permit above a deny makes the deny decorative. Note also what the first line covers — the entire studio block, which includes the guest segment's own gateway. Guests losing the ability to ping their gateway is a feature, not a bug, and it is why stage 6 gave them a public resolver instead of an internal one.

    Now the two lines above the deny, which are the classic access-list trap. An inbound list is judged the moment the packet arrives — before the router's own DHCP server ever sees it. A guest's DHCP DISCOVER is sourced from 0.0.0.0 to 255.255.255.255, so it matches neither your deny (whose source is the guest network) nor your guest-sourced permit, and it dies on the implicit deny at the end of every access list. A renewal is worse: it is unicast to the gateway, which sits inside the studio block your deny covers. Without those two permits, no guest ever gets an address and Gate 7 cannot pass. An address service running on the same router still has to be let through the door.

31. Camera egress — permit only the narrow flows your reachability table names, then deny the rest:

    codeCopy

    ip access-list extended CAMERA-POLICY
     permit ip {VLAN 50 network} {VLAN 50 wildcard} host {recording target address}
     deny ip {VLAN 50 network} {VLAN 50 wildcard} any
    exit
    interface gigabitEthernet 0/0.50
     ip access-group CAMERA-POLICY in
    end
    

    If your design records footage to a device on the Servers segment, that device is the permitted host. If your design has the cameras record locally, the permit line disappears and only the deny remains. Either way, the rule — not the translation list — is the control.

32. copy running-config startup-config on the router and on both switches. Then save the file as m9-capstone-build.

Gate 9. The full ping matrix below matches your reachability table in every cell. That is the last gate, and it is the one that certifies the build.

---

The verification checklist

Three artifacts finish a build. Produce all three; they go straight into Lesson 3's dossier.

Artifact 1 — the ping matrix. Test from a live host in each segment to a live host in each other segment, plus the public server. Record PASS or FAIL in every cell, then compare against your reachability table.

The bold cells are dictated by the brief and are not negotiable: guest reaches nothing internal but does reach the Internet; cameras never reach the Internet; design and business staff reach the server they depend on and the Internet they work with. Every "your policy" cell must match what your Lesson 1 reachability table said — and a mismatch is a finding either way. If the build disagrees with the document, one of them is wrong, and deciding which is a design decision, not a typing correction.

A note on method: a failed ping is weak evidence on its own, because pings fail for many reasons. Strengthen it. Before recording a required FAIL, confirm from the same host that something else succeeds — a guest client that cannot reach the server but loads the public web page has proved isolation; a guest client that cannot reach anything has merely proved it is broken. Positive controls are what turn a timeout into evidence.

Artifact 2 — the DHCP lease record. On the server's DHCP service, list the pools and the addresses issued. On the router, show ip dhcp binding lists the guest leases. For each segment record: the pool range, the number of leases issued, the gateway and DNS values delivered, and the lease duration. Then run three checks — every leased address falls inside its pool; no leased address collides with any static address from stage 5; and every client's DNS setting matches the policy for its segment (internal resolver for staff, public resolver for guests).

Artifact 3 — the NAT translation table. With traffic flowing, run show ip nat translations and show ip nat statistics on the router and capture both. The translation table should show many inside local addresses mapped to the single inside global address 203.0.113.2, distinguished by port — the whole studio behind one public identity. Then read it for what is absent: no entry anywhere may carry an inside local address from the camera range. An absence is evidence too, provided you can show you looked; state in your dossier which command you ran and what you searched for.

Common build failures and how to read them

Six failures account for most of the trouble in a build this shape. Each has a signature, a confirming command and a fix — this table is deliberately in the same form as Module 8's differential-diagnosis tables, because it is the same skill applied to your own work.

Two general habits shorten every one of these hunts. First, show access-lists prints a match counter beside each line: a rule with zero matches is either never being hit or never being reached, and that number distinguishes "my rule is wrong" from "my traffic never got here." Second, when a fix does not take effect, force the client to re-ask — toggling an interface to static and back to DHCP is the simulator's version of Module 8's renew, and stale leases have wasted more student hours than any command in this lesson.

Expected result. A nine-stage build in which every gate passed, a saved file per stage, the studio's five segments routed and served, one public address carrying the whole office, and three verification artifacts whose contents match the design document you wrote in Lesson 1.

Verify. You can point at evidence on screen for each of these: which command proves the trunk carries all five VLANs; which output proves a client received its address from the intended pool; which table proves the whole studio shares one public address; which two outputs together prove guest isolation (a required FAIL plus a positive control); and which absence proves the cameras are excluded from translation.

Questions.

1. During stage 3 you set switchport trunk allowed vlan 10,20,30,40,50 on both ends. A colleague says the allow-list is unnecessary because trunks carry all VLANs by default. Give the operational argument for typing it anyway, and one scenario where the default would hurt.
2. In stage 6 the internal VLANs use DHCP relay to the server while guests are served by the router. State the requirement that forces the split, and predict exactly what would break if you added ip helper-address to the guest subinterface and left the stage 9 access list in place.
3. show ip nat statistics shows hits climbing but a Business client still cannot load the public page, while a Design client can. Name the two most likely causes and the command that distinguishes them.
4. Your camera host cannot reach the Internet — before you have configured anything in stage 9. Explain the mechanism, and explain why you would still write the stage 9 rule.
5. A guest tablet cannot reach the server (as required) but also cannot reach the public web page. Which of the required matrix cells is now unproven, and what is the first thing you check?
6. You finish stage 8, discover a VLAN was never created on the second switch, and fix it. Which earlier gate should have caught this, and what does that tell you about the cost of skipping gates?

(Answers: 1 — an explicit allow-list documents intent in the configuration itself, so the next engineer reads what should cross the joint rather than inferring it, and it prevents a newly created VLAN from silently spanning both floors before anyone has decided it should; the default hurts the day someone adds a VLAN for an untrusted device and it propagates across the building unasked. 2 — the guest segment must not reach any internal segment, and the server is internal. Two failures stack, and the order matters. First, the relay would never even start: an inbound access list is evaluated the instant the packet arrives, before the relay agent sees it, and a DHCP DISCOVER (source 0.0.0.0, destination 255.255.255.255) matches neither the deny nor the guest-sourced permit — so it dies on the implicit deny and every guest self-assigns a 169.254 address. Permit DHCP explicitly and you reach the second failure: guests holding an internal resolver address they are forbidden to query, so they obtain addresses and still fail every name lookup. Two different broken states, both from policy and service design disagreeing. 3 — either the Business network is missing from the NAT-ALLOWED list, or its wildcard mask is wrong so the permit does not actually match its addresses; show access-lists NAT-ALLOWED distinguishes them, because a missing entry shows no line at all while a wrong wildcard shows a line with a zero counter. 4 — with no permit in NAT-ALLOWED, camera packets leave untranslated with a private source address that the ISP will not route a reply to, so the conversation cannot complete; you still write the rule because that behavior is a side effect of translation rather than a control — it disappears the day someone edits the list, adds a second public address, or turns on IPv6. 5 — the required PASS for guest-to-Internet is unproven, and without it the four required FAILs have no positive control, so the whole guest row is evidence-free; check first that the guest client actually holds a lease with the public resolver and a valid gateway, since a client with no address fails everything. 6 — Gate 2, which requires show vlan brief to match the plan on both switches; the cost of skipping a gate is that the symptom surfaces several stages later, where the list of possible causes is five times longer.)

If it goes wrong.

• You lost track of which stage is good. Reopen the last saved stage file and re-run its gate. That is what the saved files are for, and re-running a gate takes a minute against the twenty you would spend guessing.
• A command is rejected as invalid input. Almost always the prompt level: end returns you to the top, configure terminal goes back down, and show commands live at the top prompt. Watch the prompt change as you move.
• Everything worked, then you saved and reopened, and it did not. You configured but never wrote: copy running-config startup-config on every device whose configuration you care about.
• A client stubbornly holds an old address after you fixed a pool. Toggle it to static and back to DHCP. The simulator does not always re-request on its own schedule, and a stale lease imitates a broken configuration convincingly.
• The build has become tangled beyond diagnosis. Reopen m9-capstone-stage4 — the last stage before services — and rebuild forward. Rebuilding two stages with your gates is faster than debugging nine without them, and the second pass takes a third of the time.

Reset/cleanup. Nothing outside the simulator was touched. Keep every stage file and m9-capstone-build; Lesson 3 opens that last one, inspects it, breaks it, and asks you to prove you can find what broke.

Check yourself

1. A frame leaves a design workstation on floor 2 and arrives at the NAS on floor 1. Name every device it passes through and every point at which an 802.1Q tag is added or removed. Say whether the router is involved, and why your answer depends on your own design.
2. Your inter-floor trunk fails at 10 a.m. Using your build, list which of the five segments still function normally, which lose access to what, and which single output you would capture first for the incident record.
3. Explain in two sentences why ip nat inside source list NAT-ALLOWED interface gigabitEthernet0/1 overload lets 40 devices share one address, and name the field in the translation table that makes it possible.
4. Two access lists in this build both contain a deny. Explain the different jobs GUEST-POLICY and NAT-ALLOWED perform, and why removing either one alone would leave a real requirement unenforced.
5. A colleague suggests moving the guest DHCP pool onto the studio server "so all address management is in one place." Evaluate the suggestion against the reachability table, and give the one change that would make it work — plus the reason you would still refuse.
6. Your ping matrix shows a required PASS from Business to Servers, but users report the shared drive is unreachable. Explain how both statements can be true at once, and name the layer and the tool you would reach for next.

Answers

1. Workstation → floor 2 switch (the access port strips nothing on the way in; the switch adds a VLAN 10 tag when the frame leaves via the trunk) → inter-floor trunk → floor 1 switch. If the NAS sits in the Servers VLAN, the floor 1 switch tags the frame up the trunk to the router, the router's .10 subinterface receives it, routes it to the .30 subinterface, and sends it back down tagged for VLAN 30 — so it crosses the trunk twice and the router is very much involved. If your design placed the NAS in the Design VLAN on floor 1, the floor 1 switch strips the tag and delivers it on an access port, and the router never sees it. Same question, two answers, decided by a design choice you made in Lesson 1 — which is precisely why that choice deserved a paragraph.
2. Everything on the router's own floor keeps working, including inter-VLAN routing and Internet access, because the router hangs off that switch. The other floor loses everything beyond its own switch: no inter-VLAN routing, no server, no DHCP renewal, no Internet — its VLANs still function internally, so users there can reach same-VLAN neighbors on the same floor and nothing else. Capture show interfaces trunk (or the interface status) on both switches first: it establishes whether the link is down or merely no longer trunking, which are different incidents with different fixes.
3. Every outbound conversation is rewritten to leave with the single public source address, and the router records the original address and port beside the substituted port it assigned, so replies arriving for that port can be mapped back to exactly one inside host. The field that makes it work is the port number — the translation table's inside local and inside global entries differ in port, which is why the technique is called port address translation.
4. NAT-ALLOWED decides which internal ranges get a public identity; GUEST-POLICY decides which internal destinations a guest may send packets to. They enforce different requirements: removing GUEST-POLICY would leave guests fully routed to every internal segment (translation has no opinion about internal-to-internal traffic), and removing the camera's absence from NAT-ALLOWED would give cameras a working path outward if the policy list were ever mis-applied. Defence in depth, Module 7's phrase, expressed in two lists.
5. The reachability table forbids guest-to-internal traffic, and a DHCP server on the Servers segment is internal, so the guest segment cannot be served by it under the stated policy. The change that would technically make it work is DHCP relay, because the relayed packets are sourced by the router rather than by the guest and therefore never match the guest deny rule. You would still refuse: relay works, but it hands guests an internal resolver address they are forbidden to reach, and it creates a dependency from an untrusted segment onto the studio's most critical server — a good reason to keep the guest segment's services entirely separate.
6. Ping proves layer 3 reachability, and nothing more. The shared drive is an application service on a port, so it can fail for reasons ping cannot see — the service not running, the file share not published, credentials rejected, or a rule filtering that port specifically. Next step is layer 4 and above: test the port itself (Test-NetConnection on Windows, nc -zv on Linux, from Module 8's toolkit), and if the port answers, the problem is the application, not your network.

Key terms

• Gate — a verification step at the end of a build stage that must pass before the next stage begins; also the rollback point.
• Access port / trunk port — a port carrying one untagged VLAN toward a device, versus a port carrying many tagged VLANs toward another switch or router.
• Allowed VLAN list — the explicit set of VLANs a trunk carries; documents intent and prevents accidental propagation.
• Subinterface — a logical division of one router interface, each with its own 802.1Q tag and address, giving one physical link a presence in many VLANs.
• encapsulation dot1Q — the subinterface command that binds it to a VLAN tag; the number must match the VLAN.
• Router-on-a-stick — inter-VLAN routing performed on subinterfaces over a single trunk.
• DHCP relay (ip helper-address) — the router forwarding a client's DHCP broadcast as a unicast to a server on another segment.
• Pool / exclusion / reservation — the range a server may issue from, the addresses it must never issue, and the addresses tied permanently to one device.
• PAT / overload — many inside addresses sharing one public address, distinguished by translated port number.
• Inside / outside interface marking — telling the router which side of the translation boundary each interface is on.
• Wildcard mask — the inverted subnet mask used by access lists to describe a range.
• Match counter — the per-line hit count in show access-lists; distinguishes a wrong rule from an unreached one.
• Positive control — a test that must succeed, run alongside a test that must fail, so a failure proves policy rather than breakage.
• Ping matrix — the segment-by-segment table of expected and observed reachability; the build's primary evidence.

Summary

• Build in stages and verify at every gate; a build tested only at the end is a build debugged at the end, with five times the suspects.
• VLANs must exist on every switch that carries them, and trunks must be trunks on both ends with matching allow-lists — the two most common reasons a segment works on one floor only.
• One router interface serves five networks through subinterfaces, each with its encapsulation dot1Q tag and its gateway address taken from the design table, never from memory.
• DHCP broadcasts do not cross routers, so internal segments reach a central server by relay — and the guest segment cannot, because policy forbids it from reaching that server at all; it is served locally with a public resolver instead.
• One public address carries the whole studio through port address translation, and one segment is excluded by simply never appearing in the translation list.
• Translation is not policy: guest isolation and camera egress denial are explicit access lists, deny before permit, applied inbound at the segment's own subinterface.
• Three artifacts finish the build — the ping matrix with positive controls, the DHCP lease record checked against static addresses, and the translation table read for what is present and what is absent.
• The simulator differs from reality in three named ways (one SSID per access point, no WPA3, no PoE accounting); build to the simulator and document the real requirement.

Next lesson

The network runs. Now it has to survive contact with reality: Lesson 3 puts you at the capture point to see what your own build actually sends, hands you helpdesk tickets from Meridian's staff describing faults you did not create, runs a security review over your own work, and closes the course with the professional dossier that makes all of it defensible to somebody who was not there.

Sources and further study

• Al-Doori, T., Network Essentials, Chapters 4, 5, 6, 7 and 8 — components, the TCP/IP suite, addressing and routing, Ethernet standards and wireless; the build half of the capstone is these chapters executed simultaneously.
• IEEE 802.1Q, "Bridges and Bridged Networks" — https://1.ieee802.org/tsn/802-1q/ — the tagging standard behind every trunk and subinterface in this build.
• RFC 2131, "Dynamic Host Configuration Protocol" — https://www.rfc-editor.org/rfc/rfc2131 — the lease exchange your relay carries, and the reason relay is needed at all.
• RFC 3022, "Traditional IP Network Address Translator" — https://www.rfc-editor.org/rfc/rfc3022 — the translation mechanics behind the table you captured.
• RFC 5737, "IPv4 Address Blocks Reserved for Documentation" — https://www.rfc-editor.org/rfc/rfc5737 — why 203.0.113.0/24 and 198.51.100.0/24 are the correct addresses for a teaching Internet.
• Download: Capstone Verification Checklist (the ping matrix, lease record and translation-table checks in tickable form, with space for evidence references).