CORE Network Emulator Services overview

CORE Services is a feature of the CORE Network Emulator — an open-source network simulator — that configures and starts processes on each node running in a network simulation. Examples of processes supported by CORE Services are: quagga, dhcpd, or radvd.

Because the CORE Network Emulator implements its virtual nodes using a lightweight virtualization technology called Linux namespaces, we cannot use the normal init or upstart scripts to start networking daemons on these nodes. We must use CORE Services.

A benefit of using CORE Services is that they allow us to set up and manage processes running on each node by using the CORE GUI. This may reduce the time required to configure nodes used in a simulation scenario, especially if a large number of nodes require similar configuration procedures. Also, network scenarios that require customized configurations can be saved and used again if those configurations are implemented by customizing CORE Services.

To run complex network simulation scenarios, we must understand how to use CORE Services. In this post we will provide an overview of CORE Services.

Overview

CORE Services are used to start processes on the virtual nodes in a CORE network simulation. For the processes that are configured in each CORE service, the service defines the directories and configuration files that will be created on the virtual node so the process can run.

Each node type, such as a router or a PC node, has a set of CORE services already configured by default. More services may be selected. Services may be customized.

The CORE User Manual, Section 3.6 provides information about CORE Services.

CORE Services Configuration

Let’s investigate how CORE Services are set up by looking at the default configurations of CORE services, using the quagga set of services as an example.

First, set up a small network simulation scenario on the CORE Network Emulator. In this example, we will use the first three L3 node types: router, PC, and host, and connect them together as shown below. To see the CORE Services window, right-click on the router node and select Services… from the drop-down menu.

We see that the zebra, OSPFv2, OSPFv3, vtysh, and IPForward services are all set by default. Services are enabled or disabled by clicking on their names in the CORE Services window.

The “tools” button next to each service name allows the user to customize this service for this node. Click on the tools icon to see the customization options for this service.

The service configuration window has three tabs: Files, Directories, and Startup/shutdown.

The Files tab

In the service configuration window’s Files tab, shown below, we see that the zebra service will use a configuration file stored at the location shown in the Filename field. If multiple configuration files are needed, they can be selected from a drop-down list. The contents of each file are generated by the CORE Network Emulator and shown in the window.

The contents of the zebra configuration file are generated by the CORE Network Emulator and are based on the network configuration and the other service selected, such as OSPFv2. The user may customize this service by modifying the configuration file content, or selecting another configuration file.

The Directories tab

Next, click on the Directories tab. Here we see the directories that the service will create (as mount namespaces) on the virtual node.

The zebra service will use these directories to save configuration files and log files on the virtual node. The CORE Network Emulator creates these directories when the network simulation scenario is started.

The user may customize the service by adding other directories.

The CORE Network Emulator uses a lightweight virtualization technology called Linux namespaces to implement virtual nodes and, if no CORE Services are selected, does not set up an independent filesystem for each virtual node. Each CORE Service defines its own per-node directories and configuration files which the CORE Network Emulator will create when it starts the virtual node. So, we must use CORE Services to set up processes that manipulate files, such as log files or configuration files.

The Startup/shutdown tab

CORE Services also define startup, validation, and shutdown commands so the user can stop or restart the service while the virtual node is running in a simulation. Click on the Startup/shutdown tab to see options available for the startup, validation, and shutdown commands.

We see options for a “Startup index”, a “Start time”, and for the startup, shutdown, and validation scripts. The startup index sets the startup priority for a service compared to other services and helps the node determine which scripts to run first while the virtual node is starting up. Alternatively, the user may configure a start time for the startup script. The startup command is executed when the node starts up. The Shutdown and Validation commands are triggered if the user selects then in the CORE GUI while the simulation is running.

The service may be customized by modifying the commands or creating new commands.

Core Services Operation

Core Services on each node will start when the network simulation is started. Once the node is running, services work in the normal way and can be operated using the standard terminal commands associated with each service.

We cannot add or remove CORE services from a node while it is running in a simulation. However, we can manipulate the state of configured CORE Services using the startup or shutdown commands for each service. ((Note that, once a service is started using a CORE Service, it may also be possible to stop it and start it using standard Linux commands and scripts executed on the virtual node’s terminal.)) One may also verify whether a service is still running using the validate command.

After a CORE Network simulation is started, we can stop, validate, or re-start services on a node by right-clicking on a node and selecting the following contextual menu:

Services → service-name → start|stop|restart|validate

For example: to stop the zebra service on the router node in this example, we right-click on the router node and select the following command from the drop-down menu:

Services → zebra → stop   

Customizing CORE Services

Each CORE Service can be customized. For example, specific configurations can be added to the zebra config file in the zebra service. Or, the startup and shutdown commands can be modified (or added, if they do not exist in the default configuration). The CORE Documentation provides instructions to customize CORE Services.

If a service has been customized, the tool icon next to it will be colored green. If we select a service that must be customized — that is, the service needs some manual configuration to operate properly — the tool icon next to the selected service will be colored yellow.

The UserDefined service is a blank service where any aspect may be customized. We can use the UserDefined service to start and manage processes on a node that are not defined in any of the default services.

We’ll discuss customizing services in a future post.

New CORE Services

It is possible to add multiple new services beyond what is already defined in the CORE Network Emulator by creating new CORE Services. This requires modifying the Python files that run the CORE Network Emulator. The CORE Documentation provides instructions to add new CORE Services.

Creating new CORE Services makes the new services available to all nodes in a simulation. We can effectively create a new service by customizing the UserDefined service on each node, but we have to repeat that customization on every node in the simulation. However, customizing the UserDefined service is a good way to test a new service before creating it as a permanent new service by modifying Python files.

We’ll discuss adding new services in a future post.

Other posts that discuss CORE Services

We have already demonstrated configuring CORE Services in some of our previous posts. If you are new to using the CORE Network Emulator, we suggest you read through the following posts:

• CORE Network Emulator Test Drive : provides a general overview of the CORE Network Emulator’s functionality.
• Installing CORE Network Emulator Services: describes how to install software on the host computer that will be run by CORE Services.
• Testing IPv6 addressing in a network simulator – Part 1: Shows an example of selecting (or de-selecting) services on a node.
• Testing IPv6 addressing in a network simulator – Part 2: Shows and example of configuring services, verifying their configuration, and modifying a services configuration files.

Linux Namespaces

CORE uses Linux namespaces virtualization technology to create the “virtual machines” that emulate each node in the network simulation. Namespaces support the implementation of lightweight virtualization that provides a group of processes with the illusion that they are the only processes on the system. ((From http://lwn.net/Articles/531114/)) For example, CORE creates a unique network namespace for each node by default, so each node has its own networking functions, routing tables, and network addresses.

CORE nodes are not full-fledged virtual machines ((See the CORE Network Emulator mailing list archives, post#525 and post#1188)). To make each virtual node running in a network simulation scenario very lightweight, the CORE Network Emulator uses namespaces to create only the minimum necessary resources for each node. CORE creates an isolated network stack for each virtual node and, depending on which CORE Services are configured, it also mounts isolated copies of specific files or directories in the filesystem for each virtual node.

For this reason, we cannot just start up a virtual node in a network simulation and then manually start networking software on that virtual node. We must ensure that the directories required by the software are created when the node is started. This, and other required configurations, are performed by CORE Services.

More information about namespaces is available at linuxcontainers.org, the Ubuntu server guide, and lwn.net.

Conclusion

We reviewed the basic functionality provided by CORE Services and also explained why we must use them to manage processes on nodes running in the CORE Network Emulator.