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.
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
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.
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
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
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.
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.
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.
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.
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
Ir maybe we had to create the full 4094 VLANs available
Do you remember back in CCNA school when we learned all sorts of great things that we very rarely followed. One of the favourites was that we are supposed to put meaningful descriptions on all of our interfaces so we know what the other side is connected to.
How many people actually follow that advice?
Yeah, I never do it either. There’s always just too many things on the list that need to get done and it seems like that extra 5 seconds it would take me to update the description to the interface just doesn’t seem like it’s worth the effort. Of course, then I later check the port and end up knocking out my XYZ services and cause myself an outage.
This is where a little python and a decent NMS can help to solve a problem.
Before we get into the code. We need to understand a little about ifIndex values and how they relate to the physical interfaces of the devices. If you’re REALLY interested, you can do some reading in RFC 2863. But in a nutshell, each interface on a device, whether physical or logical has a specific numeric value assigned to it which is the last digit in the interface statistics that can be seen through the SNMP interfaces. This is commonly known as interfaces group stats.
There are a bunch of different tables in the interface group stats that are used to store specific kinds of information or statistics for the interfaces such as
- ifNumber (.18.104.22.168.22.214.171.124.0) – Which is the total number of Interfaces
- ifIndex ( .126.96.36.199.188.8.131.52.1.1. * ) – Which acts as a primary key for all the other interface group stats.
- ifDescr (.184.108.40.206.220.127.116.11.1.2.* ) – Which is the name of the interface
- ifType (.18.104.22.168.22.214.171.124.1.3.* ) – Which describes the type of the interface
- ifMTU ( .126.96.36.199.188.8.131.52.1.4.*) – Which shows the current MTU size configured on the interface
- ifSpeed (.184.108.40.206.220.127.116.11.1.5.*) – Which shows the current speed of the interface
- ifPhysicalAddress (.18.104.22.168.22.214.171.124.1.6.*) – Which shows the mac address of the interface
- ifAdminStatus (.126.96.36.199.188.8.131.52.1.7.*) – Which shows the current admin status of the port
- ifOperStatus (.184.108.40.206.220.127.116.11.1.8.*) – Which shows the current operational status
There’s a bunch more which you can see here if you’re interested, but one that I found particularly fun was the ifAlias ( .18.104.22.168.22.214.171.124.1.1.18.* ) which actually corresponds to the description command in your friendly neighbourhood network operating system
So when your interface is configured like this
The ifAlias value for the corresponding ifIndex looks like this
The Fun Begins
The interesting part about the ifAlias value is that it’s actually a SET-able value through the SNMP interface. That means that if you have a simple piece of python code like the following
It will allow you to run a little command like this >>> set_interface_description(‘10.101.0.221’, ‘1’, ‘Changed This’ ) which will result in the following.
So this is cool, right? We’ve just programatically changed a single interface description on a interface. We could stop here and you would be left with a
“So what? Why would I go to the trouble of doing that. It’s harder than just typing in the description manually!”
But wait! There’s more…
The really cool part about automating something so simple is that now we have a building block that we can do something with. For those of you who might have seen the HPE Intelligent Management Centre, you may already be aware that the topology map does this really cool thing where it actually creates a table of all of the links within a given custom view and automatically creates link-names for them.
You’ll notice that the auto-generated Link-Name actually tells me who’s connected to both sides of that link. You’ll also notice that I have the left and right nodes ( with the IP address ), as well as the left and right interfaces. And “yes”, there is an API for this where it’s all represented in a nice little JSON string which can be easily parsed in your favourite IDE.
Time vs ROI
The reason we don’t label interfaces is that most people feel it’s just not worth the effort to keep them up to date. Things change too often and it’s just too easy to say “it’s not that important” and move on before changing that description. I’m with you. I’m as guilty as everyone else on this. But with the help of a little code, a good NMS, the entire process is now automated.
I can proudly say that, for now at least, my lab is 100% accurate as far as interface descriptions go. And because the whole thing is totally automated, I simply re-run the script overtime I make some changes.
So for those of you who weren’t aware. Yes, there is someone who actually uses SNMP SETs in the world. 🙂