OpenSwitch Network Operating System

The Open Network Install Environment (ONIE) is an open source install environment that gives a switch user a choice to download ONIE compliant Network Operation System (NOS) to bare metal network switches. The OpenSwitch is community based, open source NOS that runs on hardware based on ONIE.

The goal of this article is to show how to build OpenSwitch Virtual Machine appliance, describe its capabilities and to introduce three methods for managing OpenSwitch. The OpenSwitch VM appliance was created by OpenSwitch project for training and testing purpose. It uses software data plane to forward the packets but it is not intended to be used as a virtual switch for connecting virtual machines. OpenSwitch supports many L2, L3 protocols such as STP, LACP, LLDP, OSPF, BGP, DHCP, TFTP, NTP, SSH, SNMP and others. These protocols run as separate daemons and they were integrated from another open-source projects.

For instance Quagga project provides L3 functionality to Openswitch. Quagga modules ops-ospf and ops-bgp update active routes in OpenvSwitch database (OVSDB). The module ops-zebra reads routes from OVSDB and install them to the kernel. Static routes are also stored in OVSDB, read by ops-zebra module and installed to the kernel. In order to use ASIC for fast-path routing, the module ops-vswitchd downloads a route from OVSDB and it install is to ASIC. ASIC uses the route, nexthop IP, next hop MAC and the egress port to route a packet. The pair neigbour IP address and MAC address is read from kernel neighbor table by a module ops-arpmgrd. If there is no entry, packets is sent to a kernel for ARP resolution and routed by the kernel. However the missing neighbor MAC address is added to ASIC and all other subsequent packets are routed by ASIC. The module ops-arpmgrd is also responsible for sending requests to kernel to refresh ARP entries for neighbors that have active data traffic.

The functionality of all OpenSwitch modules is very well documented on OpenSwitch website. The modules are stored in a directory /usr/sbin inside the OpenSwitch VM appliance.

OpenSwitch uses CLI similiar to Cisco IOS CLI. It makes configuration enough straightforward for a Cisco network engineer. They are also other two methods Web UI and Rest API that we can use for OpenSwitch management. I will describe them later.

1. Building OpenSwitch OVA Image From Sources

They are two ways how to obtain OpenSwitch OVA image. We can either clone OpenSwitch repository and compile OVA image from sources or we can donwnload image directly from OpenSwitch website.

In order to build OpenSwitch, we first need to install Linux OS. Linux can be installed on a virtual machine but assign enough CPU cores and RAM to the VM. Building the OpenSwitch from sources takes lots of resources so in order to shorten the time required for compilation, make your VM really powerful. I have assigned four CPU 4 cores and 4G RAM to the guest and compilation taken about 30 minutes.

Now we can install packages required for compilation.

$ sudo apt-get install python chrpath device-tree-compiler build-essential diffstat texinfo openssl libssl-dev

Clone the OpenSwitch development environment and build system.

$ git clone https://git.openswitch.net/openswitch/ops-build
$ cd ops-build

Compile sources with the following commands.

$ make configure appliance
$ make

Once compilation finishes, the OVA image should be ready in a directory ~/ops-build/images. Now download the final OVA image from the guest to the host machine with the command:

$ scp -rv ~/ops-build/images/openswitch-appliance-image-appliance.ova brezular@10.0.2.2:/home/brezular/

2. Downloading OVA Image

The OVA image can be found on OpenSwitch website but without the guarantee that the image is uploaded  there. Check the content one of the directories here. There should be a directory named appliance containing the OVA image. If not, try to search inside an another directory.

3. Runing OpenSwitch Virtual Appliance

Use Virtual Box to import a virtual machine. Navigate to File-> Import Appliance. If you prefer Qemu to Virtualbox just extract vmdk disk from OVA image with the command:

$ tar xvf openswitch-appliance-image-appliance.ova

Then you can start the virtual machine with the command below.

$ /usr/local/bin/qemu-system-x86_64 --enable-kvm -m 1024M -smp 2 OpenSwitch.vmdk

4. Users and Groups

By default they are three built-in roles ops-admin, ops-netop and none created for authenticated users. The roles ops-admin and ops-netop are represented by user groups with the same names. Users are assigned to the group based on their roles. For instance, members of the group ops-admin have no access to OpenSwitch shell - vtysh so they cannot configure OpenSwitch. However all the members of the group ops-admin can run sudo su command and eventually start vtysh shell. It is because there is a following line in the file /etc/sudoers.d/useradd.

%ops_admin ALL=(ALL) NOPASSWD: ALL

The group ops-admin is used for firmware upgrades, changing users' accounts (after sudo su command). User accounts assigned to the group ops-netop have access to vtysh shell and they are used for reading and writing from and to OpenSwitch configuration.

Below is the list of some default users created on OpenSwitch appliance assigned to the particular groups and having access to shells.

root - without password, /bin/bash
admin - without password assigned to ops-admin group, /bin/bash
netop - password netop assigned to ops-netop group, /usr/bin/vtysh

The user netop is a member of the groups ops-netop, ovsdb-client and ops-coredump. This user has access to vtysh shell and it is used for configuring OpenSwitch. If we want to create a new user account e.g. test for OpenSwitch configuration, we need to create it as following:

# /usr/sbin/useradd -g ops_netop -G ovsdb-client -s /usr/bin/vtysh test

The user test is now assigned to its primary group ops_netop and to the group ovsdb-client using the vtysh shell.

Note: The user root has no password set so it should be configured to allow an access to the system for authorized users only.

5. Web User Interface

The Web UI  provides  provides system, general and hardware information about OpenSwitch. It also provides status and utilization of the interfaces and displays their statistics. You can find there information about VLANs, logs and configuration of the Link Aggregation (LAG) and Equal-cost multi-path routing (ECMP). It also contains links to OpenSwitch Rest API and to quick guides about interfaces and LAG configuration.

Picture 1 - Web UI

The Web UI is using the REST API to authenticate the user and to retrieve a list of permissions accessible to the user. Use switch CLI to login as root with no password. Enable and start nginx and restd services.

# systemctl enable nginx && systemctl start nginx
# systemctl enable restd && systemctl start restd

If there is a DHCP server running in a network where OpenSwitch appliance is connected to, the switch should obtain the IP address from DHCP server on its eth0 interface. If not, you probably need to bridge the first switch interface to the network with DHCP server. Navigate to Machine-> Settings-> Network-> Adapter1 and bridge the interface. Then use web browser to login to the IP address of the eth0 interface as a user netop with the password netop.

6. Rest API

Using Rest API and HTTP methods such as GET, PUT, PATCH, POST we can get or store data from and to the OpenSwitch. First we will show how to log to the OpenSwitch using curl command.

Login to OpenSwitch with the IP address  assigned to a management interface with the username netop and password netop and save a cookie to the file mycookie. If there is no an error message, yur login is successful.

$ curl -c mycookie -X POST -k "https://172.17.100.7/rest/v1/login?username=netop&password=netop"

Check if the cookie is successfully stored with the command below.

$ more mycokie

Picture 2 - Saved Cookie

Now we can pull  information from OpenSwitch. For instance, list the available interfaces with the command:

$ curl -b mycookie -k https://172.17.100.7/rest/v1/system/interfaces/

Picture 3 - Available Interfaces

Similarly, we can pull information about configured VLANs. There is only default VLAN 1 created.

$ curl -b mycookie -k https://172.17.100.7/rest/v1/system/bridges/bridge_normal/vlans

Picture 4 - List of VLANs