Real labs — the complete guide

1What your account can do

You can build labs, place machines, cable them, start them, open their consoles, capture traffic and save the result. You cannot put a new image on the server. That is not a limit on your plan — no plan has it. It belongs to the administrator role, because putting a vendor image on a server is a licensing act, not a lab action.

Your account is on the Free plan. This is what that decides — read out of the same table the server checks:

2Your environment

Nothing is installed on your machine — no hypervisor, no VirtualBox, no agent. You have a browser. Everything else lives on a Linux server your account was pointed at when you signed in, and you never typed its address: the server reads your plan and issues the machine that licence covers. It is shown, read-only, on the Server tab.

Your ceilings on Free:

3What is on your shelf

The shelf has two parts, and it matters which is which.

You can open the Images tab and read the whole library — what is installed, which platform it is, which engine runs it. Only the upload area is closed, and it tells you so rather than being hidden.

4A lab in six clicks

This works on any account, on any plan, with no image at all — it uses only the built-ins.

Everything the rest of this guide describes — cabling, starting, consoles, capture, saving — behaves the same whether the device is a built-in or a real router image. The only difference is how long it takes to boot.

Short of time? Press Examples. Those labs are already drawn, and the ones built from built-ins start on any plan.

5Start lab, and your ceiling

Until you press Start, a lab is a document. Nothing exists on the server, and nothing counts against you. Press Start lab and the server checks your plan before it builds anything.

If you are over a ceiling it says so with the numbers, not with a shrug:

Three ways forward, and the first two are usually the right ones: remove a device you are not using, stop another lab that is still running, or move up a plan. A stopped lab keeps everything — the topology and the configurations — so stopping one to start another costs you nothing.

One lab runs at a time, on every plan, and a lab belongs to the window that opened it. Open the canvas in a second tab or a second browser and that one is refused — it will not let you build anything until you close it or carry on in the first window. That is on your side: two windows on one account would both be spending the same allowance, and neither would tell you. A team that needs several labs running together needs an account each.

Booting takes a moment. A built-in is instant; a real router image spends a minute or two at starting before it turns running. If a device goes red, click it — the reason is on the device, and it is usually memory on a shared server rather than anything you did.

6Console, capture, save

A click on a device that is not running only selects it. A terminal onto something that has not booted is a window with nothing in it, and laying out a topology should not leave a stack of them behind. Double-click, or the Console button in the device panel, opens one anyway — which is how you write a startup configuration before anything has started.

Click the front panel drawing in a device’s properties to see what the real hardware looks like — where the console port is, how the ports are grouped, and which socket is the interface you are configuring.

Some of what surrounds those three is decided by your plan rather than by the lab. On Free:

Where something is not included, ZNetLab names the plan that includes it rather than greying a button out and leaving you to guess.

7The device I need is not on the shelf

This is the one thing you genuinely cannot solve yourself, so here is how to solve it in one message instead of three.

First check it is really missing: open Images and read the list. A platform can be installed under a name you did not expect — viosl2 is the IOSv switch, csr1000vng is the CSR.

If it is not there, ask for it from the plan window: your profile, or the Plans page, then See what you can run. It lists every platform ZNetLab recognises that this server has not got, and the form asks for exactly the three things an administrator needs — which platform, which release, and what it is for — so nobody has to come back and ask. Asking carries a small one-time charge for the work of sourcing, checking and filing the image; it is shown before you agree to it, and it is not a charge for the software, which ZNetLab does not supply and cannot license to you.

A message to a human still works, of course. If you send one, send this:

While you wait, the lab is rarely blocked outright. The built-in LAN Switch covers VLANs, trunking and access ports; Virtual PC covers addressing, routing, DHCP and NAT through the NAT Cloud. Draw the topology now and swap the real image in when it lands — a saved lab does not care which device type sits at a position until you start it.

8What you never see, and why

None of this is hidden from you as a matter of secrecy. Where a thing is out of reach, ZNetLab says which role or plan reaches it — so you always know what you are looking at, and who to ask.

1The shape of it

You draw a topology in this browser. A Linux server boots the actual vendor images and wires them together with kernel networking. The consoles and the packet capture come back here over one WebSocket. Nothing is installed on the machine you are reading this on — no hypervisor, no VirtualBox, no agent. The browser is the whole client.

2Sign in — and what the account decides

Real labs is not reachable signed out. One account covers the whole product: the lessons, the free simulator and this lab server.

The address is a property of the account, not of the browser. When you sign in, the server reads the plan on your account and issues the lab machine that licence buys — a free account lands on the shared machine, a paid one on the machine it pays for. It appears read-only on the Server tab. Change the plan and the account moves with it; there is nothing to retype and no way to point yourself at a machine your licence does not cover.

The same plan sets the ceilings the lab enforces at Start lab — how many devices, how much memory, how many labs may run at once.

3Load an image

Done once, by an administrator. ZNetLab ships no vendor software — you supply images you are licensed to run. Two ways in, and they end in the same place.

Identity lives in the directory name, not the file name, because a QEMU library image is a folder of disks. That is also why two builds of the same platform never collide: they are two directories, and both stay.

4The workspace

Open the Lab tab. Four areas, and that is the whole screen.

5The icons, and what each one means

A device is drawn by its kind, not its brand — a Cisco router and a Juniper router share a drawing because on a diagram they do the same job. The registry maps each platform to one of these, and a few platforms are named exactly where the generic drawing would tell you nothing (a wireless controller is not a router).

And what the real one looks like

An icon says what a device does. It says nothing about what you would be standing in front of with a console cable in your hand — which is the other half of learning this, and the half a simulator usually skips.

So every device also has a front panel in its properties: the chassis, the ports laid out the way that family lays them out, the console port picked out in its own colour, the status LEDs — and each socket carrying the same interface name you are typing into the CLI. That last part is the point. Gi0/1 stops being a string in a configuration and becomes the second port from the left. Click the drawing to open it at a size where the labels can be read.

The label under a device carries its state, and links are coloured the same way:

6Build a topology

Either way you are asked two things: which cable, and which interface at each end. Seven media are offered — straight-through, cross-over, fibre, serial, console, coax and wireless — and the one that fits the two devices is already selected, so the usual answer is to press Connect. The interfaces that suit the cable are listed first; ones already carrying a link are shown as in use rather than hidden. If neither device has the kind of interface the cable wants — a serial or a radio — the picker offers to add one, named the way the platform names it.

The medium is a property of the drawing: on the canvas a serial WAN link, a fibre uplink and a wireless association each look like themselves, and a key in the bottom-left corner names the ones this lab uses — only those, so a diagram with one kind of cable does not get a seven-row legend. Underneath, all of them are the same Linux bridge. Change it later from the link’s panel — no restart, because nothing about the datapath changed.

Nothing has been created on the server yet. Until you press Start, a lab is a document — devices, positions, links and the ports they land on. That is deliberate: you can draw the whole thing offline, save it, and start it later, or on another server.

In a hurry, press Examples and open Two PCs on a wire. It is already built and it starts on any plan, because it uses only built-ins.

7Start lab — what the server actually does

This is the moment the document becomes running software. Seconds for built-ins; a minute or two for a real router image.

One device at a time

Start lab boots everything. Afterwards each device has its own power — the ⏻ on its top-left corner, or Power on / Power off in its panel.

That is not a convenience, it is the experiment. Pull one router and watch the protocol reconverge; put it back and watch it settle. Stopping the whole lab to do that would take every other console and every running capture down with it. The links stay in place while a device is off, so it rejoins the topology it left.

This is why there is no hypervisor to install. Three of the four engines are not virtual machines at all. Only full disk images need virtualization, and they use KVM — which is part of Linux. A modest server therefore runs far more devices than one-VM-per-router ever could.

8Console

Clicking a device that has not booted only selects it, and moving one opens nothing — so laying out a topology does not bury the screen in terminals. To write a configuration before anything is running, double-click instead, or press Console in the device panel: what you type there is kept and pasted in the moment the device boots.

Prefer your own terminal client? Set it as your default console from the ⚙ in the window’s title bar, and a click on a device opens the device there instead — or in both at once. Section 8 explains how that works and what it cannot do.

Output is coloured as it arrives, keyword by keyword: an interface going up or down, a rejected command, a ping that answered or did not, interface names, addresses and the IOS facility on a log message each read differently. A console scrolls faster than anyone reads, and the point is to make what you are watching for findable without reading every line. Real ANSI colour from the device is honoured too, rather than printed as escape codes.

Log gives you the transcript: save it to a file, copy the lot, or turn on a timestamp against every line. The file is written in the usual session-log shape — opened and closed lines around the session, and no escape codes in it.

It is the vendor’s own command line, because it is the vendor’s own software booted from your image. Nothing is reimplemented. Every device also gets a TCP port in the 23000–23999 range, so your own terminal can attach to the same console at the same time — useful when two people are looking at one problem.

If you would rather use your own terminal

You can make that the default. The ⚙ in the console window’s title bar — and the Default console card on the Server tab — set what a click on a device does:

The setting belongs to the browser, not the account — a client is wanted on the machine it is installed on. External terminals are a plan feature; where yours does not include them, the click still opens the console in the page and says why.

The window itself behaves the way a terminal does anywhere else, because it is one: every key goes to the device as you press it and the device echoes, exactly as in any terminal. So history on the arrow keys is the device’s own history, Tab and ? are answered by the device, a password prompt hides what you type, --More-- pages on a space, Ctrl-C really does break a running ping, and Ctrl-Shift-6 sends the Cisco break. Ctrl-Shift-C/V for copy and paste (plain Ctrl-C has to stay break), Shift-PgUp/PgDn to scroll, Ctrl-Shift-F to search the scrollback, and A− / A+ for the text size. Scroll up and it stops following, so output cannot yank the view away while you are reading — the status bar says scroll lock while that is true, alongside the connection, the console address, the measured size, how long the session has been open and how much scrollback is behind you.

It is deliberately conservative. Colour that is wrong is worse than colour that is absent, because it teaches you to distrust all of it. Where the device sends real ANSI colour of its own, that wins — nothing is repainted over it.

Log opens a small menu: Save session log writes a file named for the device and the minute, Copy everything puts the transcript on the clipboard, and Timestamp every line prefixes each line with the time it actually arrived — captured when it was written, not invented at save time. The file carries the usual opened and closed session-log lines, and no escape codes.

9Capture

Writing and drawing on the diagram

A topology is a drawing somebody else has to read, and a cable is only half of what it says. Draw ▾ in the toolbar adds the other half: a note for text, a rectangle or ellipse to box a group — drawn behind the devices, so what you drew around is still visible and still clickable — and a line for a boundary of your own.

Ctrl+A selects every device, a box dragged on empty canvas selects what it covers, and shift-click adds one. They move together and delete together, and deleting asks first. Escape stops drawing and lets a selection go. All of it is saved with the lab and travels with it to the portal; none of it is a device.

Slots and cards

A real 7200 has no FastEthernet1/0 until somebody puts a PA-2FE-TX in slot 1. ZNetLab fits the cards for you by default, but the card decides what the port is — an NM-4T makes Serial1/0..1/3 where an NM-1FE-TX makes FastEthernet1/0. Select a device with card slots and the panel lists them; choose a card and the interfaces are rebuilt from it.

Slot 0 is onboard on the integrated routers and cannot be changed — the emulator fits it itself and aborts if asked for it twice. An empty slot stays empty. A slot will not change while a cable is attached to a port it would remove, and a running device keeps its hardware until it next starts.

Two ways in, and they are the same capture. Click a link and press Capture to watch that cable; click a device and press Capture to watch that machine — with one cable it starts at once, with several it asks which interface and names what is on the far end. An interface is a link, so nothing is recorded twice.

Protocols answers the three questions a capture usually gets asked. Which packets should be here — read out of the startup configuration of the two devices on this cable, so an OSPF that is configured and silent is a red row rather than a mystery. Are they on time — the measured interval beside the protocol’s own default, and beside the interval the packets themselves advertise, because OSPF, HSRP, STP and BGP all carry their timers in the frame. If the two ends advertise different timers the adjacency will never form, and nothing else in any product tells you that. And which ones cause trouble — an ARP nobody answered, two devices claiming one address, an unreachable, a reset, a Discover with no Offer, a broadcast storm, and the IOS Ethernet keepalive that flaps every emulated link. There is a table of every default timer at the bottom, worth reading before you capture anything.

The pane opens on Overview: the rate, the protocol mix, who is talking and the conversations, as figures rather than tables — and every bar is a filter, so clicking one takes you to the packet list with that protocol or that address already applied. Packets is the list with the layer-by-layer detail and the bytes; Flow is the time-ordered graph of who sent what to whom.

Open externally pipes the live stream into your own analyser. The server is already running tcpdump; this hands you those bytes untouched, so it is treated as a live interface instead of a file that stopped being true when you saved it. The command is written for you, with the address, the capture id and your session token in it — which is why it must not be pasted into a ticket. A capture belongs to whoever started it; nobody else can read that stream, administrators included.

Pick a cable in that window and the capture is started for you, and what you get back is an address your analyser can open on its own — no token to paste and no curl to get right, because the key is in the address. There is also a launcher to download: a small script you double-click, which opens your analyser on the live stream. The key opens that one capture and nothing else, it is yours, and it stops working after fifteen minutes or when the capture stops.

Frames appear as they cross the bridge, and Export .pcap hands you a file any analyser opens. These are real frames off a real interface, not a rendering of what the traffic ought to look like — which is the whole difference between a lab and a simulator.

A link also takes conditioning: add delay, jitter or loss to a cable and watch what the protocol does about it.

Live, next to Capture on the toolbar, draws every captured frame on the cable it crossed — a coloured marker travelling from the device that sent it to the one that received it, with a running count above each device. Hover a packet to hold it still and click it to open that frame in the analyser, with its layers and its bytes. Each device’s own panel grows a Live traffic list of the last frames in and out of its interfaces, and every row opens the frame too. It draws what a capture reads and nothing else: switch it on with nothing being captured and it offers to capture the cables for you.

Each cable also keeps what last crossed it on a small label under the wire, so a cable says what is on it even when you were not watching for the marker. Right-click the Live button for two settings: the addresses on each packet, and slow motion — which is what to use when a short cable makes a packet a flicker.

Which way a packet was going is not in a capture — tcpdump on a bridge reports the frame and not the port it came in on — so ZNetLab reads the bridge’s own address table instead of guessing. Until that answer arrives a marker is drawn hollow and says so.

Everything the workspace tells you is kept. The Notifications tab in the bottom-right corner carries a count and the colour of the worst thing in it you have not read; click it for every notice with the time it arrived, filtered by kind if you want. Which ones also appear as a card over the drawing is a setting in that list — errors only, by default. Nothing is lost and nothing sits on top of your topology.

Operations · NOC, under the toolbar’s tools menu and in your account menu, is the other half of watching a lab. Give each device a Site in its panel — HQ, Branch-2, DC-East — and that screen groups them into places and says which place is down, which is short of devices, and what raised every alarm, with what to do about it. It also reads each device’s TACACS+ and RADIUS configuration: which server it points at, whether a shared key is set, whether that server is a device in this lab and whether it is running — and, when a capture is going, whether those frames are really crossing the wire.

10Save, stop, come back

A saved lab keeps the devices, their positions, the links and the configurations you wrote. Stopping a lab frees the server’s memory without losing any of that, so tomorrow you press Open and then Start, and it comes back as you left it.

11What Real labs gives you

12When something does not work

13Next to GNS3 and EVE-NG

All three boot the same images the same way: one qemu-system-x86_64 per device, with a per-device copy-on-write disk in front of a read-only library file. They differ in three places, and only three: where the knowledge of which flags an image needs is kept, how the console is carried back to you, and how the cables are made. Everything that looks like a deep architectural difference comes out of one of those.

Where the knowledge of how to run an image lives

None of the three works it out by looking at the file. Each keeps a written description per product, and the three formats hold almost the same fields under different names. GNS3 keeps a .gns3a appliance file per product, written by the vendor or the community. EVE-NG keeps a template per product under /opt/unetlab/html/templates/, where the whole QEMU incantation is one qemu_options string, and pays for that simplicity with a naming rule: the image must sit in a folder named for the template and be called hda.qcow2 or virtioa.qcow2. ZNetLab keeps a platform table that both the server and this page read, with a pattern per platform that recognises an image by its filename.

On this server there are 228 appliance files describing 1,115 versions between them, and 352 platforms in the table, 124 of them ZNetLab own (109 QEMU, 6 Dynamips, 2 IOL, 4 Docker and 3 built-ins that need no image). A built-in is never replaced by an imported file, which is why 27 appliance files are read at every start, found to clash, and set aside.

All of those are carried through to the command line here, along with the boot priority, the guest architecture and the appliance own extra QEMU arguments. Every disk interface the 228 files ask for is built: virtio (107), ide (92), sata (14) and scsi (10).

Why an image that boots can still look dead

A QEMU guest talks either down a serial line or onto a screen, and which one it uses is a property of the image, not a preference. The appliance files say so, and on this server they say it like this:

All three read that field and act on it. A serial appliance gets a terminal; a graphical one gets a screen. That is new here, and it is worth saying what it replaced: ZNetLab used to read vnc, write down no console, and start the machine with a serial line it would never write a byte to. 69 of the 228 appliances are of that kind — Cisco ASAv, ISE, vWLC, DCNM, Aruba VMC, Kali, FreeBSD, CentOS and every Windows desktop — and each of them booted perfectly, held its memory, answered on the network, and looked from the only window you had on it exactly like an image that did not boot.

What happens instead now: a device whose platform says its console is a screen is started with QEMU’s own VNC server on the loopback rather than -nographic, and its console window gains a Screen button beside the terminal. The picture comes over a WebSocket this server authenticates with a one-use ticket that dies in thirty seconds — so nothing about the screen is reachable from outside the host, and no credential is ever written into a URL. Keyboard and mouse go back the same way, and Ctrl+Alt+Delete has a button of its own because no browser will hand that chord over.

Hardware acceleration, and what it really decides

KVM is not a feature any of the three implements. It is a kernel interface onto the processor own virtualisation instructions; with it QEMU hands guest code to the CPU to run directly, and without it QEMU translates every guest instruction, which is roughly ten times slower and otherwise the same machine. A server that is itself a virtual machine, on a host that does not pass virtualisation through, cannot have it — and nothing inside the guest can change that. GNS3 or EVE-NG installed on such a host hits the identical wall; neither avoids KVM, they are simply normally run on a machine that has it.

Of the 228 appliance files, 116 say they require it, 62 say they allow it, 48 say nothing and 2 say to disable it. Require is mostly a wish, though, not a fact: it usually means or it will be slow. Alpine Cloud Guest says require and boots on a host with no KVM in about four minutes. There are exactly two ways a guest genuinely fails without it, and they look identical from the lab — an open console with nothing in it:

What this server does that the other two do not

It resumes a booted machine instead of booting it again. Once a device has reached a prompt, ZNetLab tells QEMU to write the whole machine — memory and devices — to a file, and the next start of a machine of that exact shape loads it and comes up already booted. The file is keyed by everything that would make it the wrong state to load: image, RAM, CPUs, NIC model, port count and accelerator. Neither GNS3 nor EVE-NG has anything of the kind; both boot the guest every time.

It refuses with a reason, before it spends anything, where the other two leave you with a QEMU error or a setting that says no. It measures this host rather than guessing, so the countdown on a booting device is this machine own figure for that platform. It reads the console and names what it sees — three line-protocol drops inside two minutes is the Ethernet keepalive failing on a bridged interface, and it says so once per device rather than leaving somebody to work out why pings are dropping. And an image becomes a device by being dropped in a directory: no folder to name, no appliance to pick first.

What is missing here, in the order it costs you

This list is not an opinion. It is what the appliance importer writes down, per file, when it reads something it cannot honour:

The line that used to head this table — draw a graphical console, 69 appliances, 30% of the library — is gone from it, because it is built. What is left is small: a SPICE appliance is run with a VNC screen instead, which shows the machine but carries neither the shared clipboard nor the USB redirection SPICE would have. Thirty appliances also try to pass -nographic and fifteen -smp; those are dropped on purpose, because ZNetLab sets them itself and QEMU takes the last of a repeated flag.

What would change it, in the order it pays

Two problems, and they pull in opposite directions: a host with no hardware assist translates every instruction, so running machines are expensive; and a third of the library cannot be looked at. Seven things would move both, and they are listed by what they return rather than by how interesting they are. None of them needs hardware this server does not already have, except the last.

The first is done. The second changes what a reader sees the next time an image hangs; the next four change what the server feels like under a full lab; and only the seventh needs somebody to buy a machine.

Cisco, IOS, Catalyst, Meraki, Packet Tracer, CCNA, CCNP, CCIE, Juniper, Junos, Arista, EVE-NG, GNS3, Wireshark, SecureCRT, PuTTY and other names are trademarks of their respective owners. ZNetLab is an independent product and is not affiliated with or endorsed by them. ZNetLab ships no vendor software. Terms · Privacy · Licences

1What you are building

One Linux machine. It holds the images, boots them, wires them together with kernel networking, and answers a WebSocket. Everybody else needs only a browser — there is no client to install, roll out, or keep in step.

2What the machine needs

That last row is the only thing that really differs between the platforms, so here it is in one place:

3Install it

Pick where it is going. The steps change; what you end up with does not.

Linux — Ubuntu, Debian or RHEL

A clean Ubuntu or Debian box to a running lab server in one command. The script installs the packages, makes the directories, asks for the administrator password, starts the service — and then proves the result rather than announcing it.

What it does, in the order it does it:

Windows — through WSL2

ZNetLab needs Linux networking — namespaces, veth pairs, bridges. Windows does not have those, so on Windows the server runs inside WSL2, which is a real Linux kernel. You do not have to learn WSL: one script does the whole thing.

It registers the distribution, installs the packages inside it, verifies the Linux datapath, starts the server, proves it with a real lab, and prints the address, the username admin and a generated password — copy that password before you close the window.

Two Windows-only conveniences worth knowing:

KVM works: WSL2 supports nested virtualization, so QEMU images run at full speed. This is a genuinely good way to run a personal lab server on a laptop.

VMware — Workstation or Player

Every other platform on this list either has hardware virtualisation or does not. This one hands it out: a desktop with VT-x or AMD-V can pass that through to a Linux virtual machine, which is exactly what a rented VPS usually refuses to do. So if the QEMU images are the point — IOSv, CSR1000v, ASAv, vSRX — a Linux VM on a machine you own beats a cloud instance that bills you for software emulation.

If both of those answer, the rest is the Linux page above, unchanged — this is an ordinary Ubuntu server that happens to live in a window:

The four settings that actually matter, and why:

Worth being plain about the shape of this: the VM is the server, not a device. ZNetLab does not drive Workstation and cannot boot a lab device as a Workstation VM — the cabling in a topology is Linux bridges, veth pairs and namespaces inside that one guest, and a vmnet switch on the host has no way into them. Workstation is here because it is the cheapest way to get a kernel that owns /dev/kvm.

AWS — EC2

Two things worth doing on day one, both about the images rather than the server:

Azure — Virtual Machines

4First sign-in

The installer prints an address, a username and a password. That account is the only administrator until you make another, and ZNetLab seeds no demo accounts — there is nothing with a default password to forget about.

Open the ZNetLab site, sign in with that, and the Accounts tab, the Admin portal and the Images upload appear. Then, in this order:

5Host your images

ZNetLab ships no vendor software, and it never will — those images are licensed by their vendors. You put in the ones you are entitled to run. There is one destination and four ways to reach it.

Naming is the only thing ZNetLab asks of you, and only when it cannot work the name out itself. Get it right and there is nothing else to configure — RAM, interface naming and which engine runs it all come from the platform it recognises.

Want to prove the whole thing before you touch a licensed image? Several genuinely free ones need no licence at all — FRRouting, VyOS, Cumulus VX, Arista vEOS, pfSense CE, OPNsense, Alpine and Ubuntu Server. Drop one in and watch it come out on the shelf.

6Prove it works

A lab server that looks up but silently does not forward traffic is the worst outcome, so ZNetLab ships two checks and the installer runs both. Run them yourself whenever you change the host.

Then the human check, which takes a minute: build two Virtual PCs and a LAN Switch, start it, and ping across. No image, no licence — if that works, the datapath works.

7Keep it running

8Lock it down

Generated by tools/guide-pdf.js from the guide functions in lab/assets/app.js, the icon set in assets/icons.js and the plan table in assets/plans.js — the same plan table the server enforces. Every screen, button, path, port, command and ceiling named above is read out of the running product rather than transcribed, so this document goes stale only when the product does. Part I's plan tables are shown for the Free plan, which carries the tightest ceilings of any.