Open vSwitch 101

I’ve written in the past about how the virtual switch is an SDN war zone.  Well, it still seems to be the early days for Software Defined Networking (SDN) no matter how much time goes by and I realized there isn't a whole lot of documentation out there, especially for the new guy or gal on the block, when it comes to Open vSwitch when compared to the vendor offerings from Cisco and VMware.  Over the coming weeks, I’m going to hope to write more about Open vSwitch, Linux networking, and Open Stack Networking (Neutron, formerly Quantum).  On that note, this post is meant to be an easy to read, longer than expected, concise introduction to Open vSwitch (OVS).

If there is any information that is incorrect or should be updated, please let me know.  I do not hide the fact that I’m new to Open vSwitch myself.

If you’re even reading this blog, you’ve probably at least heard of Open vSwitch.   Yes, it is an open source virtual switch.  And when comparing it to the Cisco Nexus 1000V, the VMware standard (local) vSwitch, or the VMware distributed vSwitch, it is really more like the VMware standard switch.  There is no central controller, configuration manager, or virtual supervisor module coordinating between Open vSwitches on different physical hosts.  It can run on Linux based hypervisors including KVM, Xen, Virtual Box, etc.  Check out the official FAQ for all that it supports.

From an architectural standpoint, there are three main components of Open vSwitch.

• Kernel module (Fast path) – I would equate the kernel module to ASICs on a hardware switch.  It is where all of your packet processing takes place, i.e. data plane.  The Virtual Ethernet Module (VEM) in the Nexus 1000V would be comparable to the kernel module in Open vSwitch.
  

• vSwitch daemon (ovs-vswitchd) – also called a controller in some documentation, is the Linux process that runs in user space (not the kernel) that dictates how the kernel  module will be programmed – think of this as a locally significant control plane.  This daemon runs on every physical host.  Because I am seeing this called a controller in some docs, it is important to understand, this is not a SDN or OpenFlow controller by any means and it’s just a controller in the sense that it controls a local data plane module.  Update:  See discussion in the comments section below on ovs-switchd not being a control plane, but rather an extension of the data plane.

• Database Server – More officially, it is called the Open vSwitch Database (OVSDB) server.  If you choose to run the vSwitch daemon, you will need this database.  This is the database that will store all of your cool and working configurations.  Luckily this isn’t OpenStack and you don’t need to go out and learn MySQL or anything like that (I kid, I kid).  This server uses JSON for its database schema and it communicates externally and to the vSwitch daemon using a management protocol, namely OVSDB, which is using JSON-RPC.
  

Below is a high level view of the various components just described.  The control cluster shown at the top is not part of Open vSwitch (OVS) natively.  That would be an add-on, likely not open source, to allow far greater scale.

Source: http://openvswitch.org/slides/LinuxSummit-2011.pdf

Aside from the general architecture, here is some other good information worth pointing out.

• You actually don’t require the vSwitch daemon to use the OVS kernel module.  If this tickles your fancy, you’ll be left with a dumb data plane that can’t even perform MAC learning.  Remember, the vSwitch daemon is the control plane of this switch.  But, you can use an OVS utility called ‘ovs-dpctl’ to manually program flows directly to the kernel.  You should only use this utility if you are not running the vSwitch daemon.  Update:  See discussion in the comments section below on ovs-switchd not being a control plane, but rather an extension of the data plane.

• You do need the OVS kernel module, or some form of it, to run the vSwitch daemon.  This kernel module can run in user space as well still serving as the data plane.  It may be required if the hypervisor doesn't natively support OVS.

• You do need the OVSDB-server to run the vSwitch daemon. 

• If you aren’t using a management platform that currently uses the OVSDB protocol to communicate with the OVSDB-server to centrally manage OVS instances, which you are probably aren’t, unless you are using a VMware/Nicira solution, you can use an OVS utility called ‘ovs-vsctl’ to manually configure Open vSwitch.  Using this tool is directly interfacing with the OVSDB-server.  The db server directly updates the vSwitch daemon.   You can also use a utility called ‘ovs-ofctl’ to configure flows when using the OVS daemon and kernel module.   ‘ovs-ofctl’ is a general utility, not just for OVS, which can be used with any OpenFlow switch.

• As I previously stated, the vSwitch daemon is not an OpenFlow/Controller, but guess what, it has the ability to speak OpenFlow.  This is how OVS plugs into SDN environments – each vSwitch daemon would communicate to the kernel module (southbound) and to an OpenFlow controller (northbound).  But in reality OpenFlow is the southbound protocol of the controller being used.  Confusing terminology if you aren't good with directions like me :).  Just having fun and consider this your gas station.

• A single vSwitch daemon can control multiple logical and independent switches/bridges on the same physical server.  This would be the same as multiple VMware vSwitches on a single host.

• Upon booting up a physical server, switch configurations are pulled from the OVSDB-server and into the vSwitch daemon – then the kernel module is programmed from this data.

• Many of the start-ups bringing in all of the VC money in the network virtualization space are using Open vSwitch, but in different forms.  This includes using all three components of OVS, but with vendor-specific extensions for added functionality – call this OVS++, but others only leverage the data plane module (in kernel and/or user space), and then fully write their own equivalent to the vSwitch daemon and OVSDB-server.  
  

I hope to write more soon on related topics.  If you have any specific questions, feel free to write in and we can explore together.

Follow up post going into a bit more detail: Open vSwitch 201 & 301

Thanks,
Jason

Twitter: @jedelman8