OpenFlow Overview

The ExtremeXOS OpenFlow implementation enables an external OpenFlow Controller to manipulate data flows within an Extreme switch using a standard protocol to dynamically configure a flow table abstraction. Flow table entries consist of a set of packet matching criteria (L2, L3, and L4 packet headers), a set of actions associated with a flow (flood, modify, forward, divert to controller, etc.), and a set of per flow packet and byte counters. Flow table entries are implemented using hardware ACLs and FDB entries.

ExtremeXOS supports a subset of OpenFlow classification capabilities, forwarding actions, and statistics operations based as defined in the following tables. OpenFlow Table Match Conditions.

Additionally, ExtremeXOS supports hybrid switch operations with OpenFlow in these instances:

ExtremeXOS CLI commands are used to enable OpenFlow, and to assign VLANs to the OpenFlow domain. The OpenFlow operations on a switch are controlled by an OpenFlow Controller that is connected to a switch using either the switch outband management port, or using a switch port in a VLAN that is not configured for OpenFlow.

ExtremeXOS Release 15.4 and above provides the following OpenFlow enhancements:
  • ExtremeXOS Release 15.4 and above increases the number of OpenFlow VLANs supported to the memory scaling capabilities of the platform.
  • Adds VLAN ID editing functions (VLAN ID add, strip, and modify).
  • Adds source and destination MAC modify actions to the platforms that can support it.
  • Supports the increased scaling of simple L2 flows by including the use of the FDB table to support OpenFlow flows.
  • Adds OpenFlow platform Demo support only for BlackDiamond X8, and BlackDiamond 8K chassis platforms using select interface cards. OpenFlow will work with a single MM/MSM module. Failover with dual MM/MSM‘s is not supported.
  • Provides the ability for multiple OpenFlow controllers to be configured to support high availability.
  • Provides for VLANs to be configured for OpenFlow control. The same port on a switch can support both OpenFlow-managed, and non-OpenFlow managed VLANs.
ExtremeXOS Release 15.7 and above provides the following OpenFlow enhancements:
  • ExtremeXOS Release 15.7 contains an upgrade to version 1.3 of the OpenFlow protocol.
  • The OpenFlow Group table is supported for MPLS flows only. Otherwise, only a single table is supported in this release.
  • L2VPN with Static Pseudowire and Static MPLS Tunnel (via OpenFlow Vendor Extensions).
  • MPLS Label Switching (for pseudowire only).
  • Forward between Normal VLAN/VMAN and OpenFlow Pseudowires using standard Ethernet flooding and learning.
  • Enable OpenFlow controlled traffic and normal traffic to be sent and received on the same VLAN/port.
  • Continued support of OpenFlow capabilities and scale that exist in ExtremeXOS 15.4.1.


The following list identifies limitations in this release that are the result of hardware restrictions:
  • Supported platforms do not implement both packet and byte counters simultaneously on dynamic ACL entries. Only packet counters are supported in current implementation. Counters are not supported with FDB flows.
  • IN_PORT, FLOOD, NORMAL, and TOS/DSCP editing actions are not supported.
  • Flows implemented using ACL hardware have platform limitations on the simultaneous combinations of flow match conditions that can be supported. These limitations are described in each version of ExtremeXOS Release Notes under the ACL description section, and in the Flow Match combinations table later in this section. When receiving a flow match combination that cannot be supported with the platform‘s ACL hardware, the switch will generate an OpenFlow error message to the controller.
  • Flows implemented using FDB entries are subject to normal FDB constraints, including platform-dependent table sizes.
  • FDB-based OpenFlow idle-timeout follows the configured FDB Aging Time.
  • ExtremeXOS OpenFlow supports one physical table, and ingress table. The concept of an emergency flow table is not supported.
  • OpenFlow 1.0 describes a “secure fail” model where a switch immediately removes all of its flows when it loses connectivity to its controller. ExtremeXOS implements an “open fail” mode. In this mode the switch maintains its existing flows after losing connectivity to a controller. The "open fail" model is required to support controller high availability solutions.
  • High availability for controllers is available through the following two mechanisms:
    • Some controller clusters present a single IP address. The switch treats the cluster as a single controller.
    • Some controller clusters present multiple IP addresses. The switch connects simultaneously to primary and secondary controller targets and enables the controllers to manage failover.
  • OpenFlow, XNV, and IDM are all features that enable an external agent to control resources on a switch. Due to their interaction models and resource requirements, these features are mutually exclusive. The ExtremeXOS OpenFlow implementation prevents these services from being simultaneously configured on the same port.


    There are other ExtremeXOS features that may not perform optimally when configured on OpenFlow enabled VLANs, or switch ports with OpenFlow supported VLANS. We make no attempt to prevent you from configuring additional services on these interfaces.
  • MPLS and PseudoWire instances are limited by platform capabilities.
  • Failover not supported on Stacks or Chassis.

Supported Platforms

ExtremeXOS wide-key ACL platform is required to support OpenFlow because of the potential for L2, L3, and L4 simultaneous header match conditions. OpenFlow is supported on the following platforms:
  • Summit X440
  • Summit X460
  • Summit X460-G2
  • Summit X480
  • Summit X670
  • Summit X670-G2
  • Summit X770
  • BlackDiamond X8 with a single MM module.
  • BlackDiamond 8K – 8900 (XL-Series) and C-Series with single MM only.


MPLS features are only supported on hardware platforms that support MPLS. In particular, the X430/X440 do not support MPLS.