I've been writing some OpenFlow Controller code to get a feel on how OpenFlow works. As I get into it, I've been wondering if what I want to do is quite correct. Open vSwitch has various extensions available, which may or may not be available via the OpenFlow standards. So writing code conforming to something like OF 1.4.1, will I be able to gain access to those extensions, or will I need to access Open vSwitch differently? Not sure. More research is needed. These links track some of that research.
First off, there are libraries in OVS for tracking BFD by watching a vswitch table. Also, there is an lldp encoder/decoder.
From an OpenFlow perspective, there is a tutorial called Open vSwitch Advanced Features, which shows, via the command line tools, how to use multiple flow tables to build a simple learning switch. That documentation makes reference to some extension files:
- include/openvswitch/meta-flow.h
- include/openflow/nicira-ext.h
So, the question is, how to make use of those extensions via an API? Support for that question may start at the
Integration Guide for Centralized Control.
Design Decisions In Open vSwitch has various comments on: what a master sees vs a slave, talks about v1.4 bundles and transactions, clarification on vlan matching in the various versions, and talks extensively about in-band and out-band control.
The FAQ Using OpenFlow talks about: hidden flows and how to dump them, how to set out-of-band mode, how to get a list of port numbers as they associate to interface name, and how to adjust mtu on internal interfaces.
The General FAQ talks about the current standard ports as of OVS 2.4:
- 6653 (was 6633) - OpenFlow
- 6640 (was 6632) - OVSDB - which is what I need to investigate for the OVSDB protocol API
OVS with KVM talks about starting up a KVM guest and connecting it via a couple custom scripts to the network. libvirt can also play nicely with OVS.
Bash Completion is Available with
- ovs-appctl-bashcomp.bash
- ovs-vsctl-bashcomp.bash
Tracing explains how to test the series of flow table entries against a sample packet.
For each OpenFlow version, there is a separate header. The same directory has headers for extensions as well.
On the documentation page, some interesting entries:
- ovs-vswtichd.conf.db - describes the OVSDB tables - can flows be inserted via the flow table?
- ovs-vswitchd - desribes the primary service, and has detailed examples of related client commands ovs-ofctl, ovs-vsctl, ....
- ovs-fields - is an important document describing match and action fields, whether they are openflow standard or ncira extensions, and some are just OVS based.
- ovs-dbclient - can be used to dump tables in OVSDB - so use this to check flows once a controller has been activated
I found hints at Getting Started With OVSDB for getting JSON out of some of the command line utilities. It also alludes to an OVSDB method specification. It also talks about the ability to 'monitor', which is what I'm looking for from a BFD scenario (if I don't implement that myself from a packet_in / packet_out perspective).
I get closer by looking at All About the OVSDB Server by describing non OVS database uses.
That article references RFC 7047 which talks about the database generically. It says JSON is being used for the schema format and for the wire protocol format. So, by using looking into the tables and fields, it should be possible to come up with the appropriate JSON structures and commands to perform the necessary updates without the use of OpenFlow.
Understanding Hardware VTEPs shows some ways of composing and transmitting JSON via the command line to the database.
On the Presentations page, for troubleshooting, "OVS Deep Dive" and "Debugging OVS" are useful.
OVS-Cheat-Sheet has the following useful diagram:
+---------+ +-----------+
|ovs-ofctl| |sFlow Trend|
+----^----+ +-----^-----+
| | Remote
+-----------------------------------------------------------------------------------------------+
| |
| sFlow |
| | +---------+ +----------+ +---------+ +------------+
| | |ovs-dpctl| |ovs-appctl| |ovs-vsctl| |ovsdb-client|
| | +----+----+ +------^---+ +-----+---+ +-------^----+
| | | Command | | Config | DB operation
| | +----v---------------v--+ Unix socket +----v---------------v-+
| +--+ +---------------> |
|OpenFlow | ovsdb-vswitchd | | ovsdb-server | +----------+
+---------------+ <---------------+ | |ovsdb-tool|
+-----^------------+----+ Apply changes +------------^---------+ +----+-----+
| | | |
| | | |
| | +-----v-----+ |
upcall(netlink)| |netlink | ovsdb <----------+
| | +-----------+
+-----------------------------------------------------------------------------------------------+
| | Kernel space
+-----+------------v------+
|Openvswitch kernel module|
+-------------------------+
Open vSwitch Cheat Sheet has another useful cheatsheet of commands.
Matt Oswalt has a couple of relevant OpenFlow related articles:
- Storage Traffic Magic with OpenFlow where he talks about a now defunct storage company Coho Storage using OpenFlow to steer requests and responses in and out of appropriate nodes by appropropriate mac address mangling.
- [SDN Protocols] Part 2 - OpenFlow Deep-Dive where he provides a good overview of OpenFlow tables, pipelines, write actions, action sets, as well as proactive vs reactive flow instantiation.
When getting into network discovery, Discovery in Software-Defined Networks talks about using LLDP (Link Layer Discovery Protocol) as well as BDDP (Broadcaset Domain Discovery Protocol) packets. BDDP packets can be used to discover non-LLDP responding switches, or switches not part of an SDN managed domain. The article suggests discovery packets on 5 second intervals.
