Considerations and limitations for configuring OpenFlow
Consider the following points when you configure OpenFlow on devices:
- OpenFlow must be enabled globally on the device before you can enable interfaces for OpenFlow.
- You must explicitly enable or disable OpenFlow on each interface using the CLI commands. You cannot use a range of ports to enable OpenFlow on the interface.
- Before you can disable OpenFlow globally on the device, you must disable OpenFlow on all interfaces individually.
- Spanning Tree Protocol and other Layer 2 or Layer 3 protocols are not supported on OpenFlow-enabled ports.
- OpenFlow supports up to four concurrent sessions with a maximum of two concurrent SSL sessions.
- On hybrid OpenFlow ports, Layer 2 unicast and multicast packets will be flooded in the VLAN for protected VLANs and for unprotected VLANs in absence of flows.
- Local and normal actions defined by the OpenFlow 1.0 protocol are not supported.
- OpenFlow is an ingress feature. The local device will generate protocol messages (such as PIM, OSPF) on OpenFlow enabled-ports, if configured, but return control packets will be filtered or denied by OpenFlow default rule. Because of this limitation, the PIM neighbor (if configured) will come up on the peer, and multicast traffic will hit the OpenFlow interface in all PIM DMs, and in a PIM SM scenario in which the OpenFlow port connects to an IGMP snooping-enabled LAN that has the multicast source connected.
- On OpenFlow-enabled ports, packets that do not match any flow entry are dropped by default. Although the OpenFlow 1.0 protocol specifies sending such packets to the controller as mandatory, the Brocade implementation adopted the latest behavior defined in the OpenFlow 1.2 protocol, which specifies that such packets may be sent to the controller or may be dropped by router configuration. The Brocade implementation supports an option to send such packets to the OpenFlow Controller. Refer to Configuring the default action.