Building a network lab you can break

Why this matters

N10-009 examines no lab-building task, and this lesson covers no objective. It is here because every hands-on lab in this course has to run somewhere, and because reading about networks produces a specific kind of false confidence: you can follow every word about broadcast domains and still not predict what happens when you put two hosts on the wrong subnet.

CompTIA's own courseware ships a virtual lab environment. A free course has to tell you how to make one.

The lesson

What you can practise without any hardware

More than people expect. On one laptop you can build multiple subnets, run a router between them, break routing deliberately and watch what fails, run DHCP and DNS servers, capture and read real packets, and practise almost every command-line tool in domain 5.

What you cannot do in software is anything physical: terminate a cable, use a tone generator, measure attenuation, diagnose crosstalk, or feel how far 100 metres is. That gap is real and domain 5 examines it, so this lesson ends with the small amount of hardware worth owning.

Virtual machines versus containers

Both isolate workloads; only one is useful for networking practice at this level.

A virtual machine emulates a whole computer, including virtual network interfaces that behave like real ones. It has its own IP stack, its own routing table, and it can be given several NICs on different networks. That is what you want.

A container shares the host kernel. Container networking is real and worth learning eventually, but it is abstracted — you are usually configuring a network namespace and a bridge the runtime created for you, and the layer-2 behaviour you are trying to observe is hidden. For Network+, use VMs.

Choosing a hypervisor

A type 1 hypervisor runs directly on hardware (ESXi, Proxmox, Hyper-V on Server). A type 2 runs as an application on your existing OS (VirtualBox, VMware Workstation Player, UTM on Apple silicon). For a study lab, type 2 is correct: you want it on the machine you already use, and you want to close it.

VirtualBox is free on Windows, Linux and Intel Macs. On Apple silicon, UTM is the practical choice. Hyper-V is already in Windows Pro and is fine if you have it. The specific product matters far less than understanding the networking modes it offers, which are broadly the same everywhere.

Host-only and bridged networking — the setting that matters most

Every type 2 hypervisor offers roughly three modes, and choosing the wrong one is the single most common reason a lab "doesn't work".

Bridged. The VM's virtual NIC is attached to your real network. The VM gets an address from your home router's DHCP, appears as another device on your LAN, and can be reached by other machines. Use this when you want the VM to behave like a real host on a real network.

NAT. The hypervisor gives the VM a private address and translates its traffic behind the host's address. The VM reaches the internet; nothing on your LAN can reach the VM unaided. This is the safe default and usually what you get if you change nothing.

Host-only. A private network between the host and the VMs, with no route to anywhere else. Nothing leaks in or out. This is the mode to build labs in, because you can put the network into any broken state you like without affecting your household's internet or exposing an unpatched VM.

The practical arrangement is two virtual NICs per lab VM: one NAT adapter so it can install packages, and one host-only adapter carrying the lab traffic you actually care about.

Building a two-subnet lab

The smallest lab that teaches something real. You need three VMs:

• Host A on host-only network 1, address 192.168.10.10/24.
• Host B on host-only network 2, address 192.168.20.10/24.
• Router, with a NIC on each: 192.168.10.1/24 and 192.168.20.1/24.

Give A and B their router as a default gateway, then enable forwarding on the router (on Linux, sysctl -w net.ipv4.ip_forward=1).

Now you have something you can interrogate. Ping across and it works. Remove the default gateway from Host A and it stops — and ping 192.168.10.1 still works, which tells you the failure is routing, not the link. Turn forwarding off and pings stop while both directly-connected pings still succeed. Each of those is a domain 5 symptom you have now produced on purpose.

Adding a router VM

Any Linux VM with two NICs and forwarding enabled is a router, and that is the most instructive option because nothing is hidden. If you want something that behaves like commercial kit, VyOS and OPNsense are free, have real CLIs and configuration models, and will let you practise static routes, NAT rules, DHCP scopes and firewall policy against something that pushes back.

Packet capture inside the lab

The part that converts theory into sight. Install Wireshark on a lab host, or run tcpdump on the router, and watch what your own traffic actually looks like: the ARP request before the first ping, the three-way handshake, the DNS query that precedes the web request, the TTL decrementing by one as a packet crosses the router.

Capture on a host-only network rather than your home LAN. It is quieter, so what you are looking for is not buried, and you are not capturing other people's traffic.

Emulators and simulators, and what they cannot show you

A simulator (Cisco Packet Tracer is the well-known one) imitates device behaviour with a model. It is excellent for topology and configuration practice, costs nothing in resources, and will happily accept a configuration that would not work on real hardware, because the model only implements what it was written to implement.

An emulator (GNS3, EVE-NG, Containerlab) runs real network operating system images. Behaviour is genuine, including the bugs — but you need the images, which often means licensing, and the resource cost is real.

The rule: simulators for learning topology and command syntax, emulators or VMs for anything where you need to trust the result.

Cheap second-hand hardware worth owning

A short list, because domain 5 has physical-layer questions that software will never teach you:

• A cable tester — the cheapest kind that shows pin-by-pin continuity.
• A handful of patch cables, including one you have deliberately made badly.
• A crimper, a bag of RJ45 plugs and a few metres of cable, so you have actually terminated one and know why the pair twists matter.
• An old managed switch with a web interface. Second-hand small business switches are inexpensive and will let you configure real VLANs, see a MAC address table, and mirror a port.

Resetting to a known state

The habit that makes a lab useful rather than exhausting: snapshot every VM once it is built and working, before you break anything. Every hypervisor supports this. The value of a lab is that you can put it into a failed state on purpose, and that is only true if returning to a working state takes seconds.

Break it, diagnose it, then roll back.