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?

Well, as I mention in previous posts, OpenSwitch provides a simulation environment that provides a software data path for testing and training purposes, and we package it as either container or VM appliance. So far the default software data path is provided by running an stock OpenVSwitch that’s under control of the switchd plugin for simulation.

However, since Barefoot Networks is a contributing member to the OpenSwitch project, they have been adding support for using a P4 backend that allows replace the simulation ‘ASIC’ to a P4 functional model of an ASIC. Some details about it can be found in their presentation from the last OpenSwitch Meetup (if you are interested on OpenSwitch, there were several interesting presentations on that Meetup. You can watch them here).

Since OpenSwitch is not married to a particular interface for the ASIC SDK (reports otherwise are greatly exaggerated!), the P4 backend provides a native plugin for switchd to use their ‘PD’ APIs directly.

Shut Up and Take my Bitcoin!

OK, OK, how to run with the P4 data path? OpenSwitch still doesn’t provide P4 periodic images, so you have to build the code yourself. These are the steps you need to do to flip into the P4 backend (assuming you already have a working build environment for either container or appliance):

1
2

rm -Rf build/tmp # Flush file system dependencies
echo "EXTRA_IMAGE_FEATURES += \"ops-p4\"" >> build/conf/local.conf

Now, run ‘make’ and go for a coffee while the image get’s build. It wasn’t that hard, was it?

One more thing™, if you are using the appliance environment, verify your code already includes this commit, or otherwise cherry-pick the change.

How to use the P4-based Image?

Pretty much the same way that you use the regular simulator image. If you are using the P4 Image with GNS3, you can download this special edition stencil I did for it.

One interesting fact that you may notice when using the P4 simulator, is that control packets into the CPU have higher latency. This is caused because the PDUs are going thru a TAP device from the switch process (in userspace) into the netdev interfaces in the SW namespace.

Final thoughts

This kind of experimentation wasn’t possible a couple years ago, and software stacks like SAI and P4 are changing the landscape along with OpenSwitch. Think that you can change the forwarding data path implementation, rebuild the simulator, and integrate back again with your NOS stack! is mind boggling.

So, indeed, ‘software is eating the world’. Happy hacking!

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:

• The ‘Internet’ cloud is a GNS3’s cloud element, that I configured with a NAT entry that I named ‘nat’. The name doesn’t really matter, as GNS3 just need to see a NAT interface on the cloud element, so that the connection to the VM called ‘ubuntu-netlab’ is configured using VirtualBox’s NAT networking.
• The ‘ubuntu-netlab’ is a virtual machine that have Ubuntu 16.04 Server installed on it (instructions about this setup below). This VM will have two NICs: one attached to the NAT connection and another one to the SW1 that will be the management network of the switches. What we will be doing with this machine? Several things:
  • Run a DHCP server to provide IP connectivity to the management network
  • Run a DNS relay to minimize disruptions on the configuration (I may be roaming between home/office).
  • You may optionally configure IP masquerading (aka NAT) on this box to allow the OpenSwitch boxes to reach the external world, but is not really required.
    You may be wondering why not connect the management switch directly to the NAT port on the cloud element? I tried this, and found the DHCP server shipping in VirtualBox was not really good, and sometimes will assign the same IP address to different boxes if restarted at a given time (bug with the leases?)
  • We will install Ansible on this box, and use it as control machine to configure the fabric
• The SW1 is a GNS3' ethernet switch with 8 ports. One will be connected to the Ubuntu VM, and the other ports to each of the management ports of the OpenSwitch boxes.
• We will use 5 OpenSwitch boxes to create a simple datacenter fabric. I’m calling them spines/leaves for convenience, but I will do examples with plain L2, and other L3 topologies that may not be a CLOS.

So, let’s get started with the setup!

Setup the Management Network

You should start by dragging a cloud element and configuring it to have a network interface of type NAT:

Now we need to create the template for the Ubuntu VM that we will connect to it.

Configuring the GNS3 Template for the Ubuntu VM

As I mention, we will be using an Ubuntu 16.04 (state of the art!) Server VM. Don’t worry, you won’t have to install it. I have pre-package it into a nice OVA (sorry tested only with VirtualBox, you may need to do some work if want to use VMware). Download it from here.

Importing the Image

After downloading the OVA file, import it into VirtualBox, and then proceed to create a template in GNS3 for the machine like we did for OpenSwitch in the previous post. Here is the summary of the steps and configuration:

• Preferences -> VirtualBox VMs -> New
  • Select the machine you just imported
  • ☑︎ Use as linked base VM
• After created click on ‘Edit’
  • ‘General settings’ tab:
    • Template Name: ubuntu-netlab
    • Default name format: {name}-{0}
    • Symbol: :/symbols/vbox_guest.svg
    • Category: End devices
    • RAM: 512 MB
    • ☑︎ Enable remote console
    • ☐ Enable ACPI shutdown
    • ☑︎ Start VM in headless mode
    • ☑︎ Use as a linked base VM
  • ‘Network’ tab:
    • Adapters: 2
    • First port name: leave empty
    • Name format: eth{0}
    • Segment size: 0
    • Type: PCNet-FAST III (Am79c973)
    • ☑︎ Allow GNS3 to use any configured VirtualBox adapter

Now you can drag an instance of it into your project and setup the connections as detailed previously. This image is configured with serial port console enabled, so after starting the VM, you can open the console from GNS3 and get access. The default user/password is ubuntu/ubuntu.

Setting up the Ubuntu VM

Initial Setup

Now that you have access to the console, let’s do some initial setup. First you may want to tell the serial terminal the size so that the output is not messed up. In my case I just sized my console window to 120 columns and 35 lines (I use the OS X Terminal app, and the tittle usually says the dimensions):

1

stty cols 120 rows 35

Next we want to install the latest software updates for this image:

1
2

sudo apt update
sudo apt upgrade

Network Setup

Next, we want to configure the second network interface facing towards SW1. You will have to run the ifconfig command to find the name of the second interface:

1

ifconfig -a

On this case my second interface is called enp0s8. I will then configure the interface to an static IP address and bring the interface up:

1
2
3
4
5
6
7
8
9
10
11
12

sudo su -
cat <<EOF >>/etc/network/interfaces

auto enp0s8
iface enp0s8 inet static
   address 192.168.1.1
   netmask 255.255.255.0

EOF
exit #leave sudo

sudo ifup enp0s8

DHCP Server and DNS Relay

Next we want to install the DHPC server and DNS relay (DNSmasq)

1

sudo apt install isc-dhcp-server dnsmasq

Then proceed to configure the dhcp server modifying the file /etc/dhcp/dhcpd.conf with your favorite editor (if you are not a vim expert, the nano text editor could be easier). This are the contents you will need:

1
2
3
4
5
6

option domain-name "dc-lab";
option domain-name-servers 192.168.1.1;
subnet 192.168.1.0 netmask 255.255.255.0 {
  range 192.168.1.10 192.168.1.50;
  option routers 192.168.1.1;
}

Now you can start the server:

1

systemctl start isc-dhcp-server

IP Masquerading (NAT)

If you want the OpenSwitch boxes to have access to the external network over the management port, you may want to enable IP masquerading on the box. Adjust the following script to the name of your network interfaces:

1
2
3
4
5
6

public_if=enp0s3
private_if=enp0s8
sudo -E iptables -t nat -A POSTROUTING -o $public_if -j MASQUERADE
sudo -E iptables -A FORWARD -i $public_if -o $private_if -m state --state RELATED,ESTABLISHED -j ACCEPT
sudo -E iptables -A FORWARD -i $private_if -o $public_if -j ACCEPT
sudo sysctl -w net.ipv4.ip_forward=1

Setting up the Fabric Switches

Now that we have the Cloud element and the Ubuntu VM, you need to drag the GNS3 ethernet switch element to connect the second interface from the Ubuntu VM with it, along with all the management ports of the OpenSwitch instances. You can now proceed to power up the OpenSwitch instances and login into their consoles (user/password is netop), and verify the management interface got an IP address from our control VM:

1
2
3
4
5
6
7
8
9
10

switch# show interface mgmt 
  Address Mode : dhcp
  IPv4 address/subnet-mask : 192.168.1.11/24
  Default gateway IPv4 : 192.168.1.1
  IPv6 address/prefix : 
  IPv6 link local address/prefix: fe80::a00:27ff:fe3a:efdd/64
  Default gateway IPv6 : 
  Primary Nameserver : 192.168.1.1
  Secondary Nameserver : 
switch#

You may also test login with user root (no password) into a bash shell and the networking of the management domain should be able to reach the external network.

Next Steps

Now that we have a management network up an running, we want to configure the fabric to move packets around. At this point most networking engineers will log into the CLI and start configuring, but we went thru all this setup of a management network to do something more interesting…

In our next post we will do this instead using Ansible, which is a pretty good tool for managing cattle.

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:

1

# 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:

1
2
3
4
5
6

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:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

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!

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

The first step is that I will use VirtualBox to deploy my Linux VM. You can use any software that you want, but VirtualBox is free and available to any developer, so it’s a good target.

Since I’m using a Macbook Pro Retina with a i7, I will use the following setup:

• 6 Cores: the Yocto build system can take advantage of the multicore environment, so the more cores, the faster builds. This leaves 2 cores idle for my Mac, so performance doesn’t suffer.
• 4Gb of RAM: A full from-scratch build of the compiler (rare, since we use Yocto’s shared states) can consume quite a bit of RAM.
• 20GB of disk: the build directories from Yocto could be big, averaging 6G each, but the figure could easily go up depending on what you are doing. So having some disk space to spare is a good measure (I personally ran with 160GB)
• Two network interfaces:
  • First one will be NAT, so that I can reach the internet independent of the network connection on my Mac (sometimes I use wireless, sometimes I use a thunderbolt dock station).
  • Second one will be host-only adapter, this provides a internal network so that we can easily communicate between the VM and the host. Using multicast DNS (aka Bonjour), we won' even have to worry about IP addresses on this network.

For this VM, I will be using Ubuntu LTS 14.04 Server ISO. Right now OpenSwitch works best with this version of Ubuntu (and provides faster build times). We hope to update to the new LTS soon and once we do, I will update this post to reflect that. Update: I have added comments about how to make it work with Ubuntu 16.04!.

I’m assuming you are familiar with installing an Ubuntu ISO into a VM and will omit those details. The only important detail from the installation would be to install the SSH server. I would recommend that you setup your user account with the same user id that you have in GitHub (this is a good moment to create one, if you don’t). Using the same user account makes life easier with gerrit, but is not an strict requirement.

Proxy Setup

If you are behind a corporate firewall, be sure to setup your corporate proxies in your user environment:

1
2
3
4
5

cat <<EOF >>~/.profile
export http_proxy=http://your.proxy.com:port
export https_proxy=http://your.proxy.com:port
EOF
source ~/.profile

If my case, I may be roaming between the office and home, so sometimes I don’t use a proxy, in which case I find easy to unset the variables and be able to work. So, I don’t like to wire the apt configuration with the proxy as explained here, instead I like to run the apt-get command with ‘sudo -E’ parameter so that it inherits my environment variables and uses the proxy if I have it defined.

Initial Setup

First, I usually disable asking password for my user:

1

sudo visudo -f /etc/sudoers.d/passwordless-user

Then enter a line like the following (replace your username):

1

username ALL=(ALL) NOPASSWD:ALL

Next, let’s update the apt package cache:

1

sudo apt-get update

Networking Setup

The initial installation will configure the machine out of the box to have DHCP on the first network interface, so we will need to add the second interface for automatic startup. So I will add the following lines to /etc/network/interfaces:

1
2

auto eth1
iface eth1 inet dhcp

Then, bring the interface up:

1

sudo ifup eth1

Update: if you are using 16.04, the network interfaces have different names (to understand why and revert it if you want, take a look here). Run ‘ifconfig -a’ to find the name of your interfaces.

Next, proceed to install some extra packages and configurations that make networking work better.

dnsmasq: the build system fetches constantly from the servers in order to use the shared states to speed the build. So using a local DNS cache will help reduce the pressure on your DNS (and may save you from raising flags about the high rate of request your machine will be doing).

1

sudo apt-get install dnsmasq

Update: if you are using 16.04, dnsmasq won’t work out of the box since it conflicts with the dnsmasq used by the LXC container daemon. I worked around by disabling LXC (but maybe that solution doesn’t work for you):

1
2

sudo systemctl stop lxc lxc-net
sudo systemctl disable lxc lxc-net

nss-mdns: this is the name service resolution to use multicast DNS. This allows the Linux machine to resolve (and as side effect of dependencies, advertise) .local addresses and makes communication with the Mac simpler.

1

sudo apt-get install libnss-mdns

After this is installed, you should be able to reach your machine with the .local name. Lets say your Linux machine is named linuxvm, then you should be able to run from your Mac:

1

ping linuxvm.local

Headless VM

After the initial networking setup is ready, I like to run the VM in headless mode from the OS X terminal. To do that, I shutdown the VM from the VirtualBox UI and close the application. Then from an OS X Terminal I can start the VM in the background with (replace the LinuxVM name with the name of your VM:

1

VBoxHeadless --startvm LinuxVM --vrde off &

This will run on the background and as long as you don’t close the terminal, the VM will run. Next, I usually connect to the VM from the terminal with (using the mDNS .local resolution):

1

ssh -Y username@linuxvm.local

The -Y automatically exports X11 apps into my Mac XQuartz, in case you want to use some graphical program from Linux.

OpenSwitch Development Environment Tweaks

Create a workspace directory on /ws. This is just an standard I follow of putting all my work on a separate directory. Makes easier to fine-control the NFS exports from my Linux machine into my Mac host.

1
2

sudo mkdir /ws
sudo chown $USER /ws

NFS Server Share Setup

Installing an NFS server with the proper parameters to allow easy sharing of files between the host an the Mac took me several hours of research. Here is the recipe for it.

Install the NFS server daemon:

1

sudo apt-get install nfs-kernel-server

Configure the /etc/exports file with the following line to allow your Mac host to access the files under /ws with the same user permissions as your Linux user (assuming your user ID is 1000, you can find that with the ‘id’ command).

1

/ws 192.168.56.1(rw,all_squash,anonuid=1000,anongid=1000,sync,no_subtree_check,insecure)

Start the NFS server:

1

sudo service nfs-kernel-server start

Update: if you are using 16.04 use systemctl instead of service, and the service is called nfs-server:

1

sudo systemctl start nfs-server

At this point you should be able to mount the NFS directory from your Mac, by going to the Finder Menu Go -> Connect to Server… (or using the ⌘k shortcut). On the server address box enter:

1

nfs://yourmachine.local/ws

That should get your Mac access over NFS to the directory /ws and will have the right permission mapping so that files could be changed either from the Linux or Mac environment without permissions conflicts.

Install Docker

We are going to be using docker, so we need to install it following the instructions here.

If you are using a proxy, you need to setup it up for the docker daemon on /etc/default/docker:

1
2

export http_proxy=http://your.proxy.com:port
export https_proxy=http://your.proxy.com:port

Then, restart your docker to make the changes take effect:

1

sudo service docker restart

Prepare for OpenSwitch Build Environment

Install the minimal required packages for OpenSwitch development:

1

sudo apt-get install gawk wget git-core diffstat unzip texinfo gcc-multilib build-essential chrpath screen curl device-tree-compiler git-review

OpenSwitch leverages Yocto’s shared-state system, so we want to have a global shared state directory that is shared across all the development environments to speed build time. The OpenSwitch build system will get this information automatically from a variable environment, so I will put it on my profile by default:

1
2
3
4

sudo mkdir /ws/openswitch-sstate-cache /ws/openswitch-downloads
sudo chown $USER /ws/openswitch-sstate-cache /ws/openswitch-downloads
echo -e "export SSTATE_DIR=/ws/openswitch-sstate-cache\nexport DL_DIR=/ws/openswitch-downloads" >> ~/.profile
source ~/.profile

Git And Gerrit Setup

Setup some initial git setup for working with OpenSwitch Gerrit. You will need a GitHub account in order to login into gerrit, so I will assume you already have one, and you know how to upload your ssh key into gerrit. You will also need to sign a DCO when signing for Gerrit, otherwise won’t be able to upload code for review (if you are going to contribute as part of your job, you need to follow the steps on the OpenSwitch page to get your employer to sing a corporate contribution agreement).

First, setup git (I like to use colors, and use st as an alias for status):

1
2
3
4

git config --global user.name "John Doe"
git config --global user.email johndoe@example.com
git config --global alias.st status
git config --global color.ui auto

If you are working behind a corporate firewall, it may be that gerrit ports (29418) are blocked. You can test a telnet connection into the port to confirm if you are blocked. A workaround this restriction is to install socat and use a proxy for the ssh connection:

1
2
3
4
5
6

sudo apt-get install socat
cat <<EOF >>~/.ssh/config
Host review.openswitch.net
    IdentityFile ~/.ssh/id_rsa
    ProxyCommand socat - PROXY:your.proxy.com:%h:%p,proxyport=<port>
EOF

If your github username is different from the username in your machine, you may want to configure git to use the right username when doing git reviews:

1

git config --global gitreview.username <username>

You can verify your connection to gerrit works by issuing this command and getting a similar output:

1
2
3
4
5
6
7
8
9
10
11
12

ssh -p 29418 <username>@review.openswitch.net
  ****    Welcome to Gerrit Code Review    ****

  Hi John Doe, you have successfully connected over SSH.

  Unfortunately, interactive shells are disabled.

  To clone a hosted Git repository, use:

  git clone ssh://<username>@review.openswitch.net:29418/REPOSITORY_NAME.git

Connection to review.openswitch.net closed.

Building OpenSwitch

Finally, I’m going to clone the OpenSwitch build system, and build an appliance image that I would use in my next post about working OpenSwitch with GNS3.

First I clone the build system:

1
2
3
4

git clone https://git.openswitch.net/openswitch/ops-build ops-appliance
cd ops-appliance
make configure appliance
make

Now you can sit a wait for the build to complete. If you have a fast internet connection it will take in the order of 15 minutes to download all the caches and sources to build a full OpenSwitch Virtual Appliance. In my next post we will be using that.

Conclusion

I hope the information is useful. Drop me a comment if you think there is any improvement I can do to the environment.

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.

Why start writing about the intersection of Open and Networking? These are interesting times in the networking world: disaggregation, open source, open hardware, etc. All of this is pretty new for the networking world, and is specially different because in the old good days you will have limited information about the technical details of what is going on behind scenes on your network. Now sharing the knowledge is critical. I have been inspired by reading blog entries from many in the networking community, and I’m by no means close to have the expertise of guys like Ivan or Greg, but I think I can contribute to spreading the knowledge on the little things that I do know. Hope my readers agree.

Stay tuned for some posts soon. I will be writing quite a bit about OpenSwitch, but also random thoughts on different areas about Open + Network.