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.

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.

improved customization of services

Node services in CORE have been a relatively new feature, and we're working on improving ways to customize your services. The Customize... button has now been replaced with a little edit icon next to each service. You click the edit button to customize that service.

The color of this button can indicate several things:

• Gray (default): the service config will be auto-generated
• Green: this service has been customized for this node
• Yellow (future): this is a service that requires customization

We've added some new security services that you can see on the right column. For some services there isn't a great way to auto-generate a complete config. The VPN client for example, must be configured with the server it should connect with, among other things. We'll be adding a new property to services that allows a service to flag that it requires customization. Then in the service list (shown above) the edit button will be colored yellow.

EMANE 0.7.1 supported

If you build CORE from source using the nightly SVN snapshot, you can now use EMANE 0.7.1 for more detailed wireless networking. The previous version 0.6.4 is no longer supported. The full list of changes in EMANE 0.7.1 is available here, but if you use EMANE with CORE here are some highlights:

• Location now works with IEEE 802.11abg. Thanks to the new Universal PHY, the 802.11 model now handles location events; if you drag nodes around the canvas, location events are generated and alter node connectivity.
• Rebuild your imn scenarios. Any custom EMANE parameters from your old scenarios need to be removed and re-entered; you can do this by editing the imn file and removing the "custom-config { }" block within the WLAN node definition.

node types and services

Previously the CORE GUI generated router configs for the router node type. This was mostly limited to Quagga OSPFv2 and OSPFv3, without an easy way to customize processes. Now the configuration has been pushed to the CORE services layer (cored.py) and is more exposed to the user.

Node types:
Users may now customize node types. The default types are router, host, PC, and mdr. Clicking the edit button at the end of the submenu allows the user to define new node types or change existing ones.
In the above screenshot, a new node type "supernode" has been defined, and assigned a custom icon. This new node type will appear in the toolbar. Next, a default set of services that will be started with that node type can be selected.
Services: Services can be assigned to a node or node type. When you place a node, it will automatically have the default services configured for that node type. A service can be a routing protocol, server daemon, or even simply a script that runs after the node is started. A service can also auto-generate its config file(s) based on node properties such as name, interfaces, and addresses.

The above screenshot shows the default services that will be started for the custom type "supernode." The below screenshot shows how services can later be customized for each individual node.

Notice the Customize button, available when selecting services for a certain node. This button has been pressed to invoke the custom services dialog. (This dialog may be improved in the future.) Each service defines its own:

• per-node directories
  
• config files
  
• startup index
• startup/shutdown commands

All of the services are defined in Python files (see core/python/core/services/*.py). All of the above attributes may be customized for each node. Future plans are to allow the user to easily define their own service types using Python extensions (probably ~/.core/services/*.py).

Because all of the services are defined in CORE Python daemon, Python scripts (without GUI) will be able to take advantage of auto-generated configs. The bad news is that router configs are no longer saved in the imn scenario files, unless you customize the config files of a service; effectively the imn file format has changed.

Configs moved from /etc/core to $HOME/core

A new change in the development version of CORE (svn snapshot) is that the CORE GUI will now use a $HOME/.core directory for configuration that it writes.

• the default scenario dir for imn files is now ~/.core/configs/
• existing ~/.core preferences file is moved to ~/.core/prefs.conf
• plugins.conf, servers.conf, and widgets.conf now live in ~/.core/
• the read-only /etc/core/core.conf file still exists, for configuring the daemon (cored.py)

This fixes bug #25 (http://code.google.com/p/coreemu/issues/detail?id=25)

disconnected GUI

The notion of Sessions were added to the CORE services, so you can launch a new session using the GUI, exit the GUI while leaving the emulation running, and reconnect at some later time. You can also run multiple sessions simultaneously.



(This only works for Linux network namespaces for now, until FreeBSD and OpenVZ have been ported to using the cored.py Python daemon.)

CORE is now a Python package

The CORE Python code has been reorganized into a Python package. New example scripts are included in the source under core/python/examples/netns/. Here is a snippet from one of the samples, how you would make N nodes connected to a switch:

from core import pycore
from core.misc import ipaddr

def main:
    ...
    # IP subnet
    prefix = ipaddr.IPv4Prefix("10.83.0.0/16")
    session = pycore.Session()
    # emulated ethernet switch
    switch = session.addobj(cls = pycore.nodes.SwitchNode)
    print "creating %d nodes with addresses from %s" % \
          (options.numnodes, prefix)
    for i in xrange(1, options.numnodes + 1):
        tmp = session.addobj(cls = pycore.nodes.LxcNode, name = "n%d" % i)
        tmp.newnetif(switch, ["%s/%s" % (prefix.addr(i), prefix.prefixlen)])
        tmp.cmd(["sysctl", "net.ipv4.icmp_echo_ignore_broadcasts=0"])
        n.append(tmp)

    # start a shell on node 1
    n[1].term("bash")