Vrnetlab, or VR Network Lab, is an open-source network emulator that runs virtual routers using KVM and Docker. Software developers and network engineers use vrnetlab, along with continuous-integration processes, for testing network provisioning changes in a virtual network. Researchers and engineers may also use the vrnetlab command line interface to create and modify network emulation labs in an interactive way. In this post, I review vrnetlab’s main features and show how to use it to create a simple network emulation scenario using open-source routers.
In this post, I demonstrate how to create a network emulation scenario using Libvirt, the Qemu/KVM hypervisor, and Linux bridges to create and manage interconnected virtual machines on a host system. As I do so, I will share what I have learned about network virtualization on a Linux system.
Libvirt provides a command-line interface that hides the low-level virtualization and networking details, enabling one to easily create and manage virtual networking scenarios. It is already used as a basis for some existing network emulators, and other applications and tools. It is available in almost every Linux distribution.
Are you like me? Are you a network engineer, or other professional, transitioning their skill set to include programming and automation? Does your programming experience experience come from a few programming courses you attended in college a long time ago? Then please read on because I created this Python guide for people like you and me.
In this guide, I explain the absolute minimum amount you need to learn about Python required to create useful programs. Follow this guide to get a very short, but functional, overview of Python programming in less than one hour.
When you begin using Python, there are a lot of topics you do not need to know so I omit them from this guide. However, I don’t want you to have to unlearn misconceptions later, when you become more experienced, so I include some Python concepts that other beginner guides might skip, such as the Python object model. This guide is “simple” but it is also “correct”.
Microsoft Azure unofficially supports nested virtualization using KVM on Linux virtual machines, which makes it possible to build network emulation scenarios in the cloud using the same technologies you would use if you were using your own PC or a local server.
In this post, I will show you how to set up a Linux virtual machine in Microsoft Azure and then create a nested virtual machine inside the Azure virtual machine. This is a simple example, but you may use the same procedure as a starting point to create more complex network emulation scenarios using nested virtualization.
Many open-source network simulation and emulation tools use full virtualization technologies like VMware, QEMU/KVM, or VirtualBox. These technologies require hardware support for virtualization such as Intel’s VT-x and AMD’s AMD-V. To gain direct access to this hardware support, researchers usually run network emulation test beds on their own PCs or servers but could not take advantage of the inexpensive and flexible computing services offered by cloud providers like Amazon EC2, Google Compute Engine, or Microsoft Azure.
By August 2017, most of the major cloud service providers announced support for nested virtualization. In the cloud context, Nested Virtualization is an advanced feature aimed at enterprises, but it is also very useful for building network emulation test beds. I’ve written about nested virtualization for servers before but, until recently, I was limited to running nested virtual machines on my own PC. Now that the major cloud providers support nested virtualization, I can build more complex network emulation scenarios using cloud servers.
This post will discuss the cloud service providers that support nested virtualization and how this feature supports open source networking simulation and emulation in the cloud.
Google Cloud Platform introduced nested virtualization support in September 2017. Nested virtualization is especially interesting to network emulation research since it allow users to run unmodified versions of popular network emulation tools like GNS3, EVE-NG, and Cloonix on a cloud instance.
Google Cloud supports nested virtualization using the KVM hypervisor on Linux instances. It does not support other hypervisors like VMware ESX or Xen, and it does not support nested virtualization for Windows instances.
In this post, I show how I set up nested virtualization in Google Cloud and I test the performance of nested virtual machines running on a Google Cloud VM instance.
This tutorial shows how to set up the Cloonix network emulator on a Packet.net server. It builds on top of my previous post about how to set up a virtualization server on Packet.net. Now, I focus on a specific case: setting up the Cloonix network emulator on the virtualization server. You should read my previous post before reading this one.
Running Cloonix on a remote server enables users to work with more complex network emulation scenarios than would be possible on a standard laptop computer. For example. Cloonix recently added a feature which allows users to run Cisco router images in a Cloonix network emulation scenario. Cisco router images require a large amount of computer resources so I cannot run more than a few on my personal laptop computer. If I use a remote Packet server, I could run dozens of Cisco images in a network emulation scenario if I wanted to.
In this post, I will set up a Cloonix network emulation server on Packet.net so it can be started, stopped, and restarted relatively quickly.
Packet is a hardware-as-a-service vendor that provides dedicated servers on demand at very low cost. For me and my readers, Packet offers a solution to the problem of using cloud services to run complex network emulation scenarios that require hardware-level support for virtualization. Packet users may access powerful servers that empower them to perform activities they could not run on a normal personal computer.
In this post, I will describe the procedure to set up an on-demand bare metal server and to create and maintain persistent data storage for applications. I will describe a generic procedure that can be applied to any application and that works for users who access Packet services from a laptop computer running any of the common operating systems: Windows, Mac, and Linux. In a future post, I will describe how I run network emulation scenarios on a Packet server.
To install the CORE network emulator in recently released Linux distributions, including Ubuntu 16.04 and later, I recommend that you install it from the CORE Github source code repository.
The Debian and Ubuntu maintainers will remove CORE packages from their repositories in the near future so we cannot install CORE using a package manager, anymore. We also cannot use the packages available on the CORE web site until a new version of CORE is released, because newer Linux distributions may break some of the functionality in the version of CORE packages available there. For example, CORE fails to start Quagga routing daemons in newer Linux distributions. The issue is fixed in the latest version of the CORE source code available on Github.
The CORE source code is in two places: on the CORE web site, and on Github. It’s not completely clear which source code repository we should use to build CORE from. I asked the CORE team about this and it seems that both are valid, but are not kept 100% in sync with each other. Since a recent fix I needed was on the CORE Github repository, but not in the CORE web site nightly snapshots source code folder, I will use the CORE GitHub repository.
In this post, I provide a detailed procedure to install CORE from the source code on Github, and to set up your system to run network experiments using the CORE network emulator.
I attended the Netdev 2.1 Conference in Montreal from April 6 to 8. Netdev is a community-driven conference mainly for Linux networking developers and developers whose applications rely on code in the Linux kernel networking subsystem. It focuses very tightly on Linux kernel networking and on how packets are handled through the Linux kernel as they pass between network interfaces and applications running in user space.
In this post, I write about the three-day conference and I offer some commentary on the talks and workshops I attended. I grouped my comments in categories based on my interpretation of each talk’s primary topic. The actual order in which these topics were presented is available in the Netdev 2.1 schedule. The slides from the talks, workshops, and keynotes are posted under each session on the Netdev web site. Videos of the talks are available on the netdevconf Youtube channel.
The UNetLab and EVE-NG network emulators can become powerful tools for emulating open-source networks. However, When first installed, they support Linux images only in a limited way. Fortunately, it is easy to extend UNetLab and EVE-NG to support powerful, general-purpose Linux router and server images.
In their default configuration, UNetLab and EVE-NG support Linux nodes running boot-able live CD disk images that offer a graphical user interface accessible via VNC. This is not suitable for emulating Linux routers or servers.
To fix this limitation, we will show you how to build a Linux router image for EVE-NG that boots from a virtual hard disk, can be accessed via Telnet to simplify configuration and management, and that has a persistent file system onto which we can install software and modify configuration files.
EVE-NG and UNetLab are graphical network emulators that support both commercial and open-source router images. UNetLab is the current, stable version of the network emulator and EVE-NG is an updated version of the same tool, available as an alpha release. The UNetLab/EVE-NG network emulator runs in a virtual machine so it can be set up Windows, Mac OS, or Linux computers. Its graphical user interface runs in a web browser.
Since it runs in a virtual machine, EVE-NG may be set up on any operating system such as Windows, Linux, or Mac OS. When using the EVE-NG virtual machine on a Linux computer, I had to resolve a few problems related to the way VMware Player works in Linux. In this post, I focus only on the specific issues related to getting EVE-NG working on a Linux system. I’ll also show the basic steps to creating and running a simple lab consisting of emulated Linux nodes. The procedure is the same for UNetLab.