Arie Bregman

Linux And Stuff

Open vSwitch: Introduction – Part 2

This part covers:

  • Main Components (ovsdb-server, ovs-vswitchd, ovs kernel module)
  • Utilities (ovs-vsctl, ovs-ofctl, ovs-appctl, etc)
  • Modes (normal & flow)

Part 1 is here.

Open vSwitch Components

The following diagram shows Open vSwitch main components and in which space (kernel, user or remote server) each component is located


Let’s describe each one of them in more detail.


One of the core components. It is a Daemon which controls all Open vSwitch switches on the system.

When started for the first time, it gets its initial configuration from the ovsdb-server, using the OVSDB management protocol.

It communicates with the kernel module using the netlink protocol. For communication with the system, it uses netdev abstract interface.

It is also responsible for implementing switch features such as mirroring, bonding and VLANs.


A lightweight database that holds switch level configuration. Thanks to ovsdb-server, the switch configuration changes are persistent and should survive a system reboot. It Communicates with ovs-vswitchd using the OVSDB management protocol.

OpenvSwitch Kernel Module

Handles the switching and tunneling.

When a packet arrives, it checks if there is an existing entry for it (meaning if it’s an familiar flow) if not, the packet sent to the userspace, where it processed by ovs-vswitchd.

It’s designed to be fast and simple and knows nothing of OpenFlow. OpenFlow communication is done exclusively with ovs-vswitchd.

It implements “datapaths”.   Datapath is a collection of physical or virtual ports. You can think of it as a bridge, but in the kernel and not in userspace. Each datapath can have one or more ports, which called “vports”. Datapaths are controlled with the ‘ovs-dpctl’ command (we’ll cover it in the ‘utilities’ section).

OpenFlow controller

Although it’s not part of Open vSwitch components, it’s important to know what it is for since, you might have it in your environment.

All the flows kept in ovs-vswitchd will be lost in case of a restart or a crash. So to keep important flows persistent, an OpenFlow controller is usually used.

It’s common to find it installed on a remote server (that’s why it placed in different “space” in the drawing) although it can be installed on the same server.

Open vSwitch Utilities


Querying and updating the configuration of ovs-vswitchd.

Let’s see a few examples (most of them we already used in the previous post)


Querying and controlling OpenFlow switches and controllers.

A few examples (more details on OpenFlow and ovs-ofctl can be found in the OpenFlow post):


Configuring the switch kernel module. Allows to to modify, create and delete data-paths.


Sends commands to running Open vSwitch daemon.

One of its common uses is ‘ovs-appctl fsb/show <bridge_name>’. It basically prints the MAC address table.


Creating and managing the public-key infrastructure for OpenFlow switches.


A simple OpenFlow controller that may be useful for testing (don’t use it for production).

Open vSwitch Modes

Open vSwitch bridge can operate in either normal mode or flow mode when forwarding packets.

Normal mode

In normal mode, it acts as a layer 2 learning switch:

  1. When a frame first received it compares the frame’s source MAC address to the one in the table.
    • If the source is unknown (= it’s not in the MAC address table) then it adds the source MAC address to the table with the port number the packet was received on
  2. It compares the destination MAC (where this packet should reach at the end) to the one in the MAC address table
    • If there is an entry, the switch forwards the frame out through the associated port
    • If there is no entry, it floods the packet out from all its ports, except the port where the frame was received

To view the MAC address table, you can use ‘ovs-appctl fdb/show’

Flow mode

In flow mode, things are a little bit more complex. The switch makes forwarding decisions based on OpenFlow table entries.

A switch might have one or more flow tables. A flow table can be created manually by adding flows with ‘ovs-ofctl add-flow’ command or it can be set by an OpenFlow controller (as seen in the components drawing).

I won’t go into much detail on OpenFlow, there is a dedicated post for that, but let’s describe the workflow of a packet reaching a switch which operates in flow mode:

  1. When a packet first arrives the switch, it processed first by the lowest number flow table (usually table 0).  Each table consists of flows or more accurately, flow entries.
  2. Each flow entry contains several fields/components. The packet is then matched to the ‘match fields’.
    • ‘match fields’ are basically packet headers, the ingress port and optional additional fields such as the metadata. Match fields can be for example a destination IP address, VLAN id, UDP source port, ICMP code, etc.
    • In case the packet matches several flow entries, the entry with the highest priority (anther field in flow entry) will be chosen.
  3. Once a match made, the action part (which also specified in the entry) defines what to do next. The action can be: forward to a specific port, drop, process through the specified group –  those are called “required actions” (since the switch is required to support them). There are also optional actions such as: change TTL, change header fields, push tag.
    • If the packet didn’t match any ‘field match’, this situation called ‘table-miss’ and unless there is a controller where the packet information can be sent to, the packet is dropped or redirected to another table.


  1. I am trying to create your first example, a bridge with a bond ports enp5s0 enp6s0.
    Configuring the ifcfg files is not bad, but I can’t get bond0 to start.

  2. Nice info, neatly captured

  3. Can you please tell, how can I check and set limit for the maximum number of flow entries in OVS and number of tables?

Leave a Reply

Your email address will not be published.


© 2018 Arie Bregman

Theme by Anders NorenUp ↑