OVS Deep Dive 0: Overview
In this OVS Deep Dive series, I will walk through the Open vSwtich source code to look into the core designs and implementations of OVS. The code is based on ovs 2.6.1.
1. WHY OVS
The official doc WHY Open vSwitch describes how OVS emerges and what problems it aims at solving. But the explanation is very high-level and abstract. I bet you need years of virtualization and networking experiences to understand what it’s saying.
Instead, I highly recommend the following materials to new comers of OVS:
2. OVS Architecture
Fig.2.1. OVS Architecture (image source NSRC)
OVS is usually used to bridge up multiple VMs/contaiers within one host. Such as, in OpenStack compute node, it is used as integration bridge to connect all the VMs running on the node. It manages both physical ports (e.g. eth0, eth1) and virtual ports (tap devices of VMs).
As depicted in Fig.2.1, OVS is composed of three components:
- user space program, ovs deamon
- user space program, database server of OVS
- kernel module (datapath)
- kernel space module, OVS packet forwarder
vswitchd is the main deamon process of OVS,
ovsdb-server is the database server of OVS, and
datapath is a kernel
module that performs platform-dependent packet
forwarding. After OVS started, we could see two services:
$ ps -ef | grep ovs root 63346 1 0 2016 ? 00:00:00 ovsdb-server: monitoring pid 63347 (healthy) root 63347 63346 0 2016 ? 01:16:25 ovsdb-server /etc/openvswitch/conf.db -vconsole:emer -vsyslog:err -vfile:info --remote=punix:/var/run/openvswitch/db.sock --private-key=db:Open_vSwitch,SSL,private_key --certificate=db:Open_vSwitch,SSL,certificate --bootstrap-ca-cert=db:Open_vSwitch,SSL,ca_cert --no-chdir --log-file=/var/log/openvswitch/ovsdb-server.log --pidfile=/var/run/openvswitch/ovsdb-server.pid --detach --monitor root 63356 1 0 2016 ? 00:00:00 ovs-vswitchd: monitoring pid 63357 (healthy) root 63357 63356 0 2016 ? 01:03:31 ovs-vswitchd unix:/var/run/openvswitch/db.sock -vconsole:emer -vsyslog:err -vfile:info --mlockall --no-chdir --log-file=/var/log/openvswitch/ovs-vswitchd.log --pidfile=/var/run/openvswitch/ovs-vswitchd.pid --detach --monitor
ovs-ovswitchd receives OpenFlow messages from OpenFlow controller, and
OVSDB-protocol format messages from
ovsdb-server. Communication between
datapath is through
netlink (a socket family similar with
Unix Domain Socket).
3. OVS Components
Let’s get a quick glance of the three components of OVS. Detailed explorations will be in subsequent articles of this series.
3.1. OVS Daemon
the main Open vSwitch userspace program. It reads the desired
Open vSwitch configuration from ovsdb-server over an IPC channel
and passes this configuration down to the ovs bridges (implemented as
a library called
ofproto). It also passes
certain status and statistical information from ovs bridges back into the
Fig.3.1. vswitchd: ovs main daemon
Some transient configurations, e.g. flows, are stored in datapaths and vswitchd. Persistent configurations are stored in ovsdb, which survives reboot.
ovsdb-server provides RPC itnerfaces to OVSDB. It supports JSON-RPC
client connections over active or passive TCP/IP or Unix domain sockets.
ovsdb-server runs either as a backup server, or as an active server. Only
the active server handles transactions that will change the OVSDB.
Datapath is the main packet forwarding module of OVS, implemented in kernel
space for high performance. It caches OpenFlow flows, and execute actions
on received packets which match specific flow(s). If no flow is matched for
one packet, the packet will be delivered to userspace program
ovs-vswitchd will issue an new flow to datapath which will be used to handle
subsequent packets of this type. The high performance comes from the fact
that most packets will match flows successfully in datapath, thus will be
processed directly in kernel space.
4. OVS Packet Handling
Let’s first see how a packet traverses through OVS.
Fig.4.1. OVS Packet Handling (image source)
OVS is an OpenFlow-capable software switch.
An OpenFlow controller is responsible for instructing datapath how to handle different types packets, in the form called flows. A flow describes how should datapth handle packets of one specific type, in the form called actions. Action types include forwarding to another port, output, modify vlan tag, etc. The process of finding a flow for a packet is called flow matching.
For performance consideration, part of the flows are cached in datapath, and
the others stored in
Fig.4.1 depicts how OVS forwards packets.
A packet enters OVS datapath after it is received on a NIC.
If a flow is matched in datapath for the packet, the datapath simply excutes the
actions described in the flow. Otherwise (flow missing), datapath delivers the
ovs-vswitchd, and another flow-matching process will be done there. After
ovs-vswitchd determines how the packet should be handled, it passes the packet
back to the datapath with the desired handling. Usually, it also tells the
datapath to cache the flow, for handling similar packets later.
vswitchd is at
Implementation of ovs bridge is at
OVSDB is at
vswitchd is at
- Three components of OVS
- Some implementation terms
ovs-vswitchd: main OVS daemon
ovsdb-server: OVSDB service daemon