Making Home Lab. Part 1

Key Takeaways

You don’t need a rack full of gear to start. A single used Cisco switch, a small server running EVE-NG, and some clever cabling will get you further than most people think.
Virtualisation is the force multiplier. EVE-NG or GNS3 on a modest server runs more devices than you could physically fit in a 42U rack — and uses a fraction of the power.
Start with what you’re studying. CCNP Security? ISE VM + a couple of switches + AnyConnect. CCIE? Bigger topology, more virtual routers. Don’t build a lab and then find a cert to match it.

Why build a home lab?

If you’re a network engineer studying for a certification, you already know the answer: you can’t learn networking by reading about it. You need to break things. You need OSPF neighbour flapping at 2am because you fat-fingered a timer. You need to watch a spanning-tree topology change propagate while you hold your breath. That doesn’t happen in a simulator and it definitely doesn’t happen in a video course.

A home lab gives you:

Real hardware, real behaviour. Virtualised IOS/XE/Junos images are 99% identical to physical, but the 1% that isn’t — timing, buffering, hardware forwarding — is sometimes the 1% that matters.
Freedom to break everything. No change window, no CAB approval, no “please don’t reboot the core.” Just you and a console cable.
A test environment that’s always available. Want to lab up a BGP scenario at 11pm on a Saturday? Your lab is right there. No booking, no shared resources, no waiting.

The gear: start small, add as you need

EVE-NG (Emulated Virtual Environment, Next Generation) is the piece that makes a small lab behave like a large one. It is a browser-driven network emulator that runs real vendor images as virtual machines on one host and wires them together on virtual links, so a topology you could not physically cable becomes a drag-and-drop exercise. GNS3 is the main alternative and does the same job. Both are emulators rather than simulators, which matters: they boot the actual operating system image, so the CLI, the bugs and the timers are the real ones.

Here is what I built mine around, and what I would recommend:

The core: a virtualisation server

This is the most important piece. An old desktop or a refurbished 1U server running ESXi or Proxmox. EVE-NG runs beautifully as a VM on either. Look for:

32GB RAM minimum (IOSv images are ~512MB each, ISE needs 16GB+ alone)
An SSD — spinning rust makes lab boot times painful
Intel NICs if you can — fewer driver headaches than Realtek
Something quiet if it’s in your house. A Dell R630 at full tilt in the spare room will not make you popular

Physical switching

One managed L3 switch is enough to start. A used Cisco 3750X or 3850 runs you $100-200 on eBay. It gives you real VLANs, real STP, real QoS behaviour. Juniper EX series if you’re a Junos shop. Don’t buy 10 switches — one good one will tell you everything you need to know about switching at this scale.

Routing

Virtualised, mostly. CSR1000v images in EVE-NG cover 99% of what you’d encounter on physical ISRs. If you want physical routers, a couple of 1921s or 2911s are cheap and run IOS 15.x — fine for lab work.

Cabling and power

Don’t overlook this. A couple of console cables (USB-to-RJ45), a small 8-port power strip, and enough patch leads to go between your switch and server. A USB hub for console connections to multiple devices saves you constantly swapping cables.

What to virtualise vs what to buy physical

Device	Virtualise	Physical	Why
Router (IOS/IOS-XE)	✅ CSR1000v	Optional	Virtual images are 99% feature-complete
Switch (L2/L3)	Partial (IOSvL2)	✅ Get one	Virtual switches have limitations. Real hardware shows you TCAM exhaustion, buffer behaviour and stacking
Firewall (ASA/FTD)	✅ ASAv	Skip	ASAv is fully functional for lab purposes
ISE	✅ ISE VM	Skip	ISE VM is the same code as the physical appliance
Wireless Controller	✅ vWLC	Skip (unless you need APs)	vWLC handles most config scenarios

One term in that table is worth expanding, because it is the usual reason a virtual switch stops being a useful stand-in. TCAM (ternary content-addressable memory) is the special-purpose memory a hardware switch uses to match packets against ACLs, QoS policies and forwarding entries at line rate. It is finite, it is partitioned per feature, and when you exhaust it the switch quietly stops programming entries into hardware and starts punting traffic to the CPU instead. A virtual switch has no TCAM, so it will happily accept a configuration that a real one cannot execute. That failure mode is invisible until you meet it on production hardware.

The software stack

Hypervisor: ESXi (free license) or Proxmox. Both work. ESXi is more common in enterprise; Proxmox has a better web UI and no license shenanigans.
Emulation: EVE-NG Community Edition. GNS3 is the alternative — both do the same thing. EVE-NG’s web UI wins for me.
Images: You will need to source these yourself, and the licensing question is the one people get wrong. Cisco Modeling Labs (CML) is Cisco’s own emulation platform, and buying it is the clean way to get legal access to current IOSv, IOSvL2, IOS-XE, ASAv and NX-OSv images. The Personal tier is $199 per year for 20 nodes, Personal Plus is $349 for 40, and Cisco now also lists a Free tier alongside them (Cisco DevNet, Cisco Modeling Labs). If you only want to try it, the DevNet Sandbox hands out free four-hour sessions on a pre-loaded server. Worth it for the licensing peace of mind alone.

Power consumption reality check

A small home lab with one server, one switch and a small NAS draws roughly 150 to 250 W continuously. Australian residential electricity runs somewhere around 30 to 35 cents per kWh depending on your state and retailer, so that is about $35 to $60 a month, every month, whether you are labbing or not. Check your own number rather than mine: the Australian Energy Regulator publishes the Default Market Offer reference prices each year, and they are the benchmark your retailer’s offer is measured against. Factor it in before you buy a rack full of gear you will run twice and then leave powered off.

What’s next

This is Part 1 — the hardware and platform setup. Future posts will cover:

EVE-NG topology design for CCNP Security labs
ISE deployment in a home lab (including the gotchas with licensing and VM specs)
Connecting your virtual lab to your physical switch (bridge domains, trunking, the works)