Install GNS3 Network Simulator on Debian 13/12

Debian has no GNS3 package. The PPA in the GNS3 documentation is built for Ubuntu, and Debian lacks ubridge entirely. Its only dynamips is an old 0.2.14 in non-free, and its VPCS is too old for GNS3 3.0 to start. So you install the GNS3 server from PyPI with pipx and build the three helpers from source.

Original content from computingforgeeks.com - post 27218

This guide installs GNS3 3.0 on Debian 13 as a server, runs it under systemd bound to localhost, opens the built-in web UI through an SSH tunnel, and builds a two-PC lab that pings across a switch. It also covers the problems the official steps miss. We ran it twice on Debian 13.7 with GNS3 3.0.6 in October 2026, the second time top to bottom on a fresh VM, and replayed the install and build steps in a Debian 12 container.

Choose how to install GNS3 on Debian

The GNS3 Linux documentation lists one method for Debian: pipx install gns3-server, plus the emulators from apt or source. We’d follow it. pipx puts the server in its own virtual environment under your home directory, so it never fights Debian’s Python packages, and upgrading is one command. The alternatives are worse fits:

• the ppa:gns3/ppa packages
• pip install into a hand-made venv
• the remote-install.sh script

None of them suits a Debian server: the PPA targets Ubuntu releases only, a hand-made venv is pipx with more steps, and the docs describe the remote install script for a fresh Ubuntu server dedicated to GNS3. If your lab host runs Ubuntu instead, the PPA is the easier route, and our GNS3 on Ubuntu guide follows it.

GNS3 3.0 makes the web UI on port 3080 the default way to work and puts it behind a login, so a headless Debian box needs no desktop at all; you reach it from a browser on your laptop. The Qt desktop client (gns3-gui) still exists for people who run GNS3 on a Debian desktop, and the install command for it is below. A third option skips the native install entirely: the prebuilt GNS3 VM appliance, which we cover in running the GNS3 VM on KVM. Our lab VM was headless, so every screenshot in this guide shows the web UI. Here’s where each piece came from on our two test systems:

Component	Debian 13	Debian 12	Version we ran
GNS3 server	pipx (PyPI)	pipx (PyPI)	3.0.6
Dynamips	built from source (Debian has 0.2.14 in non-free)	built from source (Debian has 0.2.14 in non-free)	0.2.25
uBridge	built from source (no Debian package)	built from source, pinned to 1.2.3	1.3.1 on 13, 1.2.3 on 12
VPCS	built from source (Debian ships 0.5b2)	built from source (Debian ships 0.5b2)	0.8.5
QEMU/KVM	apt	apt	10.0.13 on 13

The Debian 12 column comes from a container replay that ran the install and build steps and started the server, as root, with no systemd, no KVM and no web UI. It also installed a subset of the apt packages, so treat Debian 12 as covered for the build path, not for a running lab. Everything else in this guide ran on Debian 13 VMs.

What the GNS3 server needs

GNS3 itself is light. The server process peaked at 176 MB of RAM on our VM right after its first start. What decides the host size is the images you run inside it, so size the box for your biggest lab, not for GNS3:

• Debian 13 or 12, 64-bit
• Intel VT-x or AMD-V enabled
• RAM for your images, per node
• 20 GB of free disk to start
• sudo access and SSH

Virtualization support matters because QEMU images like Cisco IOSv require KVM. The RAM line is the one to plan around: the appliance files bundled with GNS3 give IOSv 512 MB, IOSvL2 768 MB and CSR1000v 3 GB per node, and disk grows with every image you import. Disk is the easiest to grow later, so do not overbuy it on day one.

Our test VM had 4 vCPUs and 6 GB of RAM with nested virtualization, which is a floor for following along, not a lab recommendation. Ten IOSv routers alone take 5 GB, so that VM could not run even a mid-sized Cisco lab. If you’re building a dedicated box for labs, our roundup of the best mini PCs for GNS3 and EVE-NG picks four boxes sized mainly by RAM, with core count second.

Check that KVM is available

QEMU images run without hardware acceleration, but so slowly that IOSv will not boot in a sensible time, and the IOSv appliance refuses to start without KVM. Check before installing anything else. Refresh the package lists, then install cpu-checker, which provides kvm-ok.

sudo apt update
sudo apt install -y cpu-checker
sudo kvm-ok

You want both lines below. On a VM, a missing /dev/kvm means the hypervisor is not passing virtualization through (on Proxmox, set the VM’s CPU type to host); on bare metal, it means VT-x or AMD-V is off in the firmware. Fix this before going further, because every later QEMU step depends on it.

INFO: /dev/kvm exists
KVM acceleration can be used

Next, confirm which driver is loaded, kvm_intel on our Intel host:

ls -l /dev/kvm; lsmod | grep ^kvm

/dev/kvm belongs to the kvm group, which is why your user joins that group later. If the group on your system differs, use that group name in the usermod step instead.

crw-rw---- 1 root kvm 10, 232 Oct 24 06:23 /dev/kvm
kvm_intel             413696  0
kvm                  1376256  1 kvm_intel

Both modules loaded means QEMU can use hardware acceleration, so the QEMU nodes you add later run at close to native speed.

Install the dependencies

Start with the Debian 13 package list from the GNS3 documentation, unchanged. It installs pipx, QEMU with KVM support, libvirt and the PyQt6 libraries the desktop client needs. On a server with no desktop you can leave out the three python3-pyqt6 packages, though we installed them as listed.

sudo apt install -y python3 python3-pip pipx python3-pyqt6 python3-pyqt6.qtwebsockets python3-pyqt6.qtsvg qemu-kvm qemu-utils libvirt-clients libvirt-daemon-system virtinst ca-certificates curl gnupg2

qemu-kvm is a virtual package on Debian 13, and apt resolves it to qemu-system-x86 without asking. The documentation stops there, but building the three helpers needs a compiler, CMake, two libraries and git, which a minimal Debian 13 image does not ship. Our first clone failed with bash: line 1: git: command not found. The line below also adds vim, because stock minimal Debian only has vim-tiny and later steps edit files with vim.

sudo apt install -y git build-essential cmake libelf-dev libpcap0.8-dev libcap2-bin vim

None of these packages starts a service, so they are safe to add on a machine that already runs other workloads. You can remove the compilers after the builds if the host is short on disk.

Install the GNS3 server with pipx

Install the server as your normal user, not with sudo. pipx keeps it under ~/.local, which is also why the systemd unit later runs as that user. With sudo, it would land under root’s home, where the service cannot find it.

pipx install gns3-server

pipx reports the version and the two commands it linked into ~/.local/bin. Note the version, because the same number appears in the web UI and in every API response.

  installed package gns3-server 3.0.6, installed using Python 3.13.5
  These apps are now globally available
    - gns3server
    - gns3vmnet

Add ~/.local/bin to your PATH so you can run gns3server by name in new shells. The systemd unit later uses the full path, so it works even before you log in again. pipx edits your shell profile for you, and the change applies after you log out and back in.

pipx ensurepath

If you also want the Qt desktop client on a Debian desktop, the documentation adds two more commands. The inject step puts the server and PyQt6 into the client’s environment, so the client can start a local server itself. We installed the client in our first run but did not launch it, because the VM had no display.

pipx install gns3-gui
pipx inject gns3-gui gns3-server PyQt6

Everything after this point only needs the server, so skip the client on a headless box because it pulls in Qt libraries you will never use.

Build Dynamips, uBridge and VPCS from source

GNS3 drives three helper programs. Dynamips emulates the classic Cisco routers and, less obviously, runs the built-in Ethernet switch node, so even a lab with no Cisco images needs it. uBridge connects the nodes’ virtual cables. VPCS provides the lightweight virtual PCs used for ping tests. The GNS3 docs only show a dynamips build, cloned from its development branch; here each helper is built from its latest GitHub release tag instead, so you get a version the GNS3 team actually released.

Dynamips

Debian’s own dynamips is 0.2.14 from the non-free section, and the version matters for security as well as features. gns3-server 3.0.6 only pins the Dynamips hypervisor to 127.0.0.1 when dynamips is 0.2.23 or newer. With an older build, it binds to whatever address the server listens on, which only exposes it when host is 0.0.0.0 or a LAN address (our journal shows the 0.2.25 build started with -H 127.0.0.1:55269 --console-binding-addr 127.0.0.1; see the dynamips manager in the gns3-server source and the Debian package list). Detect the latest release tag, then clone exactly that tag.

DYNAMIPS_VER=$(curl -s https://api.github.com/repos/GNS3/dynamips/releases/latest | grep tag_name | cut -d '"' -f 4)
echo "${DYNAMIPS_VER}"
git clone --depth 1 --branch "${DYNAMIPS_VER}" https://github.com/GNS3/dynamips.git

The echo prints the tag about to be built, so an empty value shows up before the clone. Ours was the current release.

v0.2.25

Build it with CMake, and ignore the deprecation warnings CMake prints, which are harmless:

cd dynamips && mkdir build && cd build && cmake .. && make -j"$(nproc)"

Install it with sudo, because it writes under /usr/local. The GNS3 documentation shows a plain make install, which fails for a normal user with a CMake Error at cmake_install.cmake.

sudo make install
cd ~

Run dynamips with no arguments to confirm the installed version. It complains about the missing image, which proves the binary runs without needing an IOS image.

dynamips 2>&1 | head -3

The first line is only the complaint about the image. Look for the version on the second line:

Please specify an IOS image filename
Cisco Router Simulation Platform (version 0.2.25-amd64/Linux stable)
Copyright (c) 2005-2011 Christophe Fillot.

If the shell cannot find dynamips, check that /usr/local/bin is in your PATH, because that is where the build installs it.

uBridge

On Debian 13 the latest uBridge release builds cleanly, so the same detect-and-clone pattern works:

UBRIDGE_VER=$(curl -s https://api.github.com/repos/GNS3/ubridge/releases/latest | grep tag_name | cut -d '"' -f 4)
git clone --depth 1 --branch "${UBRIDGE_VER}" https://github.com/GNS3/ubridge.git
cd ubridge && make -j"$(nproc)" && sudo make install
cd ~

On Debian 12 the 1.3.x releases fail to compile, because Debian 12’s kernel headers lack a netem constant they use (the exact error is in the troubleshooting section). Use 1.2.3 there instead, which built in our Debian 12 test.

UBRIDGE_VER="v1.2.3" # pin: 1.3.x fails to build against Debian 12 kernel headers https://github.com/GNS3/ubridge/releases
git clone --depth 1 --branch "${UBRIDGE_VER}" https://github.com/GNS3/ubridge.git
cd ubridge && make -j"$(nproc)" && sudo make install
cd ~

The install step grants uBridge the network capabilities it needs to run without root, but it copies the binary with cp -p, so on our fresh VM /usr/local/bin/ubridge ended up owned by our user with mode 775. Any process running as that user could then replace a binary in the system PATH. Hand it to root and reapply the capabilities last, because changing the owner clears them:

sudo chown root:root /usr/local/bin/ubridge && sudo chmod 755 /usr/local/bin/ubridge && sudo setcap cap_bpf,cap_net_admin,cap_net_raw=ep /usr/local/bin/ubridge

Then confirm the version, the owner and the capabilities. All three matter, because a capability-less or user-owned binary is exactly what the previous step fixes:

ubridge -v; ls -l /usr/local/bin/ubridge; /usr/sbin/getcap /usr/local/bin/ubridge

On Debian 13 all three lines should match ours. On Debian 12 only the version line differs (1.2.3), because the setcap above also adds cap_bpf, which 1.2.3’s own install step leaves out:

ubridge version 1.3.1
-rwxr-xr-x 1 root root 269664 Oct 24 06:37 /usr/local/bin/ubridge
/usr/local/bin/ubridge cap_net_admin,cap_net_raw,cap_bpf=ep

If getcap prints nothing, rerun the setcap command, because a later chown or copy clears file capabilities.

VPCS

Don’t install the vpcs package from Debian. It’s version 0.5b2, and GNS3 3.0 refuses to start a VPCS node with it (we hit that error, shown in the troubleshooting section). Build the current release instead:

VPCS_VER=$(curl -s https://api.github.com/repos/GNS3/vpcs/releases/latest | grep tag_name | cut -d '"' -f 4)
git clone --depth 1 --branch "${VPCS_VER}" https://github.com/GNS3/vpcs.git
cd vpcs && make -j"$(nproc)" && sudo make install
cd ~

Check which VPCS the shell finds. The build installs to /usr/local/bin, root-owned this time, and that directory comes before /usr/bin in the PATH:

command -v vpcs; vpcs -v | grep version; ls -l /usr/local/bin/vpcs

A /usr/bin/vpcs path here means the build did not install, so rerun sudo make install in the vpcs directory. Debian’s own package can sit behind it unnoticed, so dpkg -s vpcs tells you whether to remove it with sudo apt remove -y vpcs. Ours pointed at the build:

/usr/local/bin/vpcs
Welcome to Virtual PC Simulator, version 0.8.5
-rwxr-xr-x 1 root root 174904 Oct 24 06:39 /usr/local/bin/vpcs

All three helpers are in place. Compare your versions with ours if a node later refuses to start, because a version mismatch caused our only startup failure. The terminal capture below is from our first run and shows the helpers with the server and QEMU versions:

With the helpers in place, the server can start every node type this guide uses, so the remaining steps are configuration rather than installation.

Add your user to the kvm and libvirt groups

The GNS3 server runs as your user, so that user needs access to /dev/kvm, and the GNS3 documentation also asks for the libvirt group. Membership in libvirt lets a user control libvirtd, which is close to root access on the host, so add it only if you trust everyone who can log in as that user. The kvm group is what QEMU nodes need. Add both groups:

sudo usermod -aG kvm,libvirt "${USER}" && id "${USER}"

The groups list should now end with kvm and libvirt. The numeric IDs differ between systems, so only the names matter:

uid=1000(josphat) gid=1000(josphat) groups=1000(josphat),4(adm),20(dialout),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev),992(kvm),105(libvirt)

Group changes apply to new logins, so log out and back in before testing QEMU nodes from your shell. The systemd service started below picks them up on its own.

Configure the server and run it with systemd

Without a configuration file, GNS3 3.0 starts with built-in defaults, and two of them matter. The default listen address in the 3.0.6 source is 0.0.0.0, every interface on the host. The server also never creates its JWT signing key file, so it signs web UI login tokens with a key that ships in the source. Our test start without a config logged exactly that:

2026-10-24 06:34:30 WARNING config.py:250 No configuration file could be found or read
2026-10-24 06:34:42 ERROR authentication.py:58 A JWT secret key must be configured to secure the server, using an unsecured default key!

A config file fixes both. Create the directory and open the file:

mkdir -p ~/.config/GNS3/3.0 && vim ~/.config/GNS3/3.0/gns3_server.conf

Bind the server to localhost on its default port. Three lines are all the file needs, because every other setting keeps its default:

[Server]
host = 127.0.0.1
port = 3080

Binding to 127.0.0.1 means nothing on the network can reach the API or the web UI directly; you will use an SSH tunnel instead. If you would rather expose it on your LAN, set host to the server’s LAN address and open TCP 3080 in your firewall. Remember that node consoles are plain telnet, so anyone on that LAN could reach them too.

Next, the systemd unit. It runs the pipx-installed binary as your user. Open a new unit file:

sudo vim /etc/systemd/system/gns3-server.service

Paste the unit. GNS3_USER_HERE is a placeholder that the next command replaces with your username, which keeps the file identical for every reader:

[Unit]
Description=GNS3 server
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=GNS3_USER_HERE
Group=GNS3_USER_HERE
ExecStart=/home/GNS3_USER_HERE/.local/bin/gns3server
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

Substitute your username, then check the three lines it changed. A wrong path in this file is the most common reason the service fails to start, so read the output before moving on:

sudo sed -i "s/GNS3_USER_HERE/${USER}/g" /etc/systemd/system/gns3-server.service
grep -E "User|Group|ExecStart" /etc/systemd/system/gns3-server.service

Our lab user was josphat, and yours shows your own username in all three places:

User=josphat
Group=josphat
ExecStart=/home/josphat/.local/bin/gns3server

Start the server and enable it at boot, so it comes back after a reboot and your projects are available without logging in to the host:

sudo systemctl daemon-reload && sudo systemctl enable --now gns3-server

Give it a few seconds, then confirm the config file loaded and the JWT key was generated, because these three journal lines are the healthy result:

sudo journalctl -u gns3-server --since "-30s" --no-pager | grep -E "Configuration file|JWT|Starting server"

The server read the file, created gns3_jwt_secret_key next to it, and bound to 127.0.0.1:

Oct 24 06:40:33 gns3-01 gns3server[29592]: 2026-10-24 06:40:33 INFO gns3server.config:255 Configuration file '/home/josphat/.config/GNS3/3.0/gns3_server.conf' loaded
Oct 24 06:40:33 gns3-01 gns3server[29592]: 2026-10-24 06:40:33 INFO gns3server.config:215 No JWT secret key configured, generating one in '/home/josphat/.config/GNS3/3.0/gns3_jwt_secret_key'...
Oct 24 06:40:34 gns3-01 gns3server[29592]: 2026-10-24 06:40:34 INFO gns3server.server:288 Starting server on 127.0.0.1:3080

The key file was created world-readable on both of our VMs, and the controller database next to it, which holds the user password hashes, was too. Anyone who can read the key can forge a login token, so close the whole directory to other users and the key file on top:

chmod 700 ~/.config/GNS3 && chmod 600 ~/.config/GNS3/3.0/gns3_jwt_secret_key && ls -ld ~/.config/GNS3 ~/.config/GNS3/3.0/gns3_jwt_secret_key

Only the owner can read either now. The server kept working after a restart, because it runs as the same user that owns the files:

drwx------ 3 josphat josphat 4096 Oct 24 06:34 /home/josphat/.config/GNS3
-rw------- 1 josphat josphat   64 Oct 24 06:40 /home/josphat/.config/GNS3/3.0/gns3_jwt_secret_key

Finally, check the listener. Port 3080 should be bound to 127.0.0.1 only, which is the check that tells you the server is not exposed to the network:

ss -tlnp | grep 3080

A 0.0.0.0:3080 here means the config file wasn’t read, usually because it sits in the wrong directory:

LISTEN 0      2048       127.0.0.1:3080      0.0.0.0:*    users:(("gns3server",pid=29592,fd=7))

At this point the server is ready, and the rest of the setup happens in a browser on your workstation. Nothing else needs to run on the server, so you can close your SSH session there.

Open the GNS3 web UI over an SSH tunnel

The web UI is served by the same process on port 3080, so all you need is a tunnel from your workstation. Run this on your laptop, replacing the user and address with your server’s:

ssh -fN -o ExitOnForwardFailure=yes -L 3080:127.0.0.1:3080 [email protected]

Then browse to http://127.0.0.1:3080/. The server redirects to the web UI’s login page. The first load pulls a 4.3 MB JavaScript bundle, which took 54.6 seconds over our remote tunnel; the browser caches it after that, and on a LAN it takes a few seconds:

GNS3 3.0 creates one account on first start: user admin with password admin. Change it first, because anyone who reaches port 3080 can otherwise control the server. Open the menu (the three dots at the top right), choose User info, then Change password:

A banner confirms User admin password updated. In our first run the old password then failed at the API with HTTP 401, so the change takes effect immediately.

Build a first lab with two VPCS hosts

A switch and two virtual PCs are enough to prove that the whole chain works: Dynamips runs the switch, VPCS runs the PCs, and uBridge wires them together. No Cisco images are involved, so you can run this test straight after the install. On the Projects page, click Add blank project and give it a name:

An empty canvas opens, and the toolbar across the top holds everything you need. Build the topology in this order, so each link has both ends ready when you draw it:

1. Click the + (Add a node) icon.
2. Drag VPCS onto the canvas twice.
3. Drag Ethernet switch onto the canvas once.
4. Click Add a link, then PC1, Ethernet0.
5. Click Switch1, then Ethernet0.
6. Repeat for PC2 to Switch1 on Ethernet1.

GNS3 names the nodes PC1, PC2 and Switch1 on its own. The red dots on the PCs’ link ends mean those nodes are still stopped, while the switch side is green because a built-in switch starts as soon as it is created.

Click the green play button (Start/Resume all nodes) and confirm. Every dot turns green, and the topology summary on the right lists each PC’s console as telnet://127.0.0.1:5000 and 5002. If a node stays red, its error appears at the bottom of the canvas and in the server journal, so check those before retrying.

Right-click PC2 and choose Web console. Give it an address and save it, so the address survives a restart of the node:

ip 10.10.10.2/24
save

Open PC1’s web console the same way, set its address, save, and send four pings to PC2. VPCS sends five by default, which is why the count is set:

ip 10.10.10.1/24
save
ping 10.10.10.2 -c 4

Four replies with a TTL of 64 mean the frames crossed the switch with no router in between:

The saved addresses live in each node’s startup.vpc, so they come back when you restart the nodes. Our replay on the fresh VM sent the same commands and got four replies again, with times between 0.153 and 0.206 ms.

Keep the lab running after you close the browser

New projects close themselves when the last browser tab disconnects, and closing a project stops every node. In both of our runs the project closed shortly after the last browser disconnected, and the server journal records each close:

sudo journalctl -u gns3-server --no-pager | grep -iE "automatically closing" | tail -3

Each line marks a close that stopped every node in the project. The project ID in the message is the one in the web UI’s address bar:

Oct 24 06:53:28 gns3-01 gns3server[29710]: 2026-10-24 06:53:28 INFO root:313 Project 'b2de9e8b-2209-49d5-b179-fcf1dadeec71' is automatically closing due to no client listening
Oct 24 07:01:59 gns3-01 gns3server[29710]: 2026-10-24 07:01:59 INFO root:313 Project 'b2de9e8b-2209-49d5-b179-fcf1dadeec71' is automatically closing due to no client listening

To keep a long-running lab up without a browser attached, change the project setting. With the project open, click the GNS3 logo at the top left, choose Project settings, then Edit project. Tick Leave this project running in the background after closing and click Apply:

The UI confirms with Project first-lab updated., and the API then reported auto_close as False. We closed the browser, and two minutes later the project was still open with PC1, PC2 and Switch1 started, with no close in the journal.

Leaving the default on has a benefit too: an idle lab stops holding RAM the moment nobody is using it.

Troubleshoot GNS3 on Debian

These errors came up during our installs, and each fix was confirmed by repeating the step that failed. The error text is quoted exactly, so you can match it against your own log.

VPCS executable version must be >= 0.6.1 but not a 0.8

Starting a VPCS node with Debian’s own vpcs package failed in the web UI and in the server log. The node stayed red, and nothing else in the topology was affected:

Oct 20 11:52:48 gns3-01 gns3server[27195]: 2026-10-20 11:52:48 ERROR gns3server.api.routes.compute:133 Compute node error: VPCS executable version must be >= 0.6.1 but not a 0.8

vpcs -v printed version 0.5b2. The message reads as if 0.8 were unsupported, but the check in the GNS3 3.0.6 source only rejects versions older than 0.6.1, and our 0.8.5 build started without complaint. Remove the Debian package and build VPCS from source as shown above.

A JWT secret key must be configured to secure the server

The server logs this when it runs with no gns3_server.conf, as shown in the configuration section. Nothing breaks visibly, which is why it is easy to miss, but the login tokens are only as secret as a key that ships with the software. The server only generates its key file while loading a configuration file, so create ~/.config/GNS3/3.0/gns3_server.conf and restart the service. In our first run the count of these messages after the restart was 0. Expect to log in to the web UI again afterwards, because tokens signed with the old key stop working.

error: ‘TCA_NETEM_PRNG_SEED’ undeclared on Debian 12

uBridge 1.3.0 and 1.3.1 stop compiling on Debian 12. The build fails before producing a binary, so nothing gets installed:

src/hypervisor_tc.c:338:29: error: 'TCA_NETEM_PRNG_SEED' undeclared (first use in this function); did you mean 'TCA_NETEM_UNSPEC'?

The constant comes from the kernel headers in Debian’s linux-libc-dev package, and Debian 12’s are too old for it. Version 1.2.3 built cleanly in our Debian 12 test, so check out the v1.2.3 tag there, as in the uBridge section. Debian 13’s headers have the constant, so 1.3.1 builds as is.

Size the host before you add Cisco images

A VPCS lab barely registers on a server, but real labs grow fast, so plan the host around the images you intend to run. The appliance definitions bundled with GNS3 3.0.6 set these RAM values per node, and the QEMU-based ones require KVM:

Appliance	RAM per node	Needs KVM
Cisco 7200 (Dynamips)	512 MB	No
Cisco IOSv	512 MB	Yes
Cisco IOSvL2	768 MB	Yes
Cisco CSR1000v	3072 MB	Yes

A CCNA-sized lab of six IOSv routers and four IOSvL2 switches needs 6 GB for the nodes alone. Add the host’s own needs and the GNS3 server’s 176 MB, and you’re at roughly 7 GB before you open a browser, more than our 6 GB test VM had. GNS3 does not include any Cisco images. You need your own licensed images, for example from a Cisco Modeling Labs subscription, and you import them through the appliance templates. Once your images are in place, the CCNA lab exercises give you practice topologies to build. And if you would rather learn routing protocols first without any images, the Linux lab in our IP routing and routing protocols guide runs OSPF and BGP between network namespaces on a single Debian VM.