Skip to content

Home

Jump to bottom
Konstantinos Papadopoulos edited this page Feb 12, 2017 · 5 revisions

NSTAT SDN Controllers

We support currently controller handlers for the following versions of OpenDaylight

However in the

Controller node deployment

For testing the aforementioned handlers, a container based testing environment can either be downloaded directly from dockerhub or built from the tools available at the /deploy folder

  • essential tool: docker (v.1.12.1 or later) should be installed on your host machine
  • Give non-root access to docker daemon
    • Add the docker group if it doesn't already exist sudo groupadd docker
    • Add the connected user "${USER}" to the docker group. Change the user name to match your preferred user
    sudo gpasswd -a ${USER} docker
    • Restart the Docker daemon:
    sudo service docker restart

Download the pre-built enviroment

docker pull intracom/nstat-sdn-controllers

For running a container once the intracom/nstat-sdn-controllers is locally available

docker run -it intracom/nstat-sdn-controllers /bin/bash

password: root123

then make a git clone of the nstat-sdn-controllers repository within the container

git clone -b master https://github.com/intracom-telecom-sdn/nstat-sdn-controllers.git

and start testing all available controller handlers under /controllers directory

Build your own container based testing environment

Controller handlers usage

Controller handling features

Currently the supported controller is OpenDaylight. There is a common API in the controller handling logic, followed by all versions of this controller. Next, we describe this common API logic for the controller handlers.

  1. change_persistence.py:
    • expected behaviour: handler disabling the persistence mode in the configuration of the controller. Changes the persistence attribute to false which is present at the org.opendaylight.controller.cluster.datastore.cfg of OpenDaylight. In this case the controller will not backup datastore on the disk
    • prereqs: should be executable
    • input arguments: none
    • exit status: 0 in case of success, 1 otherwise
    • usage example:
  2. change_stats_period.py:
    • expected behaviour: changes controller statistics interval
    • prereqs: should be executable
    • input arguments: statistic period (in ms)
    • exit status: not checked
    • usage example:
  3. change_stats_period.py:
    • expected behaviour: configures OpenDaylight controller for flow modifications. It currently changes controller configuration files in order to achieve mac-to-mac flow installation for Packet_INs with ARP payload.
      • <controller base dir>/etc/opendaylight/karaf/54-arphandler.xml: changes the value of key is-proactive-flood-mode from true to false.
      • <controller base dir>/etc/opendaylight/karaf/58-l2switchmain.xml: changes the values of keys reactive-flow-idle-timeout and reactive-flow-hard-timeout to 1.
    • prereqs: should be executable
    • input arguments: no input arguments required
    • exit status: not checked
    • usage example:
  4. get_controller.sh:
    • expected behaviour: gets the pre-built version of the OpenDaylight controller.
    • prereqs: should be executable
    • input arguments: none
    • exit status: 0 in case of success, non-zero otherwise
    • usage example:
  5. get_flows.py:
    • expected behaviour: returns the number of installed flows of a topology, connected to the controller. This information is extracted from the controller's operational datastore, using RESTCONF.
    • prereqs: should be executable
    • input arguments: controller IP address in form, controller restconf port number in form, username for restconf authorization in form password for restconf authorization in form
    • exit status:
    • usage example:
  6. get_hosts.py:
    • expected behaviour:
    • prereqs:
    • input arguments:
    • exit status:
    • usage example:
  7. get_links.py:
    • expected behaviour:
    • prereqs:
    • input arguments:
    • exit status:
    • usage example:
  8. get_switches.py:
    • expected behaviour:
    • prereqs:
    • input arguments:
    • exit status:
    • usage example:
  9. start.sh:
    • expected behaviour: starts the controller so that a switch can connect to it
    • prereqs: should be executable
    • input arguments: none
    • exit status: 0 in case of success, non-zero otherwise
    • usage example:
  10. status.sh:
    • expected behaviour: queries the controller status
    • prereqs: should be executable
    • input arguments: none
    • output: 1 if controller is running, 0 otherwise
    • exit status: not checked
    • usage example:
  11. stop.sh:
    • expected behaviour: stops the controller so that no switch can connect to it
    • prereqs: should be executable
    • input arguments: none
    • exit status: 0 in case of success, non-zero otherwise
    • usage example:

Controller handlers can be directly executed on your local machine provided that necessary tools/libraries prerequisite within the *.sh, *.py handler files are properly installed. However. for keeping your local machine clean, a container based testing environment is provided or can be built as desrcibed below.

Controller handling usage

Adding your own handlers

Clone this wiki locally