Note: This article was originally published here.

Update:This post has been updated to account for some recent changes in the appliance configuration (support for up to 7 front ports). In my previous post I described my developer setup to work with OpenSwitch. At the end of my post I showed how to download the build system, and configure and build an ‘appliance’ image.

What Is An OpenSwitch Appliance?

The appliance is a virtual machine image (in OVA format) that could be run on VirtualBox or VMware (on this articule I will focus on VirtualBox) and provides a software datapath (based in OVS right now, but P4 support it’s landing soon). All the rest of the OpenSwitch stack is the same that you will see in a real hardware, and obviously the software datapath has certain limitations and features not implemented.

Despite his limitations, the appliance is a really nice way to get your hands into OpenSwitch without having real hardware.

If you are using the development environment, you can find the appliance .ova file on the images directory after completing the build, but otherwise you can also download a periodic image from the project archives (keep in mind this is a developer snapshot, so things may be broken or uncomplete sometimes).

The Appliance has currently 4 8 network ports (this is the max number of interfaces supported by VirtualBox): eth0 to eth7. The port ‘eth0’ will be the management port, and the other ones are ‘front ports’.

How To Use The Appliance?

The first good use for the appliance is that you can import it into VirtualBox, and by using ‘bridged’ interface with a dedicated NIC (for example an USB ethernet dongle), you can make the appliance talk with a real piece of hardware, like a traditional router. This allows you to play with LLDP, BGP, OSPF, etc. I won’t go into details of a setup like this for this article, and is left as exercise to the reader.

In the previous scenario, using one Appliance was nice, but how about using multiple appliances together? Like creating a virtual CLOS? For that we will be using GNS3.

If you never heard of GNS3 before, is an Open Source platform to create virtual networks and deployments inside your laptop, with some nice UI. Even more useful, it’s cross platform. I will be focusing my demo here on using it over Mac, but should be easy to extrapolate if you are a Windows user.

Setup OpenSwitch Appliance On VirtualBox for GNS3

In order to use the appliance with GNS3, you need to import the OVA file into VirtualBox (File -> Import Appliance). The OVA generated by OpenSwitch is compatible out of the box with GNS3 since April 26th 2016.

Installing And Configuring GNS3

First, download GNS3 from their project page and install it (yes, you have to register). Next, I recommend that you install Wireshark to have the capabilities of snooping on the traffic of the virtual network.

On recent OS X, when trying to run the GNS3 application you may get an error message:

“GNS3” is damaged and can’t be opened

This is a wrong error message, and the problem is really that you need to reduce the security of the system to allow executing applications that are not from the App Store. You can change this setting on: System Preferences -> Security & Privacy -> Allow apps download from: Anywhere.

When you first start GNS3, it will start the Setup Wizard, and ask for a server. Select the ‘Local server’. We would not need the GNS3 VM for running the OpenSwitch appliance, since will be run on top of VirtualBox.

On the next window select to ‘Add a VirtualBox virtual machine’ (at this point you should have already imported the OpenSwitch Appliance into VirtualBox for this to work).

Next, select the OpenSwitch Appliance Image that was imported into VirtualBox, and enable “Use as linked base VM”.

After of click on ‘Finish’, the preference panel for VirtualBox VMs will show and you will have to edit the recently created template to add some custom configuration: On the ‘General Settings’ tab:

  • Template Name: OpenSwitch
  • Default name format: {name}-{0}
  • Symbol: /local/path/to/OpenSwitchStencil.png
  • Category: Switches
  • RAM: 512 MB
  • ☑︎ Enable remote console
  • ☐ Enable ACPI shutdown
  • ☑︎ Start VM in headless mode
  • ☑︎ Use as a linked base VM

On the ‘Network’ tab:

  • Adapters: 8
  • First port name: mgmt
  • Name format: eth{port1}
  • Segment size: 0
  • Type: PCNet-FAST III (Am79c973)
  • ☑︎ Allow GNS3 to use any configured VirtualBox adapter

Creating A Simple Connection Between Two Appliance Instances

Now, it’s time to deploy two instances and verify connectivity between them:

  • Create a new project and save it (the linked VM won’t work on temporal projects).
  • Click on the ‘Browse all devices’ button on the left panel to show the available devices, then drag two OpenSwitch instances into the canvas (you can see in your VirtualBox UI that two new virtual machines are created).
  • Use the ‘Add link’ tool from the left panel (the one that looks like a cable with an RJ45 plug) to connect the two instances over the eth1 port of both.

At the end of this setup your project should look like this:

Before starting the simulation, I will attach wireshark to one of the interfaces to see the packets between the machines:

  • Right click on one of side of the links and select ‘Start capture’. This will create a pipe that will output the contents into a pcap file that wireshark can feed from. This can only be done when the link is down, so you need to start the captures before turning on the VM.

Now you can start your machines by hitting the top ‘Play’ button. This will start both VMs. Then you can double click on both machines and a Terminal will open where you get access to the serial console of the machine. You can login with the user and password ‘netop’ (this will enter into the traditional CLI mode, but you can also login as root into a bash shell):

At this point you can right click on the link where we are capturing the traffic, and select ‘Start Wireshark’. This will open a WireShark window that is feeding from the pcap capture of the traffic from the port.

Note: There is currently an open bug in OpenSwitch where the image may fail to boot properly the data path. To validate your appliance booted properly run the following command:

# show interface eth1

If the reported MAC address is (null), then reboot the appliance and check again. I will update this blog as soon as the bug is closed.

Now is time to see some traffic flowing between the machines: let’s enable LLDP on both ports, and we should be able to see both switches identifying each other, and the traffic flowing thru Wireshark. Let’s issue the following commands on the CLI of both switches:

switch# config
switch(config)# interface eth1
switch(config-if)# no shutdown
switch(config-if)# exit
switch(config)# lldp enable
switch(config)# exit

After these commands are entered on both switches, we can now show the LLDP neighbor information on any of the switches:

switch# show lldp neighbor-info eth1
Port                           : eth1
Neighbor entries               : 1
Neighbor entries deleted       : 0
Neighbor entries dropped       : 0
Neighbor entries age-out       : 0
Neighbor Chassis-Name          : switch
Neighbor Chassis-Description   : OpenSwitch 0.3.0 (dill) Linux 3.14.19-yocto-standard #1 SMP PREEMPT Wed Mar 23 00:06:21 UTC 2016 x86_64
Neighbor Chassis-ID            : a2:69:35:48:7b:4d
Neighbor Management-Address    : 
Chassis Capabilities Available : Bridge, Router
Chassis Capabilities Enabled   : Bridge, Router
Neighbor Port-ID               : eth1
TTL                            : 120

And you can see the LLDP advertisements going thru with Wireshark:

Conclusions And Next Steps

That is all the fun that we will have for today, hope you find the information useful. I’m planing to blog soon about the following subjects:

  • A GNS3 setup of a CLOS network, and pushing the configuration using Ansible (yay!).
  • Playing with an appliance using P4.

Stay tuned!