Note: This article was originally published here.

Before moving on the next post to continue our saga of OpenSwitch Simulations with GNS3, I wanted to take a quick deviation to document a subject that gets a lot of attention these days: P4.

In case you have been missing all the action around P4, the 30,000 feet view is that it’s a language to describe forwarding pipelines (and no, it’s not the same as OpenFlow, that is useful for programming entries in almost-always-pre-defined pipelines). One of the (many) nice things about this is that you can potentially ‘compile’ your pipeline definition into an executable program that provides a functional simulation of a P4-based ASIC. Did I mention the tools for doing all of this are available as open source?

What does P4 has to do with OpenSwitch?

Note: This article was originally published here.

In the previous post I covered the basics about setting up the OpenSwitch Appliance using GNS3. The setup was fairly simple: two switches connected to each other and exchanging LLDP packets. In this post we will setup a more elaborate network to simulate a DC fabric (although it may be a bit overkill of a setup). The setup will be the basis for the next posts about configuring this fabric using Ansible.

One of the first questions when setting up a complex topology with GNS3 that most people will do is: how do I connect it to the external world outside of the simulation? For VirtualBox machines that we are using, the options are limited. The one I found to work reliably across platforms was to use a NAT connection. This has the disadvantage that we have limited connectivity from the external world toward the internal network, but this could be also a security advantage to prevent accidental propagation of control protocols from our simulated environment.

Since the purpose of this lab is going to be to play with Ansible, we are going to need a Linux machine to run it. So, we will setup the following network:

Let’s elaborate on the setup details:

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?

Note: This article was originally published here.

One of the purposes when we designed the build system in OpenSwitch, was to make it possible to develop on as many environments as possible. If you have some background with developing networking firmware, the typical developer love to have this VM where everything works perfectly, but makes it impossible to work in your laptop at 30000 feet. This is not really a sin (as long as you can have the VM hosted in your machine), but the problem is that usually is some IT team on charge of the VMs setup, and the deployment is not handled by some automated/version-controlled code.

So for OpenSwitch, we aimed to at least document the requirements and steps for manual setup of your environment. You can read this page to get your Linux machine to ready it for OpenSwitch development.

So, why to write an article about my particular setup? Well, I’m a Mac user, so in this article I’m going to detail my setup using a OS X host with a Linux VM. This provides some nice tricks that makes your workflow easier if you are using a similar setup. I will also explain the rationale of the setup.

My use of Linux VM for development is mostly thru the Linux CLI and I use NFS to share files between my Mac and Linux. This allows me to use any graphical tool from the Linux VM if I have to, but also to use tools from the host without major hurdles.Read more…

Setup the VM

Today I’m jumping into water to start writing about some area where I have some half-decent background: the intersection of Open Software/Hardware and Networking.

Why?

You see, I’m a software guy. The pragmatical Linux/OpenSource fanboy kind. What that means? I have a formal degree on Computer Science, and wrote Linux drivers and software for embedded systems for 8 years. But I’m also a pragmatical guy: I know how to write kernel drivers, but I use a Mac laptop every day because I like things to work. For the last 4 years I have been learning a big from networking at Hewlett Packard Enterprise, where I have worked on networking (SDN, ASICs), and more recently on the OpenSwitch project.