OpenFlow and flow tables explained
In short: OpenFlow is a southbound protocol that lets a controller install match-and-action rules in a switch. Each rule matches header fields, has a priority and tells the switch what to do. Packets pass through one or more flow tables, and anything unmatched follows a table-miss rule.
What OpenFlow does
In software-defined networking (SDN) the control plane, which decides where traffic goes, moves out of each switch into a central controller. The switch keeps the data plane and simply follows instructions. OpenFlow was the first widely known open protocol for this conversation between controller and switch. It is a southbound protocol, meaning it runs from the controller down to devices. It was originally developed in research and is maintained by the Open Networking Foundation (ONF). Version 1.3 is the one most implementations support.
The switch opens a TCP connection to the controller, normally protected with TLS. The registered port is 6653. Over this channel the controller adds, changes and removes flow entries, asks for statistics and receives packets the switch does not know how to handle.
Flow entries and tables
- Match fields can include the ingress port, source and destination MAC, VLAN ID, EtherType, IP addresses, IP protocol and TCP or UDP ports. Fields not listed are wildcards.
- Priority decides which entry wins when several match. The highest priority applies.
- Instructions apply actions such as output to a port, drop, push or pop a VLAN tag, or set a field, and can send the packet to a later table.
- Counters track packets and bytes, useful for monitoring.
- Timeouts remove an entry after it is idle for a time, or after a fixed time regardless.
Modern OpenFlow supports a pipeline of tables, for example one for access control, one for VLAN handling and one for forwarding. A table-miss entry, with priority 0 and no match fields, decides what happens to unmatched packets: drop them, or send them to the controller as a packet-in message. Group tables allow actions such as flooding to several ports or fast failover, and meter tables allow rate limiting.
Reactive versus proactive
| Mode | How it works | Trade-off |
|---|---|---|
| Reactive | First packet of a new flow goes to the controller, which installs a rule | Flexible, but adds delay and controller load; vulnerable to flooding |
| Proactive | Controller installs rules in advance based on the topology and policy | Fast and predictable; needs more table space and planning |
Most production designs are mainly proactive, with reactive handling only for exceptions.
Try it in a lab with Open vSwitch
Open vSwitch (OVS) is an open-source virtual switch that supports OpenFlow. On a lab Linux virtual machine you can create a bridge and add rules by hand, with no controller:
sudo ovs-vsctl add-br br0
sudo ovs-vsctl set bridge br0 protocols=OpenFlow13
sudo ovs-ofctl -O OpenFlow13 add-flow br0 "priority=100,ip,nw_dst=192.168.10.20,actions=output:2"
sudo ovs-ofctl -O OpenFlow13 add-flow br0 "priority=0,actions=drop"
sudo ovs-ofctl -O OpenFlow13 dump-flows br0
sudo ovs-vsctl set-controller br0 tcp:192.168.10.5:6653The last line points the bridge at a controller in your lab. Watch the counters in dump-flows change as you send test traffic.
Tip: secure the controller channel. Without TLS and authentication, anyone who can reach it could install rules that redirect or drop traffic. See SDN security.
In exams, remember that OpenFlow is one southbound option among several. Many commercial SDN products use NETCONF, BGP or vendor APIs instead.
Practice
Two flow entries match a packet, one with priority 200 and one with priority 50. Which applies?
What does a table-miss entry do?
Why do production networks prefer proactive flow installation?
Key takeaways
- OpenFlow is a southbound protocol between an SDN controller and switches.
- Flow entries combine match fields, priority, instructions, counters and timeouts.
- Packets pass through a pipeline of tables; unmatched packets follow the table-miss entry.
- Proactive rule installation is faster and more predictable than reactive.
- Protect the controller channel with TLS and access control.
Original content written by Mohamed Fayas for FM TecHub. © 2026 FM TecHub. You're welcome to share a link to this page; please don't copy the text elsewhere without permission.