An Open vSwitch bridge can operate in “normal” mode and “flow” mode. In normal mode it acts as a regular layer 2 learning switch. For each incoming frame it learns its source MAC address and places it on its incoming port. It then either forwards the frame to the appropriate port if the destination MAC address was previously learned, or floods the frame if it wasn’t. Broadcast and multicast frames are flooded as usual. In flow mode, the bridge’s flow table is used instead. Whatever flows are installed are used and no other behavior is implied. You can mix and match, and when a message hits a flow with an action of “NORMAL”, the switch’s MAC table is consulted and the appropriate action is taken.

Navigating an Open vSwitch Flow Table

Each Open vSwitch flow, regardless if it was configured via OpenFlow or by directly calling ovs-ofctl add-flow, is composed of a match and action part. Flow tables are composed of many flows which are processed in a well defined order – But which flow(s) does a message hit? The match part of a flow defines what fields of a frame/packet/segment must match in order to hit the flow. Once a match is found, the action part of a flow defines what actually happens now that the flow was hit. You can match on most fields in the layer 2 frame, layer 3 packet or layer 4 segment. So, for example, you could match on a specific destination MAC and IP address pair, or a specific destination TCP port. Note that the match must make sense top to bottom, so you cannot specify that in the IP packet the “Next Protocol” field must be ICMP, but then in the same flow match against a TCP destination port, as TCP and ICMP are both encapsulated at layer 4 inside of an IP packet.

Matches may also be wildcarded, so you can match against a range of ports or IP addresses. Any field not explicitly defined is wildcarded against, so if a flow doesn’t say anything about the source MAC address then any source MAC address matches.

The action part of a flow defines what is actually done on a message that matched against the flow. You can forward the message out a specific port, drop it, change most parts of any header, build new flows on the fly (For example to implement a form of learning), or resubmit the message to another table (More on this later).

ovs-ofctl dump-flows <bridgeName>

Each flow is written to a specific table, and is given a specific priority. Messages enter the flow table directly into table 0. From there, each message is processed by table 0’s flows from highest to lowest priority. If the message does not match any of the flows in table 0 it is implicitly dropped (Unless an SDN controller is defined – In which case a message is sent to the controller asking what to do with the received packet). If a message does match a flow in table 0, it can be either redirected to another table (Via the resubmit action), or end its lookup by any of the other actions (Drop the message, forward it…)

What Now?

To quote Open vSwitch’s comprehensive offical tutorial guide:

If you do not already understand how an OpenFlow flow table works, please go read a basic tutorial and then continue reading here afterward.

You’ve read the basic tutorial – Now go read the advanced one. Here we learned how to view a flow table, in the advanced tutorial you’ll spend 30 minutes and interactively learn how to manipulate one.

Afterwards you can dive into Scott Lowe’s excellent blog. He has a post about bonds and VLANs (Which aren’t covered in the official tutorial linked above), as well as an entire comprehensive set of blog posts about Open vSwitch.