How to Run Network Labs on Linux (Without Any Emulator)

Running network labs usually starts with installing tools. EVE-NG. GNS3. Virtual machines. That’s where most people begin. This post starts somewhere else. By looking at what Linux already gives us, we built routers, switches, and PCs directly from the terminal. Origami is the result of that process.

Most network labs start the same way.

You install something.

EVE-NG.

GNS3.

One or more large virtual machines.

Before you touch the CLI, you are already fixing installs, rebuilding images, and troubleshooting things that have nothing to do with networking.

That is normal.

That is how most people learn.

Earlier this year, that pattern started bothering me.

Not because the tools are bad.

But because of what happens before the learning even begins.

What if the problem is not the lab itself?

What if it is the layers we add before we start?

Last month, when a new teammate joined our team, that question turned into a small experiment.

This time, we did not ask which tool to use.

We asked a simpler question.

Do we actually need one?

Because underneath all of this, Linux already knows how to do networking.

We just rarely touch those parts directly.

A few weeks later, we had something real in front of us.

We called it Origami.

Starting from what Linux already gives you

At first, the idea feels strange.

But Linux has quietly had everything required to build network labs for years.

Most emulation platforms are simply wrapping the same building blocks.

Network namespaces to create isolated nodes.

veth pairs to act as links.

Bridge interfaces for switching.

Routing stacks like FRRouting.

And when a real network operating system is needed, QEMU.

Instead of hiding these layers, we decided to work with them directly.

No GUI.

No abstraction.

Just the terminal.

Where everything actually begins. Interfaces

In Linux, networking always starts with an interface.

Physical or virtual, it does not matter.

If there is an interface, there can be traffic.

We started by creating TAP interfaces.

Virtual Ethernet ports that behave like real ones.

sudo ip tuntap add dev router-eth0 mode tap
sudo ip tuntap add dev switch-eth0 mode tap
sudo ip tuntap add dev switch-eth1 mode tap
sudo ip tuntap add dev switch-eth2 mode tap

sudo ip link set router-eth0 up
sudo ip link set switch-eth0 up
sudo ip link set switch-eth1 up
sudo ip link set switch-eth2 up

With a few commands, we had four virtual ports ready.

In the physical world, this is the moment you take Ethernet cables out of the box and place them on the table.

Bringing the router and switch to life

For the router and switch, we used QEMU.

Not as a heavy emulation platform.

Just as a way to boot lightweight Cisco IOSv images.

sudo -b qemu-system-x86_64 \
  -enable-kvm \
  -nographic \
  -m 512 \
  -drive file=/tmp/router-overlay.qcow2,format=qcow2,if=virtio \
  -netdev tap,id=gig0,ifname=router-eth0,script=no,downscript=no \
  -device e1000,netdev=gig0,mac=0C:00:CA:7E:0C:00

Everything runs in the background.

A simple telnet session connects you to the console.

telnet 127.0.0.1 5000

A few minutes later, Router> appeared on the screen.

That moment felt familiar.

The router was running.

No emulator in sight.

We repeated the same process for the switch.

sudo -b qemu-system-x86_64 \
  -enable-kvm \
  -nographic \
  -m 768 \
  -drive file=/tmp/switch-overlay.qcow2,format=qcow2,if=virtio \
  -netdev tap,id=gig0,ifname=switch-eth0,script=no,downscript=no \
  -device e1000,netdev=gig0,mac=0C:00:C0:11:AA:00

Now we had two devices running.

They just needed to be connected.

The invisible cable. Linux bridges

In real hardware, you plug in a cable.

In Linux, you create a bridge.

sudo ip link add br-rtr-sw type bridge
sudo ip link set br-rtr-sw up
sudo ip link set router-eth0 master br-rtr-sw
sudo ip link set switch-eth0 master br-rtr-sw

At that moment, traffic started flowing between the two virtual machines.

Exactly like a physical link.

Creating PCs without virtual machines

This is where things get interesting.

Instead of spinning up more VMs, we created two network namespaces.

sudo ip netns add Admin-PC
sudo ip netns add User-PC

Each namespace has its own routing table, interfaces, and firewall rules.

From a networking perspective, they behave like separate systems.

We connected them using veth pairs.

sudo ip link add AdminPC-veth0 type veth peer name AdminPC-veth1
sudo ip link set AdminPC-veth0 netns Admin-PC
sudo ip link set AdminPC-veth1 master br-AdminPC-sw
sudo ip link set AdminPC-veth1 up

Two lightweight PCs.

No operating system install.

No extra memory usage.

Just Linux doing what it already knows how to do.

The moment that matters. Ping

Once everything was up, it was time.

sudo ip netns exec Admin-PC ping -c 5 10.1.20.2

The first packets went through.

It felt like watching a link light turn green on a switch.

We had built a complete network.

No emulator.

Just Linux.

Cleaning up matters

Tearing everything down took seconds.

sudo pkill -f 'qemu-system-x86_64'
sudo ip netns delete Admin-PC
sudo ip netns delete User-PC
sudo ip link delete router-eth0
sudo ip link delete switch-eth0
sudo ip link delete switch-eth1
sudo ip link delete switch-eth2
sudo ip link delete br-rtr-sw

In under ten seconds, the system was clean.

No leftovers.

No hidden state.

What Origami really is

Origami is not a tool.

It is a way of thinking.

Instead of stacking heavy platforms on top of each other, we start from first principles.

We use what the operating system already provides.

We build each piece deliberately.

Simple parts.

Precise connections.

A real system emerges.

Next, this structure will evolve into a web based, multi user environment.

A place where anyone can run network labs without installing anything.

Until then, if you are running Linux, try it yourself.

Open a terminal.

Type the commands.

Watch a network come alive.

If you want to reproduce this setup step by step, the full guide is available on GitHub:

https://github.com/dynamips/origami

The repository includes detailed instructions to rebuild the lab and experiment with the building blocks on your own system.

If you have questions, ideas, or improvements, feel free to leave a comment or open an issue.

1 response

Leave a Reply

Your email address will not be published. Required fields are marked *