Asymmetric Links and Jitter

Asymmetric link effects can now be configured using the CORE GUI. A new Unidir. >> button in the Link Configuration dialog (when you double-click a link) will expand to show unidirectional link effects. When collapsed, the specified parameters are used bidirectionally.

Below is a screenshot of the expanded dialog. The parameters on the left are for downstream (e.g. for a link from n1 to n2, traffic going from n2 to n1) and upstream on the right.

Jitter

Also a new jitter parameter has been added. Like delay, this value is in microseconds, and specifies a random variation in delay for each packet. See this netem page for details. If you're curious about which tc netem rules that CORE is using, turn on the "-v" verbose logging option in the daemon:

16276: linkconfig: [['/sbin/tc', 'qdisc', 'replace', 'dev', 'n1.eth0.69', 'root', 'handle', '1:', 'tbf', 'rate', '512000', 'burst', '3000', 'limit', '65535']]

16276: linkconfig: [['/sbin/tc', 'qdisc', 'replace', 'dev', 'n1.eth0.69', 'parent', '1:1', 'handle', '10:', 'netem', 'delay', '45000us', '7000us', '25%', 'loss', '0.0%', 'duplicate', '0.0%']]

Caveats

There are a few caveats with asymmetric link effects. To get unidirectional link effects in a wireless model (using the WLAN), look to the EMANE Comm Effect model. The basic on/off model can only support on/off connectivity and uniform effects for the WLAN network as a whole. The asymmetric effects can be used between layer-3 nodes (router, PC, host, etc.), between hubs/switches, and links with RJ45s -- but not for a link between a hub/switch and another node.

Links between hubs/switches and other nodes only have a downstream effect. The round-trip delay (RTT) in the example above is 5ms between n1 and n2 (not 10ms) and 3ms between n1 and n3. This is because CORE is configuring the netem queue, which is outbound queuing only, on one of the veth pair interfaces, highlighted in yellow in the diagram below.

To get a round-trip delay using a switch, configure half the delay on all of the links to the switch (e.g. use 1.5ms on all links for a 3ms round-trip delay.) This could be fixed in future revisions by adding a netem queue on the outbound interface (e.g. the white veths in the diagram) inside the namespace, or by using inbound netem queuing with IFB devices.

3D GUI with SDT3D

A new 3D GUI menu item has been introduced under the View menu. CORE can now publish its topology to the SDT3D (Scripted Display Tool 3D) developed by NRL. The latitude, longitude, and altitude settings under the Canvas Size and Scale dialog will determine the coordinate mapping to a geographic location. SDT3D is based on NASA's WorldWind Java SDK. This is three-dimensional virtual globe software similar to Google Earth.

Node movements and links are drawn on the 3D map as depicted in the screenshot below.

In order to get this working, a /usr/local/bin/sdt3d.sh launcher script is made with the following contents:

#!/bin/sh
cd ~
/opt/sdt/sdt3d.sh $@

The following line is used in an ~/sdtConfig.txt file in the user's home directory; this causes SDT3D to receive commands on a local UDP port 5000 socket :

listen 5000

Here we have SDT3D installed to /opt/sdt, with a /opt/sdt/sdt3d.sh script as shown below:

#!/bin/sh
export JAVA_HOME=/usr/lib/jvm/java-7-openjdk-amd64/
THISDIR=`dirname $0`
export LD_LIBRARY_PATH=${THISDIR}/libjava -jar -Dsun.java2d.noddraw=true -Xmx512m \ ${THISDIR}/jars/sdt3d.jar

For tips on building and install SDT3D under Ubuntu 12.04 x86_64, see this SDT3D wiki page. OpenJDK 1.7 is used, as the Oracle JDK did not seem to work.

XML export

There's a new option under the Save As dialog box, to export your topology to an XML format. The supported schema can be found here. This is the NRL EmulationScript NetworkPlan with time 0 location information. Note that this format will see some updating as the spec evolves.

Sample output for two router nodes linked together is shown below. There is still much to be done in order to represent all of the data contained in the imn file format.

The XML export occurs at the Python (cored.py) level, with the GUI feeding the back-end the filename to write. This was done so that Python-scripted scenarios could be saved/loaded directly to/from XML without the GUI.

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.

custom MAC assignments

Next to the IP address configuration in the node configuration dialog, you can now configure a MAC address for each interface. Default is the usual auto-assign. Also a little trash icon next to the IP addresses should make removing unwanted addresses much easier.

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.

updated icons

Node icons have been given a face-lift:

Thanks to Justin Y. for suggesting these free-for-any-use icons on the core-dev list, used as the basis for routers and RJ45/tunnel. Inkscape was used to create a rainbow of router icons, along with hub and switch icons to match the routers.

traffic flows using MGEN

A new Traffic Tool has been added to the Tools menu. You can use this tool to create traffic flows between source and destination nodes.
When you click to create or edit a flow, the dialog shown below appears. Clicking on the source node button allows you to choose a node that will send traffic and destination node a node that will listen and log received traffic. IP addresses are automatically entered based on selected nodes, or you can choose addresses from a list. A few preset traffic patterns are defined to help get you started using MGEN.
When the scenario is started, MGEN scripts are generated on each of the nodes. Each flow has a start (and optional stop) time. You can choose to autostart all flows after the emulation is running or manually start and stop them.

To use this feature, you should get MGEN from here. The nightly snapshot for MGEN and protolib are recommended.

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.

custom IP address generator

Configure the next IPv4/IPv6 network that will be assigned.

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.)

more images than GIF supported

Use of the Tk::Img library was added to CORE. This allows you to use various image types besides just the GIFs that were supported before -- such as JPG, PNG, TIF, etc. Now the custom node icon and canvas wallpaper dialogs accept various image types.

The Img library is a new dependency for the CORE GUI. You can install it with:

    # for RedHat/Fedora
    yum install tkimg

or

    # for Debian/Ubuntu
    sudo apt-get install libtk-img 

nodes find their place in this world

The Canvas resize dialog was updated to Canvas Size and Scale. This allows you to set a geographic reference point and scale in meters for the canvas, so the traditional X,Y node coordinates can now be translated to lat/long geo coordinates. This support was added so CORE now generates EMANE location events when a node is moved on the canvas.

user-editable Observer Widgets

You can now edit the list of Observer Widgets. Insert your own commands that are run on the node with a mouse over. Changes are saved to a /usr/local/etc/core/widgets.conf file.

grid topology generator

More topology generators were added, the Grid and Connected Grid. Quickly build an NxM wired network with the Connected Grid, or use the Grid to fill the canvas with evenly-spaced disconnected nodes.