Next, when configuring any OpenFlow switch – hardware or software – it’s important to note the available operating mode(s) of the switch. Many switches support OpenFlow/non-OpenFlow hybrid operation where control over the flow of traffic can be delegated to either the OpenFlow controller, the switch-local forwarding engine, or a combination of the two. In order to establish the OpenFlow versus non-OpenFlow partitions on the switch, many vendors choose to allow for multiple OpenFlow “instances” to be instantiated onboard the switch – typically up to a low power of two number of instances. (Note that not all switches support multiple instances.) These instances can be configured with an OpenFlow controller. What this controller controls is defined by how the instance attaches to the data plane.
Some vendors support VLAN instances, where any port configured on VLAN X will be under the control of the instance’s OpenFlow controller. If the port is in access mode for VLAN X, the switch will tag ingress packets with VLAN X prior to delivering them to the instance’s forwarding table; likewise, it will pop the tags from all packets egress this port. On the other hand, if the port is in trunk mode, only those ingress packets with VLAN tag X will be delivered to the OpenFlow
instance; now, packets egress such a trunk port from an OpenFlow instance will sometimes have the tag pushed automatically if it is not already present. Other times, the controller will be responsible for pushing the tag as necessary within any installed flows. Since switch vendors vary in their implementations of this mode, it is recommended one consult the OpenFlow operating guide of the physical switch to ensure it supports the desired mode.
Another popular operating mode is port-based. In such an implementation, the OpenFlow instance is configured with a set of ports. This instance is responsible for controlling all traffic on these ports, regardless of the VLANs used.
It’s common to see both VLAN and port based OpenFlow instance partitioning on physical OpenFlow switches. In VLAN mode, a single port can support both OpenFlow controlled and non-OpenFlow controlled traffic. The two sets would belong to different VLANs where one or more VLANs would go to an OpenFlow instance and the other(s) would be handled by the onboard switch forwarding logic. In VLAN mode, special care must be taken to ensure all packets are handled correctly. If care is not taken, chaos can ensue.
Take link layer discovery protocol (LLDP) as an example. Many OpenFlow controllers implement LLDP in order to discover the links in an OpenFlow network. LLDP operates on top of VLANs (i.e. is untagged), since it is traditionally a protocol used between switches, which might share many VLANs over a given link. When using physical OpenFlow switches configured in VLAN mode and an LLDP module in the OpenFlow controller, the controller will likely send untagged packet- out messages to the switch. If the switch does not push the VLAN instance’s tag automatically, the LLDP packets will be sent out untagged. This isn’t necessarily bad; in fact, it’s as LLDP was intended. But, consider the case where another adjacent physical OpenFlow switch has an OpenFlow instance configured in VLAN mode on the same VLAN. And, for clarity, let’s assume all switch ports attached to the OpenFlow instance are in trunk mode. If the first switch sends an untagged LLDP packet out its OpenFlow instance and this instance does not automatically push the tag, the untagged LLDP packet will traverse the link to the adjacent OpenFlow switch. This switch will not deliver the packet to the OpenFlow instance, since the switch is set to use VLAN X as to multiplex traffic between OpenFlow instances and its own forwarding engine. As such, the controller connected to both physical switches will not discover the link that is in fact present.
Another note about physical switch operation/configuration is that some vendors support a different kind of hybrid OpenFlow/non-OpenFlow operating mode, where an OpenFlow instance
can have traffic filtered by the switch prior to being exposed to the controller. For example, some switches have a layer 2 hybrid mode where the switch will not deliver any packets to the controller that can be handled by its MAC learning implementation. This is a desirable behavior in some cases, but it can lead to confusion from the controller’s perspective if the controller is expected to receive all packets. Similar implementations exist for access control list policies configured on the switch. If enabled, any rules installed on the switch might preempt any flows installed by the controller in the flow table. It is very important to keep this in mind, especially when first deploying a switch – sometimes these features are turned on by default and must be manually disabled.
Lastly, some physical OpenFlow switches give the user control over TCAM carving, and oddly enough might set the default size of controller-exposed flow tables to zero entries. If this occurs, the controller will likely receive an error message from the switch when it tried to insert a flow.