An OpenFlow implementation for OpenBSD

With the MP network stack overhaul it became obvious that OpenBSD's bridge(4) needs some updates. It wasn’t built for a MP networking stack and before anyone talked about “virtual switches”, flow tables, or split data and control planes for such things. People were looking into supporting “Open vSwitch” (OVS), but the costs of adding the complex kernel layer of OVS to OpenBSD was just too high and with questionable licensing. So we were reconsidering further modernizing bridge(4). I came up with a simple idea: we don’t need it or another virtual switch, we just need a controller to offload the “control plane”. OpenBSD is already doing bridging, VXLANs, VLANs, STP, routing domains and many other things in the kernel, so why should we move it to yet another complex daemon? All we need is a controller daemon and a well-defined, pluggable interface to handle the forwarding decisions from bridge(4) in the daemon and the Cloud: OpenFlow.

Fortunately, I had started such a simple, privilege separated OpenFlow controller some time ago, but I have never released it because it wasn’t complete, not comparable to any of the “big” controllers, and I didn’t have an actual use case in OpenBSD for it. It only provided a simple learning switch that works with Open vSwitch or OpenFlow-enabled HP (HPE) switches. I also didn’t find a satisfying name for it, as “OpenFlow™” is an open protocol but also a very strict trademark and calling it openflowd would violate their trademark policy. I don’t use funny or pet names for software, and OpenWolf or sdnflowd simply didn’t work, but now I could simply rename it to “switchd(8)”. Following the idea of using the OpenFlow protocol itself as our new kernel interface, Yasuoka@ and Goda@ worked on “bridgeofp” and managed to get it working as a simple layer 2 switch. We’ll need it for many things, including the distributed virtual switching for vmd(8) and to facilitate OpenBSD in the SDN.