The Best Home Lab Setup for CCNA (Hardware, RAM & Options)

Why RAM Is the Gatekeeper (CPU and Disk Come Second)

Every node in a CML topology is its own virtual machine with its own memory footprint, so your lab's ceiling is set by how much RAM you can free up after the host operating system takes its share. Lighter node types — like IOL (IOS on Linux) images — run in a few hundred megabytes each, which is why a small lab fits on modest hardware. Heavier images such as Catalyst 8000v, NX-OS, or IOS XR can want several gigabytes per node, which is how a topology that looks small on the diagram quietly eats all your memory.

As a planning target, a 5-node CML Free lab wants roughly 8–16 GB of free RAM once the operating system and the CML appliance itself are accounted for; larger multi-node topologies push you toward 32 GB or more. CML's free tier caps you at a small number of nodes on purpose — check Cisco's current CML page for the exact limit, since it has changed over releases. If you're buying or upgrading a machine, budget RAM first and be generous: it is the one spec you will actually run out of.

CPU matters in a specific way: you need a processor with hardware virtualization (Intel VT-x or AMD-V), and you need nested virtualization to work. The reason is that CML is itself a VM, and inside it each router or switch is virtualized again with KVM — a virtual machine running virtual machines. Without nested virtualization exposed to the CML appliance, the nodes won't boot or will crawl. A handful of modern cores is plenty; clock speed and core count affect how fast nodes boot and converge, not whether the lab works.

An SSD is the cheap win. Node images load from disk every time you start a lab, so a solid-state drive turns multi-minute boots into something tolerable and makes snapshots and redeploys far less painful. It is a comfort upgrade, not a gate the way RAM is — a slow disk makes you wait; too little RAM stops the lab from running at all.

Know What You're Actually Running Before You Buy Anything

A lot of hardware confusion disappears once you're clear on what CML is. It is a virtual appliance — you download an OVA or ISO and run it inside a hypervisor. It is not a desktop application you double-click, and it is not the same thing as Packet Tracer. This distinction is the whole reason the three paths below exist: in every case, the real question is just where you put the hypervisor that hosts CML.

For running CML on your own machine, the supported type-2 hypervisor is VMware — Workstation Pro on Windows/Linux or Fusion on Mac — and both are now free for personal use, which removes the old cost objection. VirtualBox is a fine general-purpose hypervisor for other tools, but it is not a supported CML host, so don't plan your CML lab around it. If you'd rather run CML as a bare-metal-style appliance on dedicated hardware, that's the Proxmox path further down.

Packet Tracer deserves its own note because beginners reach for it first. It is a simulator, not real IOS — it models device behavior rather than running the actual operating system. That's genuinely useful for your first weeks of CCNA fundamentals, but it diverges from real gear on anything nuanced, and it won't behave like the equipment on the exam or in a job. CML runs real Cisco software images, which is why graded, exam-realistic practice is built on CML rather than a simulator.

Our full CML install walkthrough covers the appliance download, the VMware setup, and licensing step by step; the sections below are about choosing the machine you point it at.

Path 1: Use the Laptop or Desktop You Already Own

The cheapest lab is the one you already paid for. If you have a reasonably current Windows or Linux machine with an Intel or AMD CPU, install VMware Workstation Pro, import the CML appliance, and you can run small labs today. This is the right starting point for most CCNA study — the topologies you build early on are a few routers and switches, well within what a laptop with 16 GB of RAM can handle.

The tradeoff is headroom and availability. After Windows and your browser take their cut, a 16 GB laptop leaves you enough for a small CML Free lab but not much slack, and the machine has to stay on and awake while the lab runs. That's fine for evening study sessions; it gets frustrating if you want a topology that stays up for days or one that outgrows five nodes. Closing the lid, sleeping the machine, or needing the RAM for other work all interrupt you.

Practical guidance: 16 GB is a workable floor, 32 GB is comfortable, and an SSD is close to mandatory for sane boot times. When you find yourself constantly shutting nodes down to free memory, or wanting the lab reachable when the laptop is closed, that's the signal to move to Path 2 or Path 3 — not a reason to fight your laptop.

Path 2: A Dedicated Mini-PC or Old Server with Proxmox

When the laptop starts fighting back, the standard next step is a dedicated always-on box running Proxmox VE, a free type-1 hypervisor you install on bare metal. You run CML as a VM on top of it, and because nothing else is competing for the machine, you can commit far more RAM to the lab and leave large topologies running around the clock. This is the setup most serious CCNP-track learners end up with.

There are two common builds. A small mini-PC — an Intel NUC-class machine or similar — is quiet, sips power, and can often be maxed to 32 or 64 GB of RAM, which covers big CCNA and most CCNP labs. Alternatively, a used enterprise server (a previous-generation Dell or HP tower/rack unit) gets you a lot of ECC RAM and many cores cheaply, at the cost of noise, heat, and power draw. Either way, confirm the CPU supports hardware virtualization and enable nested virtualization in Proxmox so CML's nodes can boot — that's the one setting people forget.

The payoff is that your lab stops being something you start and stop and becomes infrastructure that's just there: reachable from any device on your network, sized for topologies a laptop can't hold, and free to run long convergence or automation scenarios overnight. Our Proxmox guide covers the install, enabling nested virtualization, and importing the CML appliance so the nodes come up correctly.

Path 3: The Cloud, Cisco DevNet Sandbox, and the Apple-Silicon Catch

If you don't have — or don't want to buy — capable local hardware, run the lab somewhere else. You can stand CML up on a cloud VM, but not just any instance: because CML needs nested virtualization, you generally need a bare-metal or nested-virt-capable instance type, so check CML's documentation for what's currently supported before you spin one up. The upside is you pay only while it runs and can shut it down between sessions; the discipline is remembering to turn it off.

For zero hardware and zero cost, Cisco's DevNet Sandbox is the cleanest option — Cisco hosts reservable, and sometimes always-on, environments including CML, and you just connect a browser. It's ideal for confirming a concept or getting reps without owning a lab. Availability and the exact sandbox catalog change, so treat DevNet as a moving target and see what's currently offered rather than assuming a specific sandbox will always be there.

The one caveat that forces this decision for some readers is Apple Silicon. Macs with M-series chips are ARM-based, while the classic Cisco lab images are x86. An ARM Mac can only run those images through x86 emulation, which is far too slow to be usable — and running VMware Fusion on Apple Silicon doesn't fix it, because Fusion virtualizes ARM guests, not x86 Cisco nodes at native speed. If your only machine is an Apple Silicon Mac, don't fight it: run CML in the cloud or on a DevNet Sandbox and use the Mac purely as the client, or keep a separate x86 box for the lab. Our DevNet Sandbox guide is the fastest way for a Mac user to get hands-on without any of that.