Network emulation vs simulation: what's the difference

A network simulator models devices and links in software and computes what would happen. A network emulator runs the real software, or something that behaves like the real thing, and lets real packets flow. This page explains the difference with concrete tools, shows a two-line example, and helps you pick the right one for what you want to learn.

Definitions

Simulation builds a model. Devices, protocols and links are code written to behave like the real ones. The simulator decides what happens, often in simulated time that runs faster or slower than the clock on the wall. You learn from what the model shows you.

Emulation reproduces the real thing closely enough that real software can't tell the difference. A router image boots its real operating system. A Linux container runs a real kernel network stack. Packets are real bytes, in real time, and you can capture them with tcpdump.

A short way to remember it:

• A simulator answers "what would happen if...".
• An emulator lets it happen, on a smaller scale.

The same question, two answers

Say you want to know how a file transfer behaves over a link with 50 ms of delay.

In a simulator such as ns-3, you describe two nodes, a link with 50 ms delay and a TCP application, then run the model. The output is a trace or statistics computed by the simulator's TCP model.

In an emulator, you add the delay to a real interface and run a real program. Here is the whole test with tc netem in a container:

docker run --rm --cap-add NET_ADMIN nicolaka/netshoot sh -c \
  "tc qdisc add dev lo root netem delay 50ms; ping -c 3 127.0.0.1"

64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=101 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=101 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=101 ms

The round trip is about 100 ms because the request and the reply each cross the delayed loopback interface. Without netem, the same ping took 0.04 ms. Nothing here is a model: the kernel held each real packet for 50 ms. Any program you run, from curl to a video call, would feel the same delay. The netem man page lists the other effects it can add, and our tc netem tutorial builds a full lab with them.

Side by side

Examples of each

Simulators

• ns-3 describes itself as "a discrete-event network simulator, targeted primarily for research and educational use". Researchers use it to study protocols at scales that would be costly to build.
• Cisco Packet Tracer is, in Cisco's own words, "a networking simulation and visualization tool". It is free for Networking Academy learners and runs on a laptop. Cisco notes it does not reproduce every feature or behavior of physical equipment. Its devices accept IOS-style commands, but they are models of Cisco gear, not IOS itself.

Emulators

• GNS3, EVE-NG and Cisco CML run real router, switch and firewall images in VMs or containers. Our GNS3 alternatives post compares them.
• Containerlab and Kathará build labs from containers running real network software such as FRR.
• Mininet creates "a realistic virtual network, running real kernel, switch and application code" on one machine, mostly for SDN work.
• tc netem emulates link conditions: delay, jitter, loss, duplication, reordering and rate limits.

The gray zone

The line is not always sharp:

• Dynamips, used by GNS3 for older Cisco routers, emulates the router's hardware so the real IOS image can boot. The software is real, the hardware is emulated.
• ns-3 has a real-time scheduler for "simulation-in-the-loop" setups, where simulated parts exchange packets with real systems.
• Docker networks are real Linux bridges and veth pairs. A container lab is closer to a small real network than to an emulation of one.

What each one is good for

Pick a simulator when:

• You want to understand a concept, such as how a switch fills its MAC table, step by step.
• You need very large topologies that would never fit in RAM as real devices.
• You do research and need exact, repeatable runs.
• You study for an exam that is built around a specific simulator, such as Packet Tracer activities in Cisco courses.

Pick an emulator when:

• You want to type real commands on real software and see real output, including bugs.
• You test a config change before you push it to production.
• You need packet captures, real applications or automation tools talking to devices.
• You want to see how real apps behave on a slow or lossy link.

Many people use both. A simulator teaches the idea quickly, and an emulator proves it on the software you will meet at work. Our Packet Tracer vs GNS3 comparison goes deeper on that choice for Cisco study.

Common mistakes

• Treating simulator output as proof. A simulator shows what its model does. If the model skips a feature, the result skips it too.
• Expecting an emulator to be exact about timing. Emulated devices share one CPU. Throughput and convergence times in a lab won't match hardware.
• Calling every lab tool a simulator. In search results and forums, "network simulator" often means any lab tool. When you compare tools, check whether they run real images.

Where Isothrum fits

Isothrum's editor is on the emulation side. It is a free browser editor, with no account, for drawing a network lab of containers, Linux and Windows VMs, switches with VLANs and trunks, and routers such as FRR or Cisco images you supply. You can set latency, jitter, loss and bandwidth per cable or LAN. It exports Docker Compose, Vagrant, Proxmox, Kubernetes and cloud files, and you run the real software with those tools.