goSDN

goSDN is a prototypical approach to build a model driven multi-vendor SDN controller.

This repository contains submodules, therefore it must be cloned with

git clone --recurse-submodules git@code.fbi.h-da.de:danet/gosdn.git

or if you have cloned the repository without --recurse-submodules simply run:

git submodule update --init --recursive

to get all submodules.

You can find a detailed manual to install all necessary tools at our Wiki.
There you can also find some tutorials to get to know the SDN controller:

• Lab00 education, which is used in education
• Lab00, which uses servers with gNMI targets instead of Arista switch images (needs less storage than Lab01)
• Lab01, which uses servers with Arista switch images (needs less storage than Lab01)

Table of Contents

• Overview
  • Example
  • Structure
• Concepts
• Installing
• Getting Started
  • Playground
  • Additional services
  • Configuration file
• Contributing
• License
• CI Status
• Development Tutorial

Overview

goSDN is also an application that will allow you to manage your multi-vendor network using one unified controller.

goSDN provides:

• Model driven device/network element representation
• Native multi vendor support
• Multi controller environments

Example

A simple showcase how the controller can be adressed after make containerlab-start is shown below:

Structure

• The api is a representation of the controllers Northbound-Interface and can be used to communicate with the controller.
• The cli is the CLI to manage the controller.
• csbi is the implementation of Containerised-Southbound-Interfaces (based on the idea and the proof of concept of Manuel Kieweg). Allowing to request capabilities of MNEs and generate a containerised Southbound-Interface based on them. They are currently unsupported.
• controller represents the goSDN-controller.

Concepts

The goSDN controllers core - also called nucleus - is a lightweight library that manages principal network domains and provides southbound interface operations for managed network elements.

In addition, we provide a simple Northbound-API for the controller right here.

Principal Networking Domain (PND)

The PND is the single source of truth within a network. Its state is held and maintained by the controller. Any configuration of an MNE has to be applied by the PND.

Managed Network Element (MNE)

Any network element directly configured by goSDN

Launch goSDN Controller local

In this chapter, you learn how to launch the goSDN controller.

Firstly, make sure that you're located in the root directory of gosdn. goSDN provides a Makefile for all common use cases.

# build the application files for goSDN, cSBI orchestrator, gosdnc (CLI).
make build

# build the Dockerfiles for goSDN, cSBI orchestrator, gosdnc (CLI).
make containerize-all

Depending on how you want to use the controller, you might need to edit the example config files and provide the path to this or a new config file. This can be done by providing setting the config flag when starting the controller.

--config

In case you want to use specific services with the controller without setting them up manually you can use the provided docker compose file. More information about that can be found under Additional services.

Now you can start goSDN locally by moving to the artifacts folder and running ./gosdn from the shell:

./gosdn

Getting Started

If you want to use the the playground you have to make sure you have containerlab installed on your system.

Playground

With the help of containerlab we provide simple test environments to play around with.

The environment Lab 01 contains two Arista cEOS, a goSDN, a gNMI target, a plugin-registry, a MongoDB and a RabbitMQ.

The environment Lab 00 contains two gNMI targets used as switches, s goSDN, two Linux servers, a plugin-registry, a MongoDB and a RabbitMQ. Lab 00 is lighter than Lab 01.

If you're a member of the danet group you should have access to the containers repo. Don't forget to sudo docker login registry.code.fbi.h-da.de (sudo is necessary since containerlab has to be run with it and therefore a normal docker login wouldn't be recognized by it.)

If you're no member of the danet group you have to create an account at Arista and download the Arista cEOS image by yourself. Don't forget to change the image name (line 11 in the gosdn.clab.yml file) to the local one you've downloaded.

# starts the containerlab topology which contains two Arista cEOS, an cSBI orchestrator, a goSDN controller and gNMI target.
make containerlab-start

# stop the containerlab topology
make containerlab-stop

Additional services

There are optional and mandatory services that can be used with the controller. They can be started via the provided docker-compose.yml:

docker compose up -d

Otherwise all the necessary services are included in the provided environments like containerlab. Within other use cases, they can also be configured by providing specific parameters in the controller config files. See Configuration file for information about the parameters. The services are:

• RabbitMQ message-broker: uses AMQP to provide a pub-sub mechanism. This is part of the event system used in goSDN. This server is optional.
• Databases: The controller can be used with a file store system or by providing an external database. Currently, there is only support for MongoDB. It is not mandatory to use a database.
• Plugin-registry: The plugin-registry provides plug-ins to the controller, which are used to handle different YANG files used within the communication with MNE via gNMI.

Configuration file

goSDN can be configured by using providing a config file. Examples can be found in controller/configs. These examples contain different pre-defined configurations for different environments. There's no need to touch the config files when using provided environments like starting the containerlab via makefile. The following parameters can be set:

For goSDN:

• security: the security level of the controller.
  • 'secure' mode does use the built-in authentication and RBAC mechanisms (recommended)
  • 'insecure' does not use these (only use for testing purposes). Uses default if not set.
• socket: the desired port, where to reach the controller
• basepnduuid: an initial ID of a PND within the network, needs to be a UUID
• config: path to this configuration file, so change can be written back to the file
• gnmisubscriptionspath: path to the file providing the YANG paths the controller should subscribe to in each network element existing in its storage
• defaultjwtduration: duration of how long session tokens will be valid, provide an integer for the desired hours, example: 24 for tokens that should be valid for one day
• log-level: set to 'debug' for a better level of information
• help: print the description of all available flags

For the storage system:

• databaseconnection: address of the database, only add this parameter if you want to use a database. Currently only mongoDB is supported.
• filesystempathtostores: set this path if the controller should use only the file store system, does not support all entities currently.
  Note: if the database connection is set as well, this parameter will be ignored.
• plugin-folder: path to where the plugins are/should be stored.

For the event system (RabbitMQ broker):

• amqpprefix: the URI prefix that is needed to connect to the RabbitMQ broker.
• amqphost: ip adress of the broker
• amqpport: port of the broker
• amqpuser: user name of credentials to access the broker, default value is guest
• amqppassword: user password of credentials to access the broker, default is guest

For the plugin registry:

• plugin-registry: ip adress and port of the plugin-registry

CLI

Information about how to use the CLI is provided in the cli folder, see here.

CI Status

Master

Development Tutorial

To help with developing there is a small script available, which helps to create the complete dev environment. For it to work, you need go, docker, docker compose and containerlab.

For a quick start simply use make start-dev-env to start everything. This can take a while. Afterwards, you see the output of goSDN, to stop it hit Ctrl+C. To stop everything else use make stop-dev-env.

If you want more control over your environment, you can use the manage_virt_env.sh script directly.

It works like this, if you are in the projects root folder:

./scripts/manage_virt_env.sh --mode $(start || stop) --topology $PATH_TO_TOPOLOGY --SDNCONFIG $PATH_TO_SDNCONFIG --keepdb (optional)

mode defines if it should start or stop the environment, while the two commands --topology and --sdnconfig are used to provide the desired files. The optional flag keepdb is used if you want to create the environment without reloading the SDN config file, which is handy if you just want to restart the environment. For every command there is a shortcut available (e.g. -t for --topology, etc.).

Example usages:

./scripts/manage_virt_env.sh --mode start --topology dev_env_data/clab/basic_two_aristas.yaml --sdnconfig dev_env_data/sdn/basic_two_aristas.json

./scripts/manage_virt_env.sh --mode start --topology dev_env_data/clab/basic_two_aristas.yaml --keepdb

./scripts/manage_virt_env.sh --mode stop --topology dev_env_data/clab/basic_two_aristas.yaml

Backup and restore your mongodb

If you are using the mongodb provided via the docker-compose.yaml, you can easily back up and restore your data via two scripts.

./scripts/backup_mongo_volume.sh $(suffix_of_backup)

./scripts/restore_mongo_volume.sh $(suffix_of_backup)

Keep in mind that a restore will restart the mongodb container.

Developing SDN applications

To develop applications, we provide a framework that can be found here within this repository.

The framework provides some basic code to easily setup the subscription to the event system of the controller, so that your application can get notified via the events published by the RabbitMQ server about information you would like to receive. This includes functions to register and subscribe to the used server. The information you receive includes changes on network elements like if a value of a YANG path changes or other changes like additions or deletions of entities.

Examples where the application framework is used can be found here.