OpenFlow Overview

The SDN controllers signal to the switches how traffic should be forwarded by a TCP or TLS connection. These signals are referred to as flows. Flows consist of two main components: match criteria, and action(s). Traffic can be directed by matching various Ethernet, IP, TCP, fields or even the traffic‘s incoming port on the switch. Actions can consist of forwarding to one or more ports, copying traffic to the controller, modifying VLAN tags, dropping the packets, or en-queuing the traffic to a specific egress queue. In addition to these components, flows also contain different priorities for precedence and counters for monitoring usage.

This implementation of OpenFlow supports controllers that use the OpenFlow 1.3 protocol.

When multiple controllers are configured, the Open Networking Foundation (ONF) defines several roles each controller may assume: equal, slave and master. These roles are set by the controllers themselves using OpenFlow messages and no special switch configuration is required. The show openflow controller command displays each controller‘s self-assigned role.

OpenFlow is only supported on the SSA180S and SSA150A devices with 2 GB of memory.

Using OpenFlow requires running in SDN mode, which reduces the limits of certain features as compared to when you are running in "standard" mode (see OpenFlow Mode Impact to Other Feature Limits).

Packets from any connected controller should be permitted. By default, OpenFlow applies OpenFlow rules to every packet on every port. All ports are presented to the controller as OpenFlow ports. This excludes frames from the configured controller to the switch (which are always allowed). The controller may install a default operation that if the frame does not match any rules, it is sent to the controller. The switch knows nothing about any frame and has to get a rule from the controller to forward it. The controller may install a default operation that if the frame does not match any rules, the frame is switched using the standard information that the switch may have collected using FDB learning or some router protocol. In this case, unless the controller sets a rule to get some "unknown" frames, it never gets anything. The switch has an ACL that is applied to frames before OpenFlow processing. This is configured outside of the scope of the OpenFlow protocol. This allows you to specify which frames should be processed by the OpenFlow agent. This could be an L2 ACL that specifies which ports, MAC addresses, or VLANs should be processed.

A “traditional” hybrid, OpenFlow-capable switch has two forwarding tables (or FIBs), a regular one (built from source MAC address gleaning or routing protocol information) and an OpenFlow-controlled one. This OpenFlow implementation uses hybrid port mode, where the OpenFlow FIB augments the traditional FIB in what is known as unprotected mode, where a lookup is performed in the OpenFlow FIB first and the traditional FIB is used as a fallback mechanism (if there is no match in the OpenFlow table)—except that it is an either/or operation: The OpenFlow controller installs flow entries in the switch that identify the frame signatures of interest to OpenFlow. If a frame matches an OpenFlow entry and OpenFlow re-writes a portion of the frame or specifies a forwarding port, that frame is “owned” by OpenFlow (no non-OpenFlow processing is done to that frame).