OpenSwitch in an OVA

First, disclaimer: I’m an HPE employee. Hewlett Packard Enterprise is a major contributor to the OpenSwitch project. Just thought you should know in case you think that affects my opinion here.

If you need more info on the OpenSwitch project, you can check out the other post in this series here and here

Network Engineers Don’t Like Learning New Things

Got your attention, didn’t I? After the first couple of posts on OpenSwitch and a lot of discussions about this cool new project at some recent events, there was one piece of feedback that came back fairly consistently from the traditional engineers. OpenSwitch is hard to get running because there’s so many new things to learn.

When released in November of last year, the initial demonstration environment was actually pretty simple and streamlined to get up and running, as long as you’re a developer.

The process involved the standard set of dev tools:

Virtual Box
Vagrant
DockerToolbox
Docker

For anyone involved in a development environment, these tools are like an old hoody on a cold winter day. Welcome and familiar.

But for the majority of network engineers who are far more comfortable with a console cable and a telnet session, it appears that the barrier to entry was just too high for people to start getting their hands dirty.

I was able to bring this feedback to the OpenSwitch engineering team and I’m happy to bring the news that OpenSwich is now available in a OVA format that you can run natively on VirtualBox.

Read the Docs

I’m going to go the long way around to get this up and running, but I’ve heard that the OVA file may be prebuilt and available on the OpenSwitch website in the near future. *I’ll try and come back to edit this post with a direct link if that happens*

The build process for OpenSwitch is actually well documented here. Depending on the OS you’re running, there are some specific dependencies that are well documented. I won’t cover those since they are already there, but make sure you do check the docs carefully when you’re creating you’re build system as it won’t work unless you follow them.

Getting the Code

Since we’re going to be simply creating an OVA image, we don’t need the entire OPS GIT repo, we only need the ops-build portion. The first thing we’re going to do is to get to a terminal window on your linux ubuntu 14.04 host, create a directory called opsova and then GIT clone the ops-build repository using the following command. This command will copy the contents of the ops-build directory on GITHUB into a local directory called ops-build on your local machine.

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

Selecting the Build

Now that we’ve cloned the necessary code to our local machines. We’re going to select the type of OpenSwitch build that we’d like to create. If you were pushing this to a supported white box switch you would use the following commands

make configure genericx86-64

But since we’re going to be creating an OVA so that we can import directly into Oracle Virtual box (Because it’s free!) we’re going to configure the appliance build

make configure appliance

Creating the OVA

Now for the final-ish step of the build. We’re going to run the make command to actually create the OVA file.

Warning: If you’re doing this in a VM. You want to give it lots of CPU for this step or it could take quite a long time. Remember burning CD’s on a 1x speed burner? Yeah… it feels like that.

make

Running the OVA

Now that we’ve successfully created the OVA, the next step is to move it out of the VM to the host machine where you have Oracle VirtualBox installed.. This, of course, is assuming that you followed my example and you were doing this in a Ubuntu VM rather than a bare metal machine. From here, we follow a typical deployment and import the OVA using the following steps.

Finding the OVA

Once the make process, finishes ( there may be a couple of warnings, but it should build successfully ), you will navigate to the ./images folder where you will find a symbolic link to OVA file. Following the symbolic link, the actual OVA was located in ./ops-build/build/tmp/deploy/images/appliance.

Screen Shot 2016 01 19 at 1 14 15 PM

Now you need to get it off of your VM host and move it over to the machine where you are running VirtualBox. ( I’m assuming you are comfortable with moving files between two machines and I’m not covering that here. Please feel free to point out in the comments if I’ve made a false assumption ).

Importting the OVA into Virtual Box

Now that we’ve moved this over to the host machine where you’re running VirtualBox, you simply choose File\import Appliance and navigate to the directory where you stored the OVA click next a couple of times and you should be good to go.

Screen Shot 2016 01 19 at 1 18 25 PM

Logging into OpenSwitch

In the last part of this post, we’re going to login to the OPS image. The default username for the appliance build is root with no password. Simply type in the username and you should be in the system

If you want to jump ahead of the next post, you would now type vtysh at the command prompt to pop into the quagga network shell which is where us network types will find ourselves most at home.

Screen Shot 2016 01 19 at 1 24 48 PM

What’s Next

In the next post, I’ll be looking at some basic configuration tasks, like adding an IP address and establishing basic network connectivity. If you have any issues getting this running, please feel free to post in the comments below, or even better, get involved in the OPS community by using the mailing list or the IRC Channels ( You can find information on all the ways to participate in the OPS community here

@netmanchris

2015 Recap and plans for 2016

About this time last year, I wrote this post. It’s time to revisit again and plan for 2016.

How did I do?

In 2015, I planned to work on skills in four major areas; python, data science, virtualization, and then just keep up on networking. In general, I think I did good in all areas, with the breakaway really being in the python area. I made a concerted effort this to year to seek out project after project that would allow me to explore different aspects of python, and force me to grow in as many areas as possible. Attending Interop sessions led by such trailblazers as Jason Edelman, Jeremy Schulman, and Matt Oswalt definitely gave me ideas and inspiration to explore new areas, push boundaries, and have really helped me to grow as a coder/developer not to mention really helped me to cement some opinions on the future of networking in general.

I did manage to get through a bunch of the R courses in Cousera and they were great. I’d love to say that I’m going to return and finish the specialization (I’m two courses shorts) but if I”m honest, I’m probably going to move towards the Data Science aspects of Python and get into Anaconda and Pandas more in 2016. Nothing like combining two growth areas into one to really push the growth.

More so this year that others, having great conversations over beers, Moscow Mules, and many a sugery umbrella drink helped me expand my knowledge and firm up some of the thoughts I’ve been having for the last couple of years. No need to name drop, but you all know who you are and I’d like to say thanks for all of the conversations and laughs. As much as I love the tech, it’s the people that always help to drive me forward.

If I’m keeping score, I think that 2015 was a good year.

Plans Plans Plans

Now comes time to publicly declare what I want to accomplish in 2016. This is always the scary part as I know I’m now publicly accountable for any grandiose designs I throw into the ether. 🙂

Practice to Application:

I’ve got a bit of a lab at home. If things go as planned, at the end of the year, I will be able to factory reset *almost* the entire lab and have it come back from the dead in a completely automated fashion. The plan here is to use a combination of python, jinja2, IMC, Ansible, and whatever other pieces I need to duck tape together to make this work by the end of the year. Just because I like to make my life harder than it has to be, I’m planning on building out the topology using vendor independent methodologies, meaning that I want to be able to place a Cisco, HP, or Juniper box into any position in my lab access/distribution/core/dmz/wan/etc… and use a YAML file to dynamically build the required configurations on demand.

Yeah… I know…. But it’s good to set goals right?

OpenSwitch

OpenSwitch is also another area which I will definitely be exploring during 2016. The project is still very new and definitely has some places, mostly in the documentation area, where there’s room to make a difference. I’ve been really lucky to be able to work at a place where I have direct access to some of the projects core developers and I’m hoping I can share the fruits of that access in more blogs posts, pull requests to enhance the documentation, as well as some interoperability testing with some of the usual-suspect network kit that I already have in my lab. Right now, I’m thinking OSPF, BGP, Spanning-Tree as an unambitious start, and moving from there to using the declarative interface and REST interfaces to see how I can incorporate it into project one.

Thoughts on 2015

2015 was a good year. As an industry, I think we’ve made some great gains in general. The whole “Is SDN really a thing?” conversations seem to be over and we’ve moved on to “ I don’t care what you call it, what does it do for me?” conversations are starting to really get interesting. The projects with value are starting to separate themselves from the science fair exhibits and it looks like parts of the networking profession are finally past the out-right denial and have reached the bargaining stage ( “ Can someone else write the scripts for me? Please? )

I’ve been able to make forward momentum in all the areas I wanted to and I’m generally where I thought I was going to be at the start of the year.

Looking forward to 2016!

@netmanchris

Installing OpenSwitch

First, disclaimer: I’m an HP employee. HP’s a major contributor to the OpenSwitch project. Just thought you should know in case you think that affects my opinion here.

If you need more info on the OpenSwitch project, you can check out the first post in this series here.

Getting our hands dirty

This section comes down into three steps, if you don’t follow these steps, you won’t succeed. I’m not going to go into details on these steps as I’m assuming you can figure this out if you found this blog. 🙂

– Install Virtual Box

– Install Vagrant

– Install Docker Toolbox

I’m running OpenSwitch on a Windows box in this case as the documentation covers the ‘IX build. I’m running on this natively on OSX which also means that I’ve got to install the docker toolbox plugin to get docker containesr to work. I’m also assuming that you’ve already installed Virtual Box and Vagrant for the following section.

Installing Vagrant Plugin

From a terminal window, run the vagrant plugin install vagrant-reload command from the CLI. This should show the following output.

Screen Shot 2015 10 20 at 8 28 45 PM

Installing the OpenSwitch Dev Environment

For this section, I’m assuming you have already downloaded the vagrant files from here into your working directory.

Running the Docker Toolbox Plugin

Run the Docker QuickStart Terminal application and wait for the virtual box image to come to a running state. You should be able to see the following

Screen Shot 2015 10 20 at 8 30 50 PM

Vagrant up!

From the terminal, navigate to where you have unzipped the OpenSwitch vagrant files that you downloaded from here. Run vagrant up command from the CLI. At this point some magic happens ( read more on Vagrant here if you’ve never worked with this tool before. Magic is obviously not magic, but I just don’t feel like explaining the whole process in this post. )

On a OSX box, you’re not running as root so you may end up with the following window

Screen Shot 2015 10 20 at 8 33 27 PM

If you hit this, don’t worry, just SUDO it!

Screen Shot 2015 10 20 at 8 36 39 PM

Accessing the OpenSwitch

From the same terminal window issue the sudo vagrant ssh command to be able to access the shell (CLI) of the OpenSwitch.

If you are successful, you should see the following output. Notice the shell has changed to vagrant@switch

Screen Shot 2015 10 20 at 8 39 21 PM

Accessing the network interface

From the vagrant@switch prompt, issue the sudo vtysh command and you will now have access to an industry standard hierarchical CLI like we all know and love!

Screen Shot 2015 10 20 at 8 41 36 PM

My thoughts so far

Getting this up and running has been relatively painless. There were a couple of small things to get it running that were particular to OSX which was not covered on the OpenSwitch quick start guide. Nothing that a little patience and google didn’t help me cover in a few minutes though. The install experience was pretty easy. The guides were pretty accurate and the getting this up and running should be something most of us can follow without much trouble.

OpenSwitch doesn’t have what I would call a robust network stack at this point in time, but we’re still really early in this world. Now that I’ve got it up and running, I’m looking forward to starting to look at the alternate interfaces such as OVSDB and REST as described here.

Anyone else got this up and running yet? Thoughts? Let me know in the comments below!

@netmanchris