# CORE: a research emulator for wired and wireless networks

> CORE is the Common Open Research Emulator, a tool for emulating networks on one or more machines and connecting them to live networks, combining a topology drawing GUI with Python modules for scripted emulation. It is a research instrument from Boeing, distributed under a BSD 2 clause licence, and it needs privileged network namespaces to do its work.

**coreemu/core** — Common Open Research Emulator

- Repository: https://github.com/coreemu/core
- Stars: 841 · Forks: 191
- Language: Python
- License: BSD-2-Clause
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/coreemu-core

## What CORE emulates and who uses it

The Common Open Research Emulator is a tool for emulating networks on one or more machines, and those emulated networks can be connected to live networks. The README describes the project as two halves: a GUI for drawing topologies of lightweight virtual machines, and Python modules for scripting network emulation.

The split matters. A topology drawn by hand in a GUI is a picture of a network, while a scripted emulation is a program that builds, mutates and tears down a network as part of an experiment. CORE is built for the second, and the GUI exists so that a human can design the starting point and watch what the script does to it.

The copyright line in the README reads "Copyright (c)2005-2025 the Boeing Company", which tells you both the origin and the audience. This is a research tool built inside a company laboratory and published for academic and testing use. The topic tags confirm the domain: emane for the wireless emulation side, network emulation, RF, wireless, Python.

The licence is BSD-2-Clause, and the README points at the LICENSE file included in the distribution. A permissive licence with no copyleft obligation, which suits a tool that companies are expected to build on.

One structural detail is worth noting for anyone who has met the project before: the repository contains daemon/, netns/, package/, dockerfiles/, docs/, man/, tasks.py, setup.sh, bootstrap.sh and configure.ac. The configure script and autotools files show that the code also builds through a traditional Unix packaging route, not only through the Python installer.

## The GUI, the Python modules and the shared emulator

Because CORE is a research instrument, the two halves have to agree about what is running. The GUI is not a picture of a network, it is a control surface for a set of running processes.

The components visible in the repository layout describe that machinery. The daemon/ directory holds the background processes, netns/ holds the network namespace handling, and the presence of vnoded and vcmd in the installation description names the two privileged helpers. Those are the parts that create network namespaces, set up virtual interfaces and let a process attach to a node's interfaces, and they need elevated privileges to do it.

That privilege requirement is the defining operational constraint of the project and it shapes everything else. CORE is not something you run inside an unprivileged container without additional work, and it is not something you install on a shared machine without thinking about what the daemon can do.

The Python modules are the scripting side. A script can drive the same topology the GUI draws, which is what makes a repeatable experiment possible: the topology is defined in code, the same code runs on another machine, and the result is the same starting condition every time. The docs/ directory and the mkdocs.yml at the root indicate the documentation is built with MkDocs and published at coreemu.github.io/core, with the Discord channel as the support channel.

The emane tag deserves a specific mention because it is not a detail. EMANE is the wireless emulation framework CORE integrates with, and it is what lets a scenario model radio behaviour rather than only wired links.

## Installing from a package

The package route is the fastest path to a working install, and the README describes it in two steps.

The latest deb or rpm is taken from the releases page.

```shell
sudo <yum/apt> install -y ./<package>
```

That single command installs vnoded and vcmd, the system dependencies, and CORE itself within a Python virtual environment at `/opt/core/venv`. The virtual environment location is a useful detail, because it tells you where to look for the interpreter when a script fails to find CORE, and it also means the install does not pollute the system Python.

The requirement is Python 3.9 or later, and the README points to the install page in the documentation for more detailed instructions and other options.

The package does not include the routing daemon. The README's next step is to install OSPF MDR from source, and that is the part of the setup with the most moving pieces.

## Building OSPF MDR and the script install path

OSPF MDR is the routing daemon CORE drives, and the README gives a full source build for it.

```shell
git clone https://github.com/USNavalResearchLaboratory/ospf-mdr.git
cd ospf-mdr
./bootstrap.sh
./configure --disable-doc --enable-user=root --enable-group=root \
  --with-cflags=-ggdb --sysconfdir=/usr/local/etc/quagga --enable-vtysh \
  --localstatedir=/var/run/quagga
make -j$(nproc)
sudo make install
```

The configure flags are worth reading rather than copying blindly. The daemon is configured to run as root, its configuration lives under `/usr/local/etc/quagga`, and the vtysh shell is enabled. The `--localstatedir=/var/run/quagga` setting points the runtime state somewhere other than the default, which matters when a daemon is expected to be started and stopped repeatedly inside a scripted experiment.

The script install path is the alternative, and the README says it should get you running on Ubuntu 22.04.

```shell
git clone https://github.com/coreemu/core.git
cd core
./setup.sh
source ~/.bashrc
inv install
```

The setup script installs the dependencies needed to run the installation task, and the last step is an `inv install` call, with `inv install -p /usr` given as the CentOS variant. The `inv` prefix is the Invoke task runner, and tasks.py at the root of the repository is what it runs, so the install steps are ordinary Python tasks rather than a hidden shell script.

The distinction between the two paths is where CORE ends up. The script path puts CORE into a Python 3 virtual environment; the package path puts it in `/opt/core/venv` along with the privileged helpers.

## Where CORE is the wrong tool

The first limitation is privilege. vnoded and vcmd are installed as privileged helpers, and the OSPF MDR build is configured to run as root. CORE creates real network namespaces on the host, so it wants a machine it can own, and it is not a good fit for a shared server or a locked down workstation.

The second is the operational weight of the OSPF MDR dependency. A package install that appears complete still leaves you building a routing daemon from source, with autotools, a Quagga style configuration directory and a vtysh shell to manage. For an experiment that needs a routed network this is fair, but for one that only needs a flat segment it is a lot of setup for a feature you will not use.

The third is the boundary between emulation and reality. The README states the emulated networks can be connected to live networks, which is the capability researchers want and also the risk. A script that accidentally routes traffic into a live network is a problem the project does not appear to guard against, so the care has to be in the script.

The fourth is the release gap. The recent releases are CORE 9.2.1 from 2025-05-19, 9.2.0 from 2025-02-12 and 9.1.0 from 2024-07-04. The last push was on 2026-06-02, so the source is being worked on, but the tagged releases are more than a year behind the tip, and the documentation is published separately from the code.

The fifth is the learning curve of the domain itself. CORE does not hide that emulating wireless networks with EMANE is a specialised skill, and the README points to a Discord channel for support rather than shipping a self-contained tutorial.

## CORE compared with GNS3, Mininet and ns-3

GNS3 is the closest competitor in terms of audience, and the difference in approach is that GNS3 is built around appliances and virtual machines, while CORE is built around lightweight virtual machines and namespaces it manages itself.

GNS3 nodes can be heavier guests, and that flexibility is the point; it is also the cost, because the emulator is orchestrating a collection of real software. CORE takes the opposite approach with its lightweight virtual machines, which means the nodes are namespaces rather than guests, the footprint per node is small, and a topology with many nodes stays cheap. What you give up is the ability to run vendor software inside a node.

Mininet is the other comparison and it is a closer one. Mininet also creates network namespaces and also makes topology creation scriptable, and it is the usual first thing anyone tries. The difference is that Mininet is a general network namespace toolkit with a scriptable API, while CORE adds the layers a research experiment needs on top: a GUI for topology design, an emulation service, the EMANE integration for wireless, and a routing daemon in the picture.

ns-3 is a discrete event simulator rather than a network emulator. The distinction is fundamental and it decides the choice. ns-3 models protocol behaviour in simulation with a network stack that is not the kernel's, which gives control and repeatability but no real packets on a real interface. CORE creates real namespaces and real interfaces, so a protocol under test is the one running on the machine, and the result can be captured with tcpdump on a real link. If the question is how a protocol behaves under a specific topology, CORE answers it with the real stack; if the question is about throughput or delay behaviour under a load model, ns-3 is the instrument that was built for it.

## Licence, maintenance and the practical upgrade path

The licence field on the repository records BSD-2-Clause, and the README asks readers to see the LICENSE file included in the distribution. A two clause BSD licence permits commercial use, modification and redistribution with only the conditions of retaining the copyright notice and the licence text, and it carries no requirement to publish changes back. For a tool that a company might want to extend internally, that is the right licence.

The project is not archived and the last push was on 2026-06-02, so work is landing on the master branch. The CHANGELOG.md at the root is the place to look for what changed between the tagged releases, and the release tags follow the release-9.2.1 pattern.

The upgrade path in practice is not a package manager update. Both install routes put CORE into a virtual environment, one built by the Invoke tasks in tasks.py and one at `/opt/core/venv` created by the deb or rpm, so upgrading means rebuilding that environment and reinstalling the privileged helpers. OSPF MDR is separate again and has to be rebuilt from source.

The documentation lives at coreemu.github.io/core, built with MkDocs from the docs/ directory and the mkdocs.yml at the root, and the man/ directory suggests some of it is also available as manual pages. Support is via the Discord channel rather than a tracker, which suits a research community but leaves the answer to a specific problem in a chat log rather than in the documentation.

## Conclusion

CORE suits a networking researcher or test engineer who needs repeatable, scripted network conditions rather than a single topology, especially when the experiment involves wireless link behaviour, emulation nodes and a routing daemon such as OSPF MDR. It is the wrong tool for production traffic work, for a quick lab of a handful of virtual machines with no scriptable control, and for anyone without root on the host, since the installation steps install vnoded and vcmd and put CORE in a virtual environment at /opt/core/venv. Before running an experiment, read the install page in the project documentation for the option that matches your distribution, and confirm OSPF MDR builds on your kernel, because the README still requires building it from source.

## FAQ

### What is CORE the Common Open Research Emulator used for?

It is a tool for emulating networks on one or more machines, and those emulated networks can be connected to live networks. It combines a GUI for drawing topologies of lightweight virtual machines with Python modules for scripting network emulation.

### How do I install CORE on Linux?

Take the latest deb or rpm from the releases page and install it with `sudo <yum/apt> install -y ./<package>`, which installs vnoded, vcmd, the system dependencies and CORE inside a Python virtual environment at /opt/core/venv. The script install path clones the repository, runs ./setup.sh and then `inv install`.

### Does CORE need OSPF MDR installed?

The README's package install step is followed by installing OSPF MDR from source, using ./bootstrap.sh, ./configure with root user and group, make and sudo make install. The routing daemon is a separate build from the USNavalResearchLaboratory/ospf-mdr repository.

### What are the system requirements for running CORE?

Python 3.9 or later, and privileges sufficient to run the vnoded and vcmd helpers and the root-configured OSPF MDR daemon, since CORE creates network namespaces on the host. The README points to the install page in the documentation for more detailed options.

### How is CORE different from GNS3 or Mininet?

GNS3 runs appliances and full virtual machines as nodes, while CORE manages lightweight virtual machines and network namespaces itself, including a GUI, an emulation service and EMANE integration for wireless. Mininet also works with namespaces but is a general toolkit rather than a research emulator with those layers.

### What licence is CORE released under?

BSD-2-Clause, and the README asks readers to see the LICENSE file included in the distribution.

## Sources

- [coreemu/core on GitHub](https://github.com/coreemu/core)
- [Issues](https://github.com/coreemu/core/issues)
- [License: BSD-2-Clause](https://github.com/coreemu/core/blob/master/LICENSE)
- [README](https://github.com/coreemu/core/blob/master/README.md)
- [Releases](https://github.com/coreemu/core/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/coreemu-core