The Best Way to Practice CCNA Hands-On (Without Buying Gear)

Your options for hands-on practice

Packet Tracer is the free, beginner-friendly place to start learning commands. GNS3 and Cisco Modeling Labs run real Cisco IOS for realistic practice. Physical gear and rack rentals are the most 'real' but the most expensive and least convenient. For most people, CML on free-tier images hits the sweet spot: real IOS, low cost, no hardware.

Reps beat marathons

Cramming a weekend of labbing does far less for retention than a short lab every day. Spaced, consistent practice is how skills stick — the same reason athletes train daily rather than once a month. A single focused scenario a day, done deliberately, builds the muscle memory the exam tests under time pressure.

Practice you can actually check

The weakness of most self-study labs is that nobody tells you whether your configuration is right — you follow a walkthrough and assume it worked. Grading closes that loop: you build the lab, upload your config, and get pass/fail on every requirement, so practice ends in certainty instead of guesswork.

That's exactly what Goldfish Networks does — a fresh, graded CCNA/CCNP lab every day, built for CML, that checks your own work against the answer key. Start with the free sample lab and run the whole loop before you subscribe.

Setting up a free CML practice rig (what actually runs where)

CML is not a program you double-click; it is a virtual appliance -- an entire Linux server shipped as an OVA or ISO that you import into a hypervisor, which in turn spins up virtual routers and switches inside itself. Its supported host is VMware: Workstation on Windows and Linux, and Fusion on macOS, both now free for personal use, which is what makes the no-hardware path genuinely cheap. VirtualBox is not a supported CML host, so plan on VMware or a small ESXi box.

The appliance model matters because every node you drop on the canvas is a real IOS instance that consumes RAM and vCPU from the host. A 16 GB laptop comfortably runs a handful of lightweight IOSv or IOL nodes, but it will crawl if you try to boot a dozen full Layer 2 switch images at once. For CCNA-level work, favor the lighter reference platforms and only reach for heavier images when a specific feature demands them; exact image availability and free-tier limits shift over time, so check current Cisco terms rather than trusting a number you read once.

Whatever the topology, the first thing worth doing on each fresh node is the management bring-up so you can SSH in and, later, hand a clean running-config to a grader. Set the hostname and domain name, create a local user, lock the VTY lines to SSH, and generate the RSA key -- and mind the order, because the key generation depends on a domain name already being set.

R1> enable
R1# configure terminal
R1(config)# hostname R1
R1(config)# ip domain-name lab.local
R1(config)# username admin privilege 15 secret C1sco123
R1(config)# ip ssh version 2
R1(config)# line vty 0 4
R1(config-line)# login local
R1(config-line)# transport input ssh
R1(config-line)# end
R1# crypto key generate rsa modulus 2048
% Generating 2048 bit RSA keys, keys will be non-exportable...[OK]

Verify before you trust it: reading your own lab like a grader

Grading gives you a pass or fail, but you improve fastest when you can predict that verdict yourself before you submit. The habit to build is finishing each task and immediately proving it with show and ping instead of eyeballing the running-config. Consider a two-router lab: R1 and R2 share a 10.1.12.0/30 link (R1 = .1, R2 = .2), R2 hosts the 192.168.20.0/24 LAN, and R1 needs a static route to reach it.

You configure the route by pointing at R2's near-side address, then confirm two separate things -- that the route installed (control plane) and that traffic actually crosses (data plane). Because you specified a next-hop IP, the router performs a recursive lookup: it must first resolve 10.1.12.2 to an outgoing interface using the connected /30 route before it can forward. Had you written the route with only an exit interface, it would skip recursion but lean on proxy ARP at the far end, which is exactly why the next-hop form is more predictable on shared segments.

Make that same two-step check your default across every topic: a matching line in show ip route (or show ip ospf neighbor, show standby brief, and friends) proves the control plane converged, and a successful ping or SSH proves the data plane end to end. One quirk to recognize while reading the table is that OSPF advertises a loopback as a /32 host route by default no matter what mask you configured on the interface, so do not panic when 10.0.0.1/32 appears where you expected the full subnet -- that is expected behavior, not a broken lab.

R1(config)# ip route 192.168.20.0 255.255.255.0 10.1.12.2
R1(config)# end
R1# show ip route static
      192.168.20.0/24 is subnetted, 1 subnets
S        192.168.20.0 [1/0] via 10.1.12.2
R1# ping 192.168.20.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms