Simulator guide

Which simulator?

There are two, and they are for different jobs. Neither is a lesser version of the other.

Start with the browser simulator. It is faster to iterate in, it tells you when you are wrong, and it costs nothing. Move to real labs when you need something it cannot give you — and the guide below covers both, with a complete worked lab for each.

Your account

Both simulators need you to be signed in. The lessons, articles and forums are open to anyone; the Simulator and Real labs send you to the sign-in page first, and back to where you were going afterwards.

Everything that is yours is in the account panel — click your name at the top right of any page:

Your language

Click the 🌐 in the header — or choose it in Edit profile — and pick from 25 languages (हिन्दी, मराठी, বাংলা, தமிழ், తెలుగు, ગુજરાતી, ਪੰਜਾਬੀ, ಕನ್ನಡ, മലയാളം, اردو and more). The site is translated automatically by Google Translate, which is only contacted once you choose a language other than English. Consoles, commands and code are never translated — a translated command would be a wrong one. Choose English to switch back.

If you are in a company

When your company uses ZNetLab, you get the company's plan, its company labs (Real labs → Open ▾ → From the company library), any router images your company added, and its logo on the workspace. Signing up with your company email address may add you to it automatically.

The header menus: Learn, Simulator, Real labs, Guide (this page — the simulator guide and the real-labs guide) and Contact. Plans is not in the header: your plan is a thing about your account, so it lives on your profile, with the price list a click away. An account is created by an administrator, or by signing up on the sign-in page when the server allows it.

Signing in, and staying signed in

Most of this you will never have to think about. It is written down because when one of these things does happen, it looks like a fault, and it is not.

One place at a time

Your account can be signed in at one place at a time. Sign in on your phone and the browser on your desk is signed out — and it is told so, and told where from: “this account signed in from 203.0.113.9”. Read that message. Either it was you on another device, or it was not, and the second of those is the entire reason the rule exists.

Your running lab is not affected. Signing in somewhere else moves your session, not your devices. Everything you had running keeps running, and the new place picks the same lab up where you left it — a router you were halfway through configuring is still there, still booted, with its configuration intact. Closing a browser does not throw a lab away either.

One tab at a time, for a real lab

A real lab runs in one browser tab, and only one. The window that started the work keeps it; open a second tab, or a second browser, and that one is told so at once and cannot build anything. The message will not let you past it until you close the duplicate or carry on in the first window.

This is deliberate, and it is on your side. Two windows both building on one account would both be spending the same allowance — you would pay for a four-device plan and quietly be using eight devices' worth of memory, and neither window would tell you. The rule is enforced on the server and not only in the page, for the same reason every other limit here is.

It is also why every plan runs one lab at a time, including the paid ones: a lab belongs to the window that opened it. A team that needs several labs running together needs an account each.

The browser simulator has no such rule. It runs on your own machine and costs nobody anything, so open as many tabs of it as you like.

If you get your password wrong

After five wrong attempts, further attempts are refused for a minute; keep going and the wait grows to five minutes, then thirty, then two hours. The message always says how long is left. It is a pause, not a locked account — it decays on its own, and one correct password clears it immediately. If you are genuinely stuck, an administrator can lift it at once.

Where you signed in from

Profile → Sign-ins and security lists every sign-in on your account with its country, state, city, address and network, and can draw them on a map. This is for you as much as for anyone: a sign-in from a city you have never been to is the one thing worth acting on straight away, and the page has Sign out everywhere else right beside the list.

The location comes from your network address, worked out on the server. The site never asks your browser for your location — that permission is switched off for every page here, so your browser will never show you a prompt for it.

Signing out

Sign out is in the account panel at the top right of every page, and again in Profile → Sign-ins and security, where you can end your other sessions without ending this one. Signing out does not stop a running lab — use Stop in the workspace for that, or leave it and it will be stopped for you (see the real-labs workspace).

Registering

Registration asks for your full name, email, phone number, company or institution, and your occupation. All of them are required. We send a six-digit code to your email address to prove it is yours: it lasts ten minutes, is good for one use, and you get five tries at typing it. Ask for another after sixty seconds if it does not arrive.

If the server cannot send email, the sign-in page says so on the first screen rather than letting you fill in the form and wait for a code that is not coming. In that case an administrator creates the account for you.

What we keep, and what we never keep

Your activity — sign-ins, labs started and stopped, devices, images — is kept for 24 hours and then deleted. You can read your own in Profile → Activity. Your company's administrator can see your company's; nobody else can.

Never stored anywhere: your password in readable form, your session token in readable form, the codes we send you, or anything you type into a console. A failed sign-in records the name that was tried and nothing else — not what was typed as the password.

If something looks wrong

Use Support in the account panel, or the assistant at the bottom right of any page. A sign-in you do not recognise, a device you did not start, or a page asking you for something it should not — say so, and change your password from Edit your profile while you wait for an answer.

The simulator workspace

Open Simulator. It uses a classic network-simulator layout, and it is worth two minutes to know which area is which before the first lab.

Every section can be resized, and your layout stays. Drag the seam above the device shelf, beside the right panel, or above the PDU list; double-click a seam to put it back. Sizes, the open panel, the zoom, the workspace and whether the PDU list shows are all remembered on this computer — a reload brings back exactly the layout you left. The device shelf always stays at the very bottom. Full screen hides the site header as well — Esc leaves it.

Realtime and Simulation

Two modes, and the difference is the whole point of a simulator. Realtime forwards traffic as fast as it can, like a network — and with Packet flow on you still see every packet cross every cable. Simulation steps one packet at a time so you can stop on each hop and read what the device did with it. Open the panel with Show simulation, close it with Hide simulation. Use Realtime to configure; step in Simulation the moment something does not work.

Lab 1 · Static routing between two LANs

About 15 minutes. Two LANs that cannot reach each other, and two routers between them. This is the lab everything else builds on: if you understand why these four commands are needed, subnetting and routing stop being abstract.

The topology — already on the canvas when you pick this lab:

PC0 ──── Switch0 ──── Router0 ──── Router1 ──── Switch1 ──── PC1
192.168.1.10        .1  10.0.0.1  10.0.0.2  .1        192.168.2.10
   LAN 192.168.1.0/24      WAN 10.0.0.0/30      LAN 192.168.2.0/24

1. Pick the lab Open Tasks in the right strip → OPEN A LAB → Enterprise · Static routing between two LANs. (The simulator opens on a blank workspace; this is the sample lab it ships with, also under File → Open Samples.) Five tasks appear, worth 70 points.
2. Address Router0's LAN side Double-click Router0. Its window opens on the CLI tab — press Enter and you are at Router0>.

   enable
   configure terminal
   hostname R0
   interface GigabitEthernet0/0
    description LAN side
    ip address 192.168.1.1 255.255.255.0
    no shutdown
    exit

   Task 1 turns green. The interface came up because you said no shutdown — every router interface starts administratively down, and forgetting this is the single most common reason a lab does not work.
3. Address Router0's WAN side

   interface GigabitEthernet0/1
    description to R1
    ip address 10.0.0.1 255.255.255.252
    no shutdown
    end

   A /30 gives exactly two usable addresses — one for each end of a point-to-point link, and nothing wasted.
   
   Check it:

   show ip interface brief

   Both interfaces should read up / up. The first up is the physical link; the second is the protocol. Up/down means the cable is fine and the far end is not talking.
4. Do the same on Router1

   enable
   configure terminal
   hostname R1
   interface GigabitEthernet0/1
    ip address 10.0.0.2 255.255.255.252
    no shutdown
    exit
   interface GigabitEthernet0/0
    ip address 192.168.2.1 255.255.255.0
    no shutdown
    end

   Task 3 turns green.
   
   From R0, prove the WAN link works before going further:

   ping 10.0.0.2

   Five exclamation marks means five replies. Full stops mean no reply — check both addresses are in the same /30 and both interfaces are up.
5. Give each router a route to the other LAN A router only knows the networks attached to it. R0 has never heard of 192.168.2.0/24, so it drops anything addressed there.

   ! on R0
   configure terminal
   ip route 192.168.2.0 255.255.255.0 10.0.0.2
   end

   ! on R1
   configure terminal
   ip route 192.168.1.0 255.255.255.0 10.0.0.1
   end

   Read it as: to reach that network, send it to this neighbour. Both directions are needed — a reply that cannot get home looks exactly like a request that never arrived.
   
   

   show ip route

   The new line begins with S for static. C is connected and L is the local address itself.
6. Address the PCs and prove it Double-click PC0 → Desktop → Command Prompt (or use IP Configuration if you prefer a form):

   ip 192.168.1.10/24 192.168.1.1

   And PC1:

   ip 192.168.2.10/24 192.168.2.1

   The second address is the default gateway — the router interface on that PC's own LAN. Without it a PC can reach its own subnet and nothing else.
   
   From PC0:

   ping 192.168.2.10

   Task 5 turns green. Press Run check (the ▶ at the bottom of the tools rail) for all 70 points.
7. Now watch it happen With Packet flow on, ping again and keep your eye on the workspace — then click an envelope to open it. To go one hop at a time, press Show simulation, switch to Simulation mode, and ping again.
   
   You will see, in order: an ARP request broadcast by PC0 asking who has 192.168.1.1, the router's ARP reply, then the ICMP echo. Follow the echo across and watch the MAC addresses change at every hop while the IP addresses never do. That one observation is what routing is.

If it does not work

Lab 2 · OSPF, and what happens when a link breaks

About 20 minutes. Static routes do not scale and do not react. OSPF does both. Build a triangle of three routers so there are two paths between any two of them, then break one and watch the network repair itself.

1. Build the triangle Drag three routers onto the canvas. Link R1–R2, R2–R3 and R1–R3. Address each link as a /30: 10.0.12.0/30, 10.0.23.0/30, 10.0.13.0/30 — the digits say which routers the link joins, which is worth doing from the start.
2. Give each router a loopback

   interface Loopback0
    ip address 1.1.1.1 255.255.255.255
    exit

   (2.2.2.2 on R2, 3.3.3.3 on R3.) A loopback never goes down, so OSPF uses it as the router's permanent identity. Without one, the router ID changes whenever an interface flaps.
3. Turn OSPF on

   router ospf 1
    router-id 1.1.1.1
    network 10.0.12.0 0.0.0.3 area 0
    network 10.0.13.0 0.0.0.3 area 0
    network 1.1.1.1 0.0.0.0 area 0
    end

   The mask is inverted — a wildcard, not a subnet mask. 0.0.0.3 means "match the first 30 bits". 0.0.0.0 means "exactly this address". Getting this backwards is the classic OSPF mistake.
4. Watch the adjacencies form

   show ip ospf neighbor

   You want FULL. If it stops at EXSTART or 2WAY, the two ends disagree about something — usually an MTU mismatch or different area numbers.
   
   Then:

   show ip route ospf

   Routes marked O that you never typed. That is the point.
5. Break something Select the R1–R2 link and shut it down.

   ! on R1, immediately
   show ip route ospf

   The route to 2.2.2.2 now points via R3. Nobody reconfigured anything — OSPF recalculated. Bring the link back and it returns.
6. See why it knew Capture a router-to-router link in Simulation mode. Every ten seconds each router sends a Hello. When the link went down the Hellos stopped, the neighbour was declared dead, and an LSA was flooded telling everyone the topology had changed. That is the entire mechanism.

Building your own lab

1. Drag devices from the tray onto the canvas.
2. Link them — choose Cables on the shelf, pick a cable, click one device and its port, then the other.
3. Add ports if you need them — power the device off and drop a module into a slot on its Physical tab (see Devices, modules and power).
4. Configure by double-clicking each device.
5. Save it as a lab — Create a lab… in the menu bar. Write the tasks, and the checker will verify them for whoever opens it.

Saving and opening labs

A lab can live in two places, and both hold the same file:

The file keeps everything: devices and where they are, fitted cards, power state, every device's configuration, cables with their lengths, shapes, text, notes, clusters, saved PDUs, the physical layout — cities, buildings, racks, tables and rack units — and the lab's tasks. The portal needs you to be signed in; each account sees only its own labs. Older .pkt.json and .ncsim files still open.

Your work survives a reload. The simulator opens on a blank workspace, and whatever you build is kept in this browser as you go: if the page reloads — by accident or not — the same topology, configurations and open device window come back. Only File → New (or opening another lab) replaces it. One sample lab ships with the simulator: File → Open Samples, or Tasks → Open a lab.

What this simulator is, and is not

It is a real protocol engine. OSPF forms adjacencies, BGP negotiates capabilities, spanning tree elects a root, and packets are forwarded hop by hop against real forwarding tables built from your configuration.

It is not Cisco IOS. It implements the command syntax and the protocol behaviour; the binary is ours. For learning how a protocol works, and for practising until the commands are automatic, that difference does not matter. Where it does — exact show output for a specific train, a feature we have not implemented, or exam practice — use real labs.

Selecting, deleting and renaming

Shapes, text and colours

The palette button on the tools rail opens a Paint-style box. Shapes: line, rectangle, rounded rectangle, ellipse, triangle, diamond, hexagon, arrow, star, freeform and text — pick one, then drag on the workspace (for text, click where it goes and type). Outline and Fill: click one, then a colour; Edit colours picks any colour, and the ones you use collect under Recent. Below that: text size (A− / A+), line width, solid / dashed / dotted, and fill transparency. With a shape selected every change applies to it; otherwise to the next one you draw.

Text works as in Paint. Pick the T on the tools rail (or Tools → Type Text), drag a box on the workspace — or just click — and type straight into it. The text toolbar above the box sets the font, size, bold, italic, underline, colour, and a transparent or opaque background; Ctrl+B / I / U work too. Click the workspace, the ✓, or press Ctrl+Enter to finish; Esc cancels. Double-click the text later to edit it in place.

Devices, modules and power

Devices are drawn as the hardware they are — a grey Catalyst with its rows of ports, a black ISR 4000, a PC with monitor and tower. The small port lights on an icon are live: green is up, amber is cabled but down. If you prefer the classic topology symbols, turn off View → Realistic device icons.

Real photographs

A model can show a real product photograph instead of the drawing — on the workspace, the shelf, the tables and at the top of its Physical tab. Only an administrator adds product photos: a photograph is somebody's copyright, so the person answerable for the site decides which ones are shown. Everybody sees them; nobody else gets the buttons. If a model should have a photo, ask your administrator.

Wireless

The Wireless shelf category has Cisco's current line: Catalyst CW9176I (Wi-Fi 7) and 9166I (Wi-Fi 6E) access points, the Wireless 9177 outdoor AP, the Meraki MR57, the Catalyst 9800-L and 9800-40 controllers, and Campus Gateway. Access points bridge wireless to wired and controllers are modelled as bridges — there is no radio model, so range and interference are not simulated.

The Physical tab

Open a device and choose Physical. You see its real panel: RJ-45 jacks, SFP cages, serial connectors, the light-blue console port, and the power switch. Hover a port for its interface name — that is the name you type in the CLI.

Adding ports with a module

1. Power the device off — the power button in the window's title bar, the rocker on the panel, or right-click → Power off. Modules are not hot-swappable, here or on the real thing.
2. Drag a module from the MODULES list onto an empty slot — or click the module, then click the slot.
3. Power back on. The new interfaces exist: show ip interface brief lists them and they take a cable.

Cables in the Physical tab. A port with a cable shows its plug. Drag the plug to another free port to move the cable; click it to see where it goes, open the far device or unplug it. Click a free port to plug a new cable in: choose the cable, the device and its port, then Connect.

To take a card out, click the red × on it, or drag it back onto the MODULES list. If the device is still on you are offered Power off and remove. A card with a cable in it has to be unplugged first. Hover any module, card, slot or port for what it is and what it adds.

The interface name follows the slot: an HWIC-2T in slot 0/1 gives Serial0/1/0 and Serial0/1/1. A PC has one card, so dropping a different one on the slot swaps it — the address stays, the interface name changes. A card with a cable on it has to be unplugged first.

Power

Every device window has a ⏻ ON / OFF button in its title bar. You can also use the Physical tab, right-click → Power on/off, or Tools → Power on/off selected device(s) for several at once. A powered-off device forwards nothing and its console is dark.

The console

A router's or switch's CLI tab — and Desktop → Terminal on a PC wired with a console cable — is a tabbed terminal session on the console port.

The PC desktop

A PC, laptop or server opens on its Desktop: a wallpaper, shortcuts down the left, and a taskbar showing the network card's state and the address. Click a shortcut and the program opens in its own window — close it with ✕.

Packet Capture — an analyser, on the PC

The workspace could always record a cable: click the link, watch what crosses it. That is the view a network engineer wants, and it is the wrong one for the question most people are actually asking, which is “what is my machine sending, and what is coming back?” On a real PC you answer that by opening an analyser on the PC. So Packet Capture opens from the desktop and watches this computer’s own interfaces.

Three panes, which are the three questions you ask of a capture:

Start records every interface this computer has; the drop-down narrows it to one and names what is on the far end, so you know which cable you are watching. The display filter takes the words people actually type — arp, icmp, tcp, dns, an address, or any word from the Info column — and anything it does not recognise it says it did not recognise, rather than quietly ignoring the clause and showing you the wrong packets.

Save .pcap writes a genuine libpcap file. Not “a file an analyser might open” — the real format, so every analyser and every command-line reader takes it, and the Ethernet header is built from that frame’s own addresses and ethertype.

These are simulated frames, and the app says so. The addresses and the ethertype are real; the bytes after the header are not a real payload, because this simulator never serialised one. Open the file in your analyser and you will see an ARP or an IP header and then filler. That is honest, and it is the difference between this and a capture taken on the Real labs platform, which comes off a Linux bridge through tcpdump and is real all the way down.

Device windows float. Drag one by its title bar, and keep it open while you work — send a ping from the Command Prompt and watch it cross the workspace behind the window.

Watching packets

With Packet flow on (toolbar, or View → Packet flow animation), every frame the network sends is drawn as an envelope moving along its cable, labelled and coloured by protocol: ARP, ICMP, DNS, HTTP, TCP… They play in the order they happened, one cable at a time.

1. Hover an envelope — every packet pauses, so you can catch one.
2. Click it — a card opens with the source and destination IP and MAC, the length, the info line, and each layer (Ethernet, IP, ICMP/TCP/UDP) opened out.
3. Want to step instead? Switch to Simulation and use the event list — every hop is recorded there too, and in Capture.

The physical workspace

Press Physical (top right). The same network, seen as the places it lives in. Double-click a place to go inside; ‹ Back or the breadcrumb comes out.

In a rack every device is drawn as its own front panel, with live port lights; empty units have blanking panels. PCs, laptops and phones sit on the tables. Double-click anything to open it.

Working in the server room

The bar at the top of the room has everything:

Every cable — whether it was made here or in the Logical view — is drawn as a patch cable from its own port: blue copper, yellow fibre, orange serial, light-blue console. A dashed cable is down. It is the same link in both views.

Distance is real. Where you put things decides how long the cables are: two devices in one room are metres apart, two cities are kilometres. A copper run longer than 100 m is reported down — move the building, or change the cable to fibre.

The real-labs workspace

Open Real labs. If you are not signed in you are sent to the login page; sign in with your email and password. There is no server address to type — the server issues the one your account's plan is entitled to, so a free account lands on the shared machine and a paid one on what its licence buys.

Three devices are on the shelf whether or not anybody has loaded an image, because they are not images. They are Linux itself:

They cost a few hundred kilobytes and start instantly, so a twenty-node lab of them is entirely reasonable. Lab 3 uses nothing else.

Building a lab

When devices stop by themselves

Real devices are real processes on a shared machine, so ZNetLab stops the ones nobody is using. Two separate rules, and knowing which is which saves a support ticket:

You are asked first, and nothing goes quietly. The default is thirty idle minutes. Five minutes before the end you are asked whether you are still working — on screen and on the console itself — and one click, or one keystroke at a console, gives the device its full half hour back. An administrator can change the thirty minutes, or switch automatic stopping off altogether, for this server.

The reason is money as much as memory: nobody should pay for a lab they forgot about on a Friday afternoon, and the memory should go back to whoever is using the server next.

Your lab is never thrown away. Stopping a device is not deleting it: the topology, the names, the cables and each device's startup configuration are all still there. Press Start and you are back. What is lost is anything you typed into a running device and never saved to its configuration — the same thing that is lost when real hardware loses power, and the same cure: write memory.

You can also stop things yourself, which is the polite thing to do on a shared server: Stop on one device, or Stop all for the lab. An administrator can stop a lab too, and when they do it is recorded with their name on it — so if your lab stops and you want to know why, Profile → Activity says which of these it was.

Everything running, whose it is, and how much memory each device is using, is on one screen for administrators: Admin portal → Running now.

Lab 3 · A switched LAN, with no image at all

About 10 minutes, and nothing to license. Three PCs on a switch. It proves your server works end to end — bridges, namespaces, consoles, capture — and it teaches the difference between a switch and a hub in a way no diagram does.

1. Place the devices Drag one LAN Switch and three Virtual PCs onto the canvas.
2. Wire them Link tool → click the switch, then a PC. Repeat for all three. The switch's ports are p1 p2 p3 p4.
3. Start it Press Start lab. Every LED goes green within a second or two — there is nothing to boot.
4. Address the PCs Open each console (select the device → Console) and type:

   PC1  ip 10.10.10.11/24
   PC2  ip 10.10.10.12/24
   PC3  ip 10.10.10.13/24

   Check one with show ip.
5. Look at the switch before any traffic Open SW1's console:

   show mac

   Empty. Nothing has sent a frame, so it has learned nothing. A switch is not configured with addresses — it learns them by watching.
6. Ping, then look again

   on PC1  ping 10.10.10.12

   on SW1  show mac

   Two addresses now, each against the port it arrived on. That is a real kernel bridge FDB — the same table a switch keeps.
7. The lesson worth the whole lab Select the PC3 link → Capture. Now ping PC2 from PC1 again.
   
   PC3 sees the broadcast ARP — because a broadcast goes everywhere — and does not see the ICMP echoes, because by then the switch knows which port PC2 is on and sends them only there. A hub would have shown PC3 everything.
   
   Press Export .pcap and open it in your analyser. Those are real frames from tcpdump on the bridge.
8. Try spanning tree

   on SW1
   stp on
   show spanning-tree

   Ports go through listening and learning before forwarding — about thirty seconds. That delay is why portfast exists on access ports.

Lab 4 · Routing between two LANs, with a real router

About 25 minutes, and one router image. Lab 1 again, but the router is a genuine vendor binary. Any router image works — IOSv, CSR1000v, a Dynamips 7200, VyOS or MikroTik. The topology does not care.

1. Check you have a router Press the images button in the header. If a router is listed as ready, you are set. If not, see Seeing what you can run — you can ask for the one you need from there, and the open-source routers (VyOS, FRRouting, MikroTik CHR) need no licence at all.
2. Build it One router, two LAN Switches, two Virtual PCs:

   PC1 ── SW1 ── R1 ── SW2 ── PC2

   Link the router's first interface to SW1 and its second to SW2.
3. Start the lab, and wait properly Press Start lab. The switches and PCs are green immediately; the router shows starting and takes one to three minutes to boot. That is real boot time, not a delay we added. Open its console and watch — you will see the actual boot messages.
4. Configure the router Once it settles at a prompt:

   enable
   configure terminal
   interface GigabitEthernet0/0
    ip address 192.168.1.1 255.255.255.0
    no shutdown
    exit
   interface GigabitEthernet0/1
    ip address 192.168.2.1 255.255.255.0
    no shutdown
    end
   write memory

   Interface names differ by platform — a CSR1000v uses GigabitEthernet1, a MikroTik uses ether1, VyOS uses eth0. The device's properties panel lists its real names.

5. Address the PCs

   PC1  ip 192.168.1.10/24 192.168.1.1
   PC2  ip 192.168.2.10/24 192.168.2.1

   No static routes this time: each PC's gateway is the router, and the router is directly attached to both LANs, so it already knows both.
6. Prove it

   on PC1  ping 192.168.2.10

   Real ICMP, across a real kernel bridge, through a real router.
7. Capture the difference Capture both links while pinging. On the PC1 side the destination MAC is the router's; on the PC2 side it is PC2's — and the IP addresses are identical in both. The router rewrote layer 2 and left layer 3 alone. Export the pcap and compare the two frames side by side in your analyser.
8. Break it on purpose Select the PC2 link → Shut down. Ping again: it fails. Bring it up: it returns. This is how you practise convergence without rebuilding anything.

Consoles, terminals and capture

Your own terminal

Every running device gets a telnet port on the server. Press External terminal in a console and it prints the exact commands:

putty -telnet lab-server 23004
securecrt /T /N "R1" /TELNET lab-server 23004
telnet lab-server 23004

Both windows share one session — what you type in either appears in both, so you can keep your terminal open beside the browser.

A console in its own window

Press ⧉ in the console's title bar and that device's console opens in a separate browser window — move it, minimise it, maximise it, or put it on a second screen while the topology stays on the first. It is the same session, with the scrollback so far, your theme, Clear, Save log, A−/A+ and Back to the lab. If nothing opens, your browser blocked the window: allow pop-ups for this site and press ⧉ again.

Theme and logs

Theme ▾ in the console sets its colours (classic black, green screen, amber, white (classic terminal), classic grey, Solarized, console blue, paper), the font, the cursor shape and an optional phosphor glow — kept in your browser. Log ▾ saves the session to your computer, copies it, or saves it to your dashboard; the Dashboard's Saved console logs lists them to view, download or delete, from any computer.

Pasting a configuration

Paste a whole block and it is sent line by line, as a terminal would. Plain Ctrl+C is break, not copy — otherwise you could never interrupt a router. Copy and paste are Ctrl+Shift+C and V, the usual terminal bindings.

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.

Select a shape or a note and Delete removes just that one. Escape stops drawing, and lets a selection go.

All of it is saved with the lab and travels with it to the portal, so the person you hand it to sees the diagram you drew and not just the cables. None of it is a device: nothing here can be started, stopped, addressed or cabled.

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 — ask for six interfaces and it fills slots until you have six — but the card decides what the port is, and four serial ports and four Ethernet ports are not the same device to anybody configuring one.

So select a device with card slots and the panel shows them. Choose a card and the interfaces are rebuilt from it:

Slot 0 cannot be changed on the integrated routers — those ports are on the motherboard, and the emulator fits them itself. An empty slot stays empty: taking a card out is something you did on purpose, and nothing will quietly put it back.

Two refusals you may meet, and both are on your side. A slot will not change while a cable is attached to a port it would remove — delete the link first, or you would be left with a link to an interface the chassis no longer has. And a running device keeps its hardware: the new card is fitted the next time it starts, because hardware does not change under a booted IOS.

A saved lab remembers its cards, so reopening it gives you the same chassis — not the same number of interfaces with the wrong kind on them.

Capture — how to start one

A capture reads one cable, the way tcpdump reads one interface. That is the whole idea, and everything else follows from it: you pick a cable, the server runs tcpdump on it, and the frames arrive in the window as they cross.

Four ways in, and they all end in the same capture:

Where there is a choice, every cable is listed in plain words with its state on the right: capture this, capturing · stop, or both ends are off. A cable you cannot capture says why instead of being greyed out in silence — the devices at either end have to be running, because a powered-off cable has no interface on the server to read. Capture all takes every cable that is ready, in one press.

Frames appear live in three panes: the list, the decoded detail, and the bytes. The display filter accepts the syntax you already know — ip.addr == 10.0.0.1 and icmp, tcp.port == 179, !arp. A term it does not understand is reported, never silently ignored, because a filter that quietly drops a clause shows the wrong packets while looking correct.

Finding one packet among thousands

A display filter and a search are not the same question. A filter says show me only these; a search says take me to the next one of these and leave the rest where it is. A capture that has been running for ten minutes needs both.

Searching the list or a packet number runs as you type. Searching the detail or the bytes waits for Enter, because each one dissects the frames it looks at — and it tells you how many it searched rather than quietly searching part of the capture.

Why the list stops moving — and when it should

A live list has to do two contradictory things: show you the newest frame, and hold still while you read an old one. It decides by where you are:

• At the bottom — it follows the newest frame, and the counts along the bottom say · following.
• Anywhere else — it holds your place, however many frames arrive, and says · holding your place — End to follow again. Scrolling back down to the bottom, or pressing End, starts it following again.
• Sorted by a column — it does not follow at all, and says so. The newest frame is not at the bottom of a list sorted by length or by address, so scrolling there would not take you to it. Clicking the heading a third time puts the capture order back.

The same is true of the other four views: each one keeps where you were when it redraws, which it does every time a frame arrives.

Columns — sorting them, and choosing them

Click a heading to sort by it: up, then down, then back to capture order. Sorting applies to the newest 1500 frames the list is showing, in capture order, sorted after — so a sort is a sort of what is on screen and not of something else.

Tools ▾ → Columns… (or right-click any heading) chooses which columns exist. The default seven are No., Time, Source, Destination, Protocol, Length and Info; the rest are there for the day you need them:

Your choice is kept in your own browser, like the pane sizes, so the list you set up is the list you get tomorrow. A column you switch off that was being sorted on takes the sort with it.

Making the window, and its panes, the size you want

The analyser is a panel, and every seam around it and inside it can be moved:

Every seam works the same way throughout ZNetLab: drag to size, double-click to put it back to the design's own size, and arrow keys when it has focus — Shift for bigger steps, Home to reset — so a pane is not something only a mouse can move. Sizes are remembered in your own browser; Tools ▾ → Reset the panes forgets the analyser's three.

Conversations — who is exchanging what, and for how long

The packet list, the layer tree and the flow graph are all answers to “show me the frames”. Conversations answers the question about the pair, which is usually the one you actually have: are these two talking at all, what are they talking, which way is it going, how long has it been going — and when one asks, how long does the other take to answer.

One card per pair of addresses. Where an address appears in a device's startup configuration the card puts the device's name in front of it, so you read R1 10.1.1.1 ⇄ R2 10.1.1.2 rather than two numbers. Click a card and the packet list opens filtered to that conversation and nothing else.

A conversation with a group at one end — a broadcast, or multicast like spanning tree and OSPF hellos — is marked as one and is never called one-way, because one-way is what a multicast is.

Layers 1 to 7, including the two a capture cannot answer for

Under the conversations, one row per layer with what has been seen at it. The dissector reads L2 (Ethernet, 802.1Q, LLC, STP, CDP, LLDP, LACP), the row between 2 and 3 (ARP, MPLS, VXLAN), L3 (IPv4, IPv6, ICMP, ICMPv6, IGMP, GRE), L4 (TCP, UDP) and L7 (OSPF, BGP, EIGRP, VRRP, HSRP, RIP, IS-IS, BFD, DNS, DHCP, Telnet, SSH, HTTP, TLS, Syslog, SNMP, TFTP, NTP).

Layer 1 is not in any capture, and layers 5 and 6 have no headers here. Both rows are drawn anyway, dashed, saying which they are — because asking for “all seven layers” is reasonable and the honest answer beats five layers presented as seven. L1 is gone before tcpdump is handed anything: the kernel passes it whole frames, and the carrier, the voltage and the light are not in them. So that row carries what the cable knows instead — whether it is up, whether somebody shut it down, and what conditioning is applied — and it says that is where the answer came from. L5 and L6, the OSI session and presentation layers, were never implemented as separate protocols in the TCP/IP stack; what sits between the transport and the application in practice is TLS, reported at L7 with the rest.

Protocols — what should be here, and whether it is on time

The packet list answers what crossed. In front of a lab that is not working you have three other questions, and this view is all three:

• Which packets should be here? Out of the devices' own configurations, not out of a guess. A router with router ospf 1 on it will send hellos, and if none are on the wire that is a fact worth stating. A device whose configuration was typed at the console rather than pasted into the startup box has nothing to read, and it says nothing to go on rather than pretending the device should be silent.
• Are they arriving as often as they should? Measured from the capture's own timestamps, and compared with two numbers: the protocol's standard default, and the interval the packets themselves advertise — OSPF, HSRP, STP, BGP and EIGRP all carry their timers in the frame. A verdict always names which number it is comparing, because “OSPF hello is 30 s” means nothing on its own and “arriving every 30.0 s, and the packets say 30 — which is the NBMA default, not the 10 s of a broadcast network” is something you can act on.
• Which of these are the ones that cause trouble? A list of signatures, each meaning one specific thing — an unanswered who has, a TCP reset, an unreachable, a topology change, an adjacency that keeps starting over.

The reference behind it covers 29 protocols — ARP, ICMP, OSPF, EIGRP, RIP, BGP, HSRP, VRRP, GLBP, STP, CDP, LLDP, LACP, VTP, UDLD, PIM, IGMP, BFD, LDP, DHCP, DNS, NTP, SNMP, Syslog, TACACS+, RADIUS, Telnet, TCP and its keepalives — with what each one is for, its documented default timers, where it is expected to come from, and the trouble it is known for. Every default is the protocol's own standard default, which is what makes it useful as a comparison: a measured interval that matches none of them is a timer somebody changed, and that is worth knowing either way.

A protocol that is seen but not expected is not reported as an error. It is reported as “not in any configuration here”, which is the honest shape of that fact — and it is how you catch something that is switched on by default and that nobody meant to leave running.

“My capture is only IPv6” — why, and how to see the rest

Start a capture on a cable you have just drawn, between devices you have just powered on, and the first thing you see is a dozen frames that are all IPv6 — multicast listener reports to ff02::16, router solicitations to ff02::2, a neighbour solicitation nobody asked for. No ARP, no IPv4, nothing you configured.

Nothing is broken. That is what an idle cable carries. Any Linux-based stack gives every interface an IPv6 link-local address the moment the interface comes up, and then announces it — that is MLDv2, the router solicitation and duplicate-address detection, in that order, within about three seconds. A ZNetLab Virtual PC is a real Linux network stack, so it really does send those: they are its own traffic and they belong in your capture, exactly as a real PC's would.

What used to be wrong, and is fixed. The server's own halves of the cable — the bridge, the tap, the veth ZNetLab builds — were doing it too, so half of those frames came from a MAC address belonging to no device on your drawing. The server now keeps its own IPv6 off every interface it makes for a lab. Your devices are untouched: an IPv6 lab still works, and still captures, in full. What stopped is the server joining in.

So the answer to “how do the other protocols work” is that they work the same way — there simply has to be something to carry. A capture shows what crosses the cable, and on a cable where nothing is configured, nothing crosses it. Make some traffic:

The Conversations view checks this for you. At the top of it, under IPv4 and IPv6, it compares what the two devices at the cable's ends are configured for against what has actually crossed, and says which of the two sources disagrees with the other:

Use the quick filters to put the housekeeping aside while you work: ARP, ICMP, OSPF and so on are one click, and typing !icmpv6 in the filter box hides the neighbour discovery and leaves everything else. The filter changes what is shown and never what is captured, so nothing is lost by narrowing it.

Opening it in your own analyser

The analyser in the page is a good one, and it is not the one you have ten years of muscle memory in. The server is already running tcpdump on that link, so Open externally hands you that stream byte for byte — your analyser treats it as a live interface and fills in as frames arrive, rather than opening a file that stopped being true the moment you saved it.

It writes the command for you, with this server’s address, the capture’s id and your own session token already in it:

curl -sN -H "Authorization: Bearer <your token>" \
  https://your-server/api/captures/<id>/stream \
  | wireshark -k -i -

On Windows, run it in PowerShell with curl.exe and "C:\Program Files\Wireshark\Wireshark.exe" -k -i -. There is a tshark line too, for reading it at a terminal. Nothing is re-encoded on the way out: what your analyser reads is what tcpdump wrote.

That command carries your session token, which is as good as your password until you sign out — do not paste it into a chat, a ticket or a screenshot. And a capture belongs to whoever started it: nobody else can read that stream, administrators included. Watching somebody’s traffic is not an administrative task.

Link conditioning

Select a link and set bandwidth, delay, jitter or loss. Applied on the server with tc netem when the lab starts. 120 ms of delay and 5% loss turns a lab into a satellite hop, which is the setup for any QoS or TCP-behaviour lesson.

Operations · NOC — what is broken, and where

The lab screen is for building a network. This one is for watching it. It answers three questions, in this order, and nothing on it is behind a tab: what is broken, where it is, and who got in.

Open it from your name ▾ → Operations · NOC, at /noc/. It reads your own running devices — or, if you are a site administrator, press Whole server for everybody's. It refreshes every five seconds while the tab is in front, and not at all when it is not.

It is laid out as a dashboard, not a list: one filter row, one verdict sentence, then the headline strip — devices up, places, and a count per severity — and under it a grid with what is wrong in the largest panel and where it is beside it. Click a severity in the strip to narrow the whole screen to it. Panels that can run long scroll inside themselves, so the screen stays one screen.

Wherever this screen explains itself, the explanation is a line reading “? why this says that” — open it in place when you want it, leave it closed when you do not. Nothing is hidden behind a hover: the text stays on the page, so your browser's own find still reaches it.

With nothing running you get one panel instead of a dashboard of zeroes: the three first steps, with the button that starts each one. This screen has nothing to watch until something is running, and saying so once beats saying it nine times.

A site is a label you typed

Not a subnet, not a container. A site is the place a device is in — “HQ”, “Branch-2”, “DC-East” — and it is a field on the device, set on the lab screen. Devices with no label are grouped as Unassigned, which is honest about what is known and is also the only nudge to label them.

Label them and the whole screen starts speaking in places instead of in device names. That is the one thing to do before this screen is useful: “Branch-2 is down” is a sentence it can only say if somebody typed Branch-2.

There is deliberately no fourth state and no percentage. “70% up” is not something anybody can act on; the device list underneath says which ones.

Where the alarms are — which place is raising what

One row per place, longest first. The bar's length is that place's open alarms against the busiest place's, so the worst building is the longest bar before you read a number; its segments are the severities inside it, and each segment has a chip on the same row with its count and its severity in words. Beside it, the devices in that place that are raising them.

Click a row and the whole screen below narrows to that place — the alarms, the devices, the AAA servers. Click it again to let it go. The site cards above do the same thing, and the Site menu in the filter row is the same choice as a dropdown.

The alarm list itself is grouped the same way, By location, because that is the order people work in: a fault is dealt with a building at a time. Worst first beside it is the same alarms as one flat list, for when you only want the single worst thing on the network.

The alarms, and what each one means

Every alarm names the thing that raised it and what to do about it. None of them is a number with a threshold bolted on — each one is a state the server already knows it is in, so there is nothing to tune and nothing to calibrate.

Acknowledging an alarm, and clearing it

Every alarm row carries two decisions, and it matters which one you mean:

Each panel heading does the same for a whole place at once — Acknowledge all 6, Clear all 6 — and the row above the list does it for everything currently in view, which is why the button always has the number in it: it can never mean more than you can see. Narrow to one site first and “clear everything” means that site.

Neither one touches a device, and neither one can say a fault is fixed. Every alarm here is worked out from the state the lab is actually in, so if the router is still down the alarm is still raised — clearing it is you deciding not to look at it, which is a different thing and is labelled as one. Both decisions are yours alone: this is your screen, and nobody else's view of their own network changes. And the server forgets a decision once the thing it was about has stopped firing, so the same fault next week raises a fresh alarm instead of arriving pre-cleared. A shelf that never forgets is a way of switching monitoring off by accident, one press at a time.

The graphs, and why each one is the shape it is

Every chart on this screen used to need either a running capture or an alarm with some history behind it — so the commonest state of all, a lab with devices in it and nothing being captured, had no graph on it at all. The lab at a glance fixes that: four views built from what the server knows about every device the moment it is running.

They are four different forms because they answer four different shapes of question, not for variety's sake:

Elsewhere on the screen: a time strip per severity for activity, an area for packets a second, a distribution with its percentiles marked, a proportion bar on every place, ranked bars for processor and memory, and a meter against the limit on each device's CPU in the table. Nine forms, each chosen by its job.

How busy a second is — the shape, not just the line

A line of packets a second answers “is anything crossing”. It does not tell you whether the second on the screen is a typical one — and two labs with the same line can have nothing in common:

So the figures come first and the chart is the shape of them:

The chart below them is a distribution and not a time chart, which is the one way it can be misread — it is the same row of thin bars as the strips higher up the page. Its x axis is packets a second, not time, and each bar counts how many seconds fell in that band, so the tall bar is the rate this cable usually runs at. p50, p95 and p99 are marked on it with their names.

The distribution is drawn over the seconds that carried something, and the silent ones are the figure above instead. On a quiet lab they would be one bar at zero tall enough to flatten everything else, which would hide the only thing the chart is for. When every busy second carried the same number there is no distribution to draw, and the screen says so in a sentence rather than drawing twenty empty bars and one spike — “this is a timer, not traffic”.

Underneath, one line says whether this is bursty or a steady stream, with the ratio it was judged on — a bad second against a typical one — so you can disagree with the threshold instead of guessing what it was. Nothing is claimed from fewer than thirty seconds of samples: a lab that started a moment ago is not evidence about its own shape.

The rest of the screen

Everything under the filter row is scoped by it, so the numbers agree with each other. Last 15m / 1h / 6h / 24h sets the charts' window; Site and Severity narrow everything; and the filters are a view — narrowing a dashboard never changes what is measured.

Which images you can use

Routers, switches and firewalls beyond the three built-in devices are images that an administrator has put on the server — Cisco IOS, IOSv, CSR, ASAv, Nexus, Juniper, Arista, FRRouting, VyOS and so on. They appear on the shelf by themselves once they are loaded. Open your account panel → Real labs → Images available to you to see every image on the server and which your plan can boot.

A real router takes time to start: a Linux-based image is up in seconds, IOSv in about a minute, a CSR or Nexus in several. Its console shows the real boot messages while it does, and its light stays amber until the router reaches a prompt — green means it is ready to type into. Anything in its Startup configuration box is typed in for you as soon as it is ready.

Seeing what you can run, before you pay

A plan says how many devices in one lab may need a vendor image. What it cannot say is which ones — that depends on what this server has been given. So choosing a plan opens a window first, and it has two halves.

• On this server — every platform this server holds an image for, by name and vendor, plus the three that need no image at all. Search it. Nothing about licences, file names or sizes is in there: that is the administrator's screen, not yours.
• Ask for an image — every platform ZNetLab recognises that this server has not got. Pick the ones you need, say which release, say what it is for, and tell us about your licence in your own words.

Asking carries a small one-time charge, shown before you agree to it and worked out from the number of images you picked. It is a charge for the work — sourcing what you are licensed to run, checking it boots and filing it under the right platform — and not for the software. ZNetLab supplies no vendor software and cannot license any to you: whether you may run it is between you and the vendor, and we cannot check that for you. What we record is what you tell us, with your name and the date against it. The figure is recalculated every time you change the selection, and your agreement to the old one is cleared with it, so you are never submitting a yes to a number that has moved.

There is no card form, here or anywhere in ZNetLab — on purpose. Your request raises an order, and the window tells you how it is settled on this server. An administrator picks the request up, and the platforms appear on your shelf when they are here.

If you need a lab bigger than the price list — past twenty image devices, or several people each with their own lab — the same window opens with the calculator's numbers in it. That one is a conversation: nothing is charged until the figure is agreed with you.

You can still simply ask your administrator, of course. The window exists because an email is not a queue.