Version 8 (modified by Josh Smift, 9 years ago) (diff)

Don't actually need lavi_swlinks, and it's noisy

Testing OpenFlow in the GENI backbone

This page describes a procedure for testing that an experimenter can allocate resources in the GENI OpenFlow backbone, and send traffic through them. We might want to do this to test a FOAM or FlowVisor upgrade at Internet2 or NLR, for example.


  • You're only testing the OpenFlow backbone in Internet2 and NLR, and not any GENI core resources at regionals.
  • You're using as the IP subnet to test with; this is normally reserved to Josh Smift, so either check with him before using it, or use a different subnet. (The GENI Network Core subnet reservations page has a list of available (and reserved) subnets.)
  • You're using ProtoGENI VMs BBN (via NLR) and Utah (via Internet2), to send and receive traffic via VLAN 3716 in the core.
  • You're set up to use Omni in general, i.e. you've successfully used Omni to reserve GENI resources, have a current version of the software (in ~/src/gcf-current, in the examples below), a user credential signed by a CA that's trusted by all aggregates where you'll need to create slivers, a working omni_config file, etc.
  • You have an OpenFlow controller that you can use for this. (FIXME: It'd be better if we supplied instructions to allocate a controller host, and install and run a controller on it, but this is hard to do in a generic way, because the OpenFlow rspecs depend on the controller hostname, which you don't know until you allocate the host. Could be done, but it's more complicated.)
  • You have valid request rspec files to test with. There are example rspecs here, but NOTE that they'll need to be modified to point to your OpenFlow controller.
  • You know what output to expect when common things succeed. (Expected output is described here only in cases where an error is the expected result, or where it otherwise might not be obvious; if you think the expected output isn't obvious for any given step, let us know.)


Here's the full procedure for doing this.


This section sets some variables that later sections use; in particular, ones that you'll need to allocate resources.

The values below are the ones JBS uses when we do this at BBN; you may need to change some of them for your own use.

Set your slicename:


Set the names of your rspec files (if needed, modify these examples (which are BBN-specific) to use the path to your rspec files):


Set the URLs of the aggregate managers:


Set the target IP address that you'll want to ping. In this example, we use the dataplane IP address of the VM at Utah, which we'll ping from the VM at BBN.

dst_addr=$(grep "ip address" $protogeni_utah_rspec | sed -re 's/.+ip address="([0-9\.]+)".+/\1/')

Get resources

Create your slice, and make sure it won't expire for a few days:

~/src/gcf-current/src/ createslice $slicename
~/src/gcf-current/src/ renewslice $slicename "$(date -d 'now + 3 days')"

Create FOAM slivers at BBN, BBN InstaGENI, Internet2, NLR, and UEN:

~/src/gcf-current/src/ -a $foam_bbn_am createsliver $slicename $foam_bbn_rspec
~/src/gcf-current/src/ -a $foam_bbn_instageni_am createsliver $slicename $foam_bbn_instageni_rspec
~/src/gcf-current/src/ -a $foam_internet2_am createsliver $slicename $foam_internet2_rspec
~/src/gcf-current/src/ -a $foam_nlr_am createsliver $slicename $foam_nlr_rspec
~/src/gcf-current/src/ -a $foam_uen_am createsliver $slicename $foam_uen_rspec

Create ProtoGENI slivers at BBN and Utah:

~/src/gcf-current/src/ -a $protogeni_bbn_am createsliver $slicename $protogeni_bbn_rspec
~/src/gcf-current/src/ -a $protogeni_utah_am createsliver $slicename $protogeni_utah_rspec

NOTE that your FOAM slivers may need to be approved manually by an admin at each FOAM site; you should get e-mail from each of the five FOAM aggregates when they're approved (automatically or manually). You can also check your controller for connections from the relevant switches, but you won't be able to run tests until all of your slivers are approved.

Run tests

Once your FOAM slivers are approved, you can confirm that the backbone OpenFlow switches are connecting to your controller, and test that you can send traffic on your subnet.

OpenFlow controller

We don't provide detailed instructions for running an OpenFlow controller here. In this example (and the example rspecs), the controller is running at port 33017, with a LAVI listener on port 11017.

That controller was started like this:

cd ~/nox_build/src
./nox_core --info=$HOME/ -i ptcp:33017 switch lavi_switches jsonmessenger=tcpport=11017,sslport=0

That host has a patched version of the 'nox-console' program; you can get the patch from, and then use it to display a sorted list of DPIDs that are connected to your controller:

nox-console -n localhost -p 11017 getnodes | sort

This should produce output like:


In that list, the first five are from Internet2; the next four are from BBN, NLR, BBN InstaGENI, and UEN, respectively; the next five are from Internet2 again; and the last five are from NLR again.


Use Omni's remote-execute functionality to log in to the BBN VM, and ping the dataplane address of the Utah VM:

export PYTHONPATH=~/src/gcf-current/src
~/src/gcf-current/examples/ -a $protogeni_bbn_am $slicename -m "ping -c 10 $dst_addr"

The first few packets may take a second or two; the rest should have a consistent RTT.


Delete your slivers:

~/src/gcf-current/src/ -a $foam_bbn_am deletesliver $slicename
~/src/gcf-current/src/ -a $foam_bbn_instageni_am deletesliver $slicename
~/src/gcf-current/src/ -a $foam_internet2_am deletesliver $slicename
~/src/gcf-current/src/ -a $foam_nlr_am deletesliver $slicename
~/src/gcf-current/src/ -a $foam_uen_am deletesliver $slicename
~/src/gcf-current/src/ -a $protogeni_bbn_am deletesliver $slicename
~/src/gcf-current/src/ -a $protogeni_utah_am deletesliver $slicename