physical nodes

When defining new node types, you can also specify the machine type. The default machine type is netns (for a Linux network namespace), and other options are xen and physical. (The xen machine type is only available on the Xen code branch -- more about that in a later post.) The physical machine type allows you to incorporate physical testbed machines into your emulated network.

There is a new default node type with a green icon named prouter, or physical router. You can define other node types that are physical nodes. When you link to a physical node, a GRE interface will be built on the real machine for that link, to tunnel data to/from the emulated network. Services will be started and stopped as defined in the service list. Double-clicking a physical node opens an SSH shell to that node.

Physical nodes must be assigned to a server just like emulation servers in a distributed session. The physical node should be running the cored.py daemon. The difference between a physical node and a distributed emulation server is that no virtual namespaces are created; processes run directly on the physical node without virtualization.

XORP routing services

XORP routing services were added to the development version of CORE (SVN snapshot) on 10/24/11. These services provide an alternative to Quagga routing, and include multicast routing support with PIM SM.

Similar to Quagga's zebra service, a unified configuration (/etc/xorp/config.boot) is written by the xorp_rtrmgr (router manager) service. This means that once you have enabled XORP protocols, use the customize button next to the xorp_rtrmgr service to edit the config file.

The default router node type still uses Quagga's OSPF, but you can create your own node types that use XORP protocols as default.

check emulation light (CEL)

A new feedback system has been added to CORE (SVN): the Check Emulation Light (CEL). A small yellow indicator appears in the bottom right corner of the screen when problems arise. In the screenshot below, for example, the OSPFv3 service reports a problem that the ospf6d daemon is not running.

A dialog listing the problem items (exceptions) will pop up when you click the yellow CEL icon. The CEL will blink for fatal errors, such as the failure to spawn a new network namespace or failure to launch EMANE processes. The affected node is also highlighted so it is easy to find.

Node services have a new field named validation commands. These commands (if any) are invoked following the service startup commands to verify that the service has correctly started. The validation commands for existing services are currently defined with something like `pidof ospfd`, to check that a daemon is actually running. A non-zero return code from a validation command causes a CEL exception to be thrown.

The motivation for the CEL is to be more informative about underlying emulation problems. With previous versions of CORE, something may have gone terribly wrong, but the GUI continued happily along with no indication of issues. We're also cooking up some performance monitoring scripts that monitor the CPU, memory, and throughput used by nodes; future plans are to tie in performance alarms with this exception system.

improved customization of services 2

As a follow-up to the new tabbed dialog described previously, the service list for each node now has yellow customize buttons for services that require customization. The BGP service must be customized, for example, as BGP requires fine-tuning peering relationships and AS numbers.

yargh, hooks

One of the goals of the CORE project is hackability. In that spirit, you can now define hooks under the experiment menu. Hooks are optional shell scripts that run at the specified session state. (If you previously used the global experiment script, this is the same thing; the experiment script now becomes a runtime hook.) The hook script runs on the host as root, is not associated with any particular node, and is saved in the imn file.

 Below the hook configuration dialog is shown. You select the session state from a drop-down menu.

Here are the session states and their meanings:

1. Definition - used by the GUI to tell the backend to clear any state.
2. Configuration - when the user presses the Start button, node, link, and other configuration data is sent to the backend.
3. Instantiation - after configuration data has been sent, just before the nodes are created.
4. Runtime - all nodes and networks have been built and are running.
5. Datacollect - the user has pressed the Stop button; a good time to collect log files before nodes are shut down.
6. Shutdown - all nodes and networks have been shut down and destroyed.

Another related feature that has been added is a /tmp/pycore.nnnnn/state file. As a session changes states, it will write the current state number and name into this file. This would enable an external program or script to monitor that file.

CORE 4.2 released

A new 4.2 release of CORE is available. To obtain the software, please visit:
http://cs.itd.nrl.navy.mil/work/core/
http://downloads.pf.itd.nrl.navy.mil/core/packages/4.2/

Quickstart installation instructions are here:
http://code.google.com/p/coreemu/wiki/Quickstart

Here are some of the high-level changes since version 4.1:

• EMANE 0.7.1 support
  support for Bypass model, Universal PHY, logging, realtime
• configurable MAC addresses
• control interfaces (backchannel between node and host)
• service customization dialog improved (tabbed)
• new testing scripts for MDR and EMANE performance testing
• improved upgrading of old imn files
• new coresendmsg.py utility (deprecates libcoreapi and coreapisend)
• new security services, custom service becomes UserDefined
• new services and Python scripting chapters in manual
• fixes to distributed emulation, linking tunnels/RJ45s with WLANs/hubs/switches
• fixed the following bugs:
  18, 32, 34, 38, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49,  52, 53, 55, 57, 58, 60, 62, 64, 65, 66, 68, 71, 72, 74

These release notes along with a list of known issues are posted here:
http://code.google.com/p/coreemu/wiki/ReleaseNotes

customize service tabbed dialog

The customize service dialog was limited in the past, only allowing configuration of the first config/script file. This dialog has been revamped with a new tabbed dialog, using Ttk (Tcl/Tk 8.5 now required).

To add a new config/script file, you would enter the new name into the combo box and press the new button.

Below the Directories and Startup/Shutdown tabs are shown.