HPE FlexNetwork 5510 HI Series User manual

HPE FlexNetwork 5510 HI Switch Series
OpenFlow
Configuration Guide
Part number: 5200-0017a
Software version: Release 11xx
Document version: 6W101-20161221

© Copyright 2015, 2016 Hewlett Packard Enterprise Development LP
The information contained herein is subject to change without notice. The only warranties for Hewlett Packard
Enterprise products and services are set forth in the express warranty statements accompanying such
products and services. Nothing herein should be construed as constituting an additional warranty. Hewlett
Packard Enterprise shall not be liable for technical or editorial errors or omissions contained herein.
Confidential computer software. Valid license from Hewlett Packard Enterprise required for possession, use, or
copying. Consistent with FAR 12.211 and 12.212, Commercial Computer Software, Computer Software
Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under vendor’s
standard commercial license.
Links to third-party websites take you outside the Hewlett Packard Enterprise website. Hewlett Packard
Enterprise has no control over and is not responsible for information outside the Hewlett Packard Enterprise
website.
Acknowledgments
Intel®, Itanium®, Pentium®, Intel Inside®, and the Intel Inside logo are trademarks of Intel Corporation in the
United States and other countries.
Microsoft® and Windows® are either registered trademarks or trademarks of Microsoft Corporation in the
United States and/or other countries.
Adobe® andAcrobat® are trademarks of Adobe Systems Incorporated.
Java and Oracle are registered trademarks of Oracle and/or its affiliates.
UNIX® is a registered trademark of The Open Group.

i
Contents
Configuring OpenFlow····················································································1
Overview····························································································································································1
OpenFlow switch········································································································································1
OpenFlow port············································································································································1
OpenFlow instance ····································································································································2
OpenFlow flow table···································································································································3
Group table ················································································································································5
Meter table·················································································································································5
OpenFlow channel·····································································································································5
Protocols and standards ····························································································································7
OpenFlow configuration task list························································································································7
Configuring OpenFlow instances·······················································································································8
Creating an OpenFlow instance·················································································································8
Configuring the OpenFlow instance scope ································································································8
Creating flow tables for an OpenFlow instance··························································································9
Setting the controller mode························································································································9
Setting the maximum number of flow entries for an extensibility flow table·············································10
Configuring inband management VLANs·································································································10
Configuring OpenFlow to forbid MAC address learning···········································································11
Forbidding an OpenFlow instance from reporting the specified types of ports to controllers···················11
Configuring the default action of table-miss flow entries··········································································11
Setting the datapath ID ····························································································································11
Activating or reactivating an OpenFlow instance·····················································································12
Configuring controllers for an OpenFlow switch ······························································································12
Configuring controllers and main connections·························································································13
Setting the connection interruption mode·································································································13
Setting OpenFlow timers··································································································································13
Configuring an OpenFlow instance to support dynamic MAC addresses························································14
Enabling packet loss prevention for OpenFlow forwarding··············································································14
Enabling an OpenFlow instance to perform QinQ tagging for double-tagged packets passing an extensibility
flow table··························································································································································15
Disabling logging for successful flow table modifications ················································································15
Refreshing all Layer 3 flow entries in the MAC-IP flow table for an OpenFlow instance ·································15
Displaying and maintaining OpenFlow·············································································································16
OpenFlow configuration example ····················································································································16
Network requirements······························································································································16
Configuration procedure···························································································································17
Verifying the configuration························································································································17
Appendixes···································································································19
Appendix A Application restrictions··················································································································19
Matching restrictions································································································································19
Instruction restrictions······························································································································19
Restrictions for merging the action list into the action set········································································20
Packet-out messages restrictions············································································································20
Packet-in messages restrictions ··············································································································21
LLDP frame matching ······························································································································21
Flow table modification messages restrictions·························································································21
Appendix B MAC-IP flow table·························································································································22
Capabilities supported by the MAC-IP flow table·····················································································22
MAC-IP flow table restrictions··················································································································23
Table-miss flow entry of MAC-IP flow tables····························································································23
Dynamic aware ········································································································································24
MAC-IP flow table cooperating with extensibility flow table ·····································································24
Appendix C VLAN tagging and untagging flow tables ·····················································································25
Capabilities supported by the VLAN tagging flow table ···········································································25
Capabilities supported by the VLAN untagging flow table ·······································································25

ii
Document conventions and icons·································································27
Conventions·····················································································································································27
Network topology icons····································································································································28
Support and other resources ········································································29
Accessing Hewlett Packard Enterprise Support ······························································································29
Accessing updates···········································································································································29
Websites ··················································································································································30
Customer self repair·································································································································30
Remote support········································································································································30
Documentation feedback ·························································································································30
Index·············································································································32

1
Configuring OpenFlow
Software-Defined Networking (SDN) was developed to meet the growing requirements of
virtualization technologies and data networks. SDN uses software to separate controlling functions
from data forwarding, and provides simple, flexible device operations and high extensibility.
OpenFlow is the communication interface between a controller and network devices to implement
SDN. With OpenFlow, you can perform centralized data forwarding management for physical and
virtual devices.
Overview
OpenFlow separates the data forwarding and routing decision functions. It keeps the flow-based
forwarding function and employs a separate controller to make routing decisions. A switch
communicates with the controller through an OpenFlow channel. An OpenFlow channel can be
encrypted by using TLS or run directly over TCP.An OpenFlow switch exchanges control messages
with the controller through an OpenFlow channel to perform the following tasks:
•Receive flow table entries or data from the controller.
•Report information to the controller.
Unless otherwise stated, a switch refers to an OpenFlow switch throughout this document.
Figure 1 OpenFlow network diagram
OpenFlow switch
OpenFlow switches include the following types:
•OpenFlow-only—Supports only OpenFlow operation.
•OpenFlow-hybrid—Supports both OpenFlow operation and traditional Ethernet switching
operation. Switches of this series are OpenFlow-hybrid switches.
OpenFlow port
IMPORTANT:
The tunnel interfaces and loopback interfaces cannot be used as OpenFlow ports.

2
OpenFlow supports the following types of ports:
•Physical port—Corresponds to a hardware interface of a switch, such as an Ethernet interface.
A physical port can be either an ingress port or an output port.
•Logical port—Does not correspond to a hardware interface of a switch and might be defined
by non-OpenFlow methods, such as an aggregate interface. A logical port can be either an
ingress port or an output port.
•Reserved port—Defined by OpenFlow to specify forwarding actions. Reserved ports include
the following types:
{All—All OpenFlow ports that can be used to forward a packet.
{Controller—OpenFlow controller.
{Local—Local CPU.
{Normal—Normal forwarding process.
{Flood—Flooding.
Except the Any type, all reserved ports can be used only as output ports. Only ports of
Controller and Local types can be used as input ports.
OpenFlow instance
You can configure one or more OpenFlow instances on the same device. Acontroller considers each
OpenFlow instance as a separate OpenFlow switch and deploys forwarding instructions to it.
In this chapter, an OpenFlow switch is the same as an OpenFlow instance, unless otherwise
specified.
Associated VLAN
When an OpenFlow instance is associated with VLANs, the flow tables take effect on packets only
within those VLANs.
Activation and reactivation
The configurations for an OpenFlow instance take effect only after the OpenFlow instance is
activated.
The controller can deploy flow entries to an OpenFlow instance only after the OpenFlow instance
reports the following information to the controller:
•Capabilities supported by OpenFlow.
•Ports that belong to the OpenFlow instance.
An activated OpenFlow instance need be reactivated when any of the OpenFlow instance
configurations is changed.
After reactivation, the OpenFlow instance is disconnected from all controllers and then reconnected
to them.
OpenFlow instance port
An OpenFlow instance sends information about following ports to the controller:
•Physical ports.
•Logical ports.
•Reserved ports of the Local type.
In loosen mode, a port belongs to the OpenFlow instance when VLANs associated with the
OpenFlow instance overlap with the port's allowed VLANs. Otherwise, a port belongs to an
OpenFlow instance only when VLANs associated with the OpenFlow instance are within the port's
allowed VLAN list.

3
OpenFlow flow table
An OpenFlow switch matches packets against one or more user-defined flow tables. A flow table
contains flow entries, and packets are matched based on the matching precedence of flow entries.
OpenFlow flow tables include the following types:
•MAC-IP—Combines the MAC address table and FIB table.
A MAC-IP flow table provides the following match fields:
{Destination MAC address.
{VLAN.
{Destination IP address.
A MAC-IP flow table provides the following actions:
{Modifying the destination MAC address.
{Modifying the source MAC address.
{Modifying the VLAN.
{Specifying the output port.
•Extensibility—Combines Ternary ContentAddressable Memory (TCAM) tables and tables
programmed by software.An extensibility table provides more match fields and actions than a
MAC-IP flow table, such as destination MAC address, destination IP address, VLAN priority,
TCP source port, and TCP destination port.
Flow entry
Figure 2 Flow entry components
A flow entry contains the following fields:
•Match fields—Matching rules of the flow entry. These contain the ingress port, packet headers,
and metadata specified by the previous table.
•Priority—Matching precedence of the flow entry. When a packet is matched against the flow
table, only the highest priority flow entry that matches the packet is selected.
•Counters—Counts of the packets that match the flow entry.
•Instructions—To modify the action set or pipeline processing. These include the following
types:
{Meter—Directs the packets to the specified meter to rate-limit the packets.
{Apply-Actions—Applies the specified actions in the action list immediately.
{Clear-Actions—Clears all actions in the action set immediately.
{Write-Actions—Modifies all actions in the action set immediately.
{Write-Metadata—Modifies packets between two flow tables if there are multiple flow tables.
{Goto-Table—Indicates the next flow table in the processing pipeline.
Actions are executed in one of the following ways:
{Action Set—When the instruction set of a flow entry does not contain a Goto-Table
instruction, pipeline processing stops and the actions in the action set are executed.An
action set contains a maximum of one action of each type.
{Action List—The actions in the action list are executed immediately in the order specified
by the action list. The effect of those actions is cumulative.
Actions include the following types:

4
{(Required.) Output—The Output action forwards a packet to the specified OpenFlow port.
OpenFlow switches must support forwarding packets to physical ports, logical ports, and
reserved ports.
{(Required.) Drop—There is no explicit action to represent drops. Packets whose action
sets have no output actions are dropped. Typically, packets are dropped due to empty
instruction sets, empty action sets, or the executing a Clear-Actions instruction.
{(Required.) Group—Process the packet through the specified group. The exact
interpretation depends on group type.
{(Optional.) Set-Queue—The Set-Queue action sets the queue ID for a packet. When the
packet is forwarded to a port by using the output action, the queue ID determines which
queue attached to this port is used for scheduling and forwarding the packet. The
forwarding behavior is dictated by the configuration of the queue and is used to provide
basic QoS support.
{(Optional.) Set-Field—The Set-Field actions are identified by their field type and modify
the values of corresponding header fields in the packet. Set-Field actions are always
applied to the outermost header. For example, a Set VLAN ID action always sets the ID of
the outermost VLAN tag.
•Timeouts—Maximum amount of idle time or hard time for the flow entry.
{idle time—The flow entry is removed when it has matched no packets during the idle time.
{hard time—The flow entry is removed when the hard time timeout is exceeded, whether or
not it has matched packets.
•Cookie—Flow entry identifier specified by the controller.
Table-miss flow entry
Every flow table must support a table-miss flow entry to process table misses. The table-miss flow
entry specifies how to process packets that were not matched by other flow entries in the flow table.
The table-miss flow entry wildcards all match fields (all fields omitted) and has the lowest priority 0.
The table-miss flow entry behaves in most ways like any other flow entry.
OpenFlow pipeline
The OpenFlow pipeline processing defines how packets interact with flow tables contained by a
switch.
The flow tables of an OpenFlow switch are sequentially numbered, starting at 0. The packet is first
matched against flow entries of the first flow table, which is flow table 0. Aflow entry can only direct a
packet to a flow table number that is greater than its own flow table number.
When a packet matches a flow entry, the OpenFlow switch updates the action set for the packet and
passes the packet to the next flow table. In the last flow table, the OpenFlow switch executes all
actions to modify packet contents and specify the output port for packet forwarding. If the instruction
set of one of the flow tables contains an action list, the OpenFlow switch executes the actions to
modify a copy of the packet immediately in this table.
Figure 3 OpenFlow forwarding workflow

5
Group table
The ability for a flow entry to point to a group enables OpenFlow to represent additional methods of
forwarding.A group table contains group entries.
Figure 4 Group entry components
A group entry contains the following fields:
•Group Identifier—A 32 bit unsigned integer uniquely identifying the group.
•Group Type—Type of the group: All—Execute all buckets in the group. This group is used for
multicast or broadcast forwarding.
•Counters—Updated when packets are processed by a group.
•Action Buckets—An ordered list of action buckets, where each action bucket contains a set of
actions to execute and associated parameters.
Meter table
Meters enable OpenFlow to implement various simple QoS operations, such as rate-limiting. Agroup
table contains meter entries.
Figure 5 Meter entry components
A meter entry contains the following fields:
•Meter Identifier—A32 bit unsigned integer uniquely identifying the meter.
•Meter Bands—Each meter can have one or more meter bands. Each band specifies the rate at
which the band applies and the way packets should be processed. If the current rate of packets
exceeds the rate of multiple bands, the band with the highest configured rate is used.
•Counters—Updated when packets are processed by a meter.
Figure 6 Band components
A meter band contains:
•Band Type—Packet processing methods. Packets that exceed the band rate are dropped.
•Rate—Defines the lowest rate at which the band can apply.
•Counters—Updated when packets are processed by a band.
•Type Specific Arguments—Some band types have optional arguments.
OpenFlow channel
The OpenFlow channel is the interface that connects each OpenFlow switch to a controller. The
controller uses the OpenFlow channel to exchange control messages to configure and manage the
switch, receive events from the switch, and send packets out the switch. The OpenFlow channel is
usually encrypted by using TLS. Also, an OpenFlow channel can be run directly over TCP.

6
The OpenFlow protocol supports the following message types: controller-to-switch, asynchronous,
and symmetric. Each message type has its own subtypes.
Controller-to-Switch messages
IMPORTANT:
Support for Controller-to-Switch messages varies by device mode.
Controller-to-Switch messages are initiated by the controller and used to directly manage or inspect
the state of the switch. Controller-to-Switch messages might or might not require a response from
the switch.
The Controller-to-Switch messages include the following subtypes:
•Features—The controller requests the basic capabilities of a switch by sending a features
request. The switch must respond with a features reply that specifies the basic capabilities of
the switch.
•Configuration—The controller sets and queries configuration parameters in the switch. The
switch only responds to a query from the controller.
•Modify-State—The controller sends Modify-State messages to manage state on the switches.
Their primary purpose is to add, delete, and modify flow or group entries in the OpenFlow tables
and to set switch port properties.
•Read-State—The controller sends Read-State messages to collect various information from
the switch, such as current configuration and statistics.
•Packet-out—These are used by the controller to send packets out of the specified port on the
switch, or to forward packets received through Packet-in messages. Packet-out messages
must contain a full packet or a buffer ID referencing a packet stored in the switch.The message
must also contain a list of actions to be applied in the order they are specified. An empty action
list drops the packet.
•Barrier—Barrier messages are used to confirm the completion of the previous operations. The
controller send s Barrier request. The switch must send a Barrier reply when all the previous
operations are complete.
•Role-Request—Role-Request messages are used by the controller to set the role of its
OpenFlow channel, or query that role. It is typically used when the switch connects to multiple
controllers.
•Asynchronous-Configuration—These are used by the controller to set an additional filter on
the asynchronous messages that it wants to receive, or to query that filter. It is typically used
when the switch connects to multiple controllers.
Asynchronous messages
IMPORTANT:
Support for asynchronous messages varies by device mode.
Switches send asynchronous messages to controllers to inform a packet arrival or switch state
change. For example, when a flow entry is removed due to timeout, the switch sends a flow removed
message to inform the controller.
The asynchronous messages include the following subtypes:
•Packet-In—Transfer the control of a packet to the controller. For all packets forwarded to the
Controller reserved port using a flow entry or the table-miss flow entry, a packet-in event is
always sent to controllers. Other processing, such as TTL checking, can also generate
packet-in events to send packets to the controller. The Packet-in events can include the full
packet or can be configured to buffer packets in the switch. If the packet-in event is configured
to buffer packets, the packet-in events contain only some fraction of the packet header and a
buffer ID. The controller processes the full packet or the combination of the packet header and

7
the buffer ID. Then, the controller sends a Packet-out message to direct the switch to process
the packet.
•Flow-Removed—Inform the controller about the removal of a flow entry from a flow table.
These are generated due to a controller flow delete request or the switch flow expiry process
when one of the flow timeouts is exceeded.
•Port-status—Inform the controller of a state or setting change on a port.
•Error—Inform the controller of a problem or error.
Symmetric messages
IMPORTANT:
Support for symmetric messages varies by device mode.
Symmetric messages are sent without solicitation, in either direction.
The symmetric messages contain the following subtypes:
•Hello—Hello messages are exchanged between the switch and controller upon connection
startup.
•Echo—Echo request or reply messages can be sent from either the switch or the controller, and
must return an echo reply. They are mainly used to verify the liveness of a controller-switch
connection, and might also be used to measure its latency or bandwidth.
•Experimenter—This is a staging area for features meant for future OpenFlow revisions.
Protocols and standards
OpenFlow Switch Specification Version 1.3.1
OpenFlow configuration task list
Tasks at a glance
(Required.) Configure an OpenFlow instance:
1. (Required.) Creating an OpenFlow instance
2. (Required.) Configuring an OpenFlow instance:
{(Required.) Configuring the OpenFlow instance scope
{(Optional.) Creating flow tables for an OpenFlow instance
{(Optional.) Setting the controller mode
{(Optional.) Setting the maximum number of flow entries
{(Optional.) Configuring inband management VLANs
{(Optional.) Configuring OpenFlow to forbid MAC address learning
{(Optional.) Forbidding an OpenFlow instance from reporting the specified types of ports to
controllers
{(Optional.) Configuring the default action of table-miss flow entries
{(Optional.) Setting the datapath ID
3. (Required.) Activating or reactivating an OpenFlow instance
(Required.) Configure controllers for an OpenFlow switch:
•(Required.) Configuring controllers and main connections
•(Optional.) Setting the connection interruption mode
(Optional.) Setting OpenFlow timers
(Optional.) Configuring an OpenFlow instance to support dynamic MAC addresses
(Optional.) Enabling packet loss prevention for OpenFlow forwarding

8
Tasks at a glance
(Optional.) Enabling an OpenFlow instance to perform QinQ tagging for double-tagged packets passing an
extensibility flow table
(Optional.) Disabling logging for successful flow table modifications
(Optional.) Refreshing all Layer 3 flow entries in the MAC-IP flow table for an OpenFlow instance
Configuring OpenFlow instances
Creating an OpenFlow instance
Step Command Remarks
1. Enter system view. system-view N/A
2. Create an OpenFlow
instance and enter
OpenFlow instance view. openflow instance instance-id By default, no OpenFlow instance
exists.
3. (Optional.) Specify a
description for the OpenFlow
instance. description text By default, an OpenFlow instance
does not have a description.
Configuring the OpenFlow instance scope
When an OpenFlow instance is associated with VLANs, the flow entries take effect only on packets
within those VLANs.
When you associate an OpenFlow instance with VLANs, follow these guidelines:
•Do not associate multiple OpenFlow instances with the same VLAN. Otherwise, VLAN traffic
cannot be correctly processed.
•When you activate an OpenFlow instance that is associated with non-existent VLANs, the
system automatically creates these VLANs. Do not delete any of the associated VLANs after
the OpenFlow instance is activated.
•Do not configure the BFD MAD function on the VLAN interface for a VLAN that is associated
with an OpenFlow instance. For more information about the BFD MAD function, see IRF
Configuration Guide.
To configure the OpenFlow instance scope:
Step Command Remarks
1. Enter system view. system-view N/A
2. Enter OpenFlow instance
view. openflow instance instance-id N/A
3. Associate the OpenFlow
instance with VLANs. classification vlan vlan-id
[ mask vlan-mask ] [ loosen ]
Use either command.
By default, an OpenFlow instance
is not associated with any VLAN.

9
Creating flow tables for an OpenFlow instance
Step Command Remarks
1. Enter system view. system-view N/A
2. Enter OpenFlow instance
view. openflow instance instance-id N/A
3. Configure the flow table type
and the flow table ID.
flow-table { [ ingress-vlan
ingress-table-id ] [ extensibility
extensibility-table-id | mac-ip
mac-ip-table-id ] * [ egress-vlan
egress-table-id ] }
By default, an OpenFlow instance
contains one extensibility flow
table with an ID of 0.
An OpenFlow instance supports
only one MAC-IP flow table and
one extensibility flow table. If you
execute the command multiple
times, the most recent
configuration takes effect.
The ID of the MAC-IP flow table
must be smaller than that of the
extensibility flow table.
The VLAN tagging flow table and
untagging flow table take effect
only when the following conditions
are met:
•The OpenFlow instance is
configured to perform QinQ
tagging for double-tagged
packets passing an
extensibility flow table.
•The OpenFlow instance uses
the standalone connection
interruption mode.
The ingress-vlan ingress-table-id
and egress-vlan egress-table-id
options are available in Release
1121 and later.
Setting the controller mode
An OpenFlow instance can connect to one or more controllers, depending on the controller mode the
OpenFlow instance uses:
•Single—The OpenFlow instance connects to only one controller at a time. When
communication with the current controller fails, the OpenFlow instance uses another controller.
In this mode, an OpenFlow instance attempts to connect to a controller one by one in ascending
order of controller ID until it successfully connects to a controller. If multiple controllers that are
configured for the OpenFlow instance are unreachable, it might take a long time for the
OpenFlow instance to connect to a reachable controller.
•Multiple—The OpenFlow instance can simultaneously connect to multiple controllers. When
communication with any controller fails, the OpenFlow instance attempts to reconnect to the
controller after a reconnection interval.
To set the controller mode for an OpenFlow instance:
Step Command Remarks
1. Enter system view. system-view N/A

10
Step Command Remarks
2. Enter OpenFlow instance view. openflow instance instance-id N/A
3. Set the controller mode. controller mode { multiple |
single } By default, the controller mode
is multiple.
Setting the maximum number of flow entries for an
extensibility flow table
You can set the maximum number of flow entries that an extensibility flow table supports. When the
maximum number is reached, the OpenFlow instance does not accept new flow entries for that table
and sends a deployment failure notification to the controller.
To set the maximum number of flow entries that an extensibility flow table supports:
Step Command Remarks
1. Enter system view. system-view N/A
2. Enter OpenFlow instance
view. openflow instance instance-id N/A
3. Set the maximum number of
extensibility flow entries. flow-entry max-limit limit-value By default, an OpenFlow
extensibility flow table supports up
to 65535 flow entries.
Configuring inband management VLANs
Inband management VLANs are used to establish connections between an OpenFlow instance and
controllers.
When the inband management VLANs are configured, the data packets within the inband
management VLANs are not forwarded through OpenFlow. The ports that are assigned to only
inband management VLANs are not OpenFlow ports. Before configuring inband management
VLANs, you must plan the network.
To configure inband management VLANs:
Step Command Remarks
1. Enter system view. system-view N/A
2. Enter OpenFlow
instance view. openflow instance instance-id N/A
3. Configure inband
management
VLANs. in-band management vlan
vlan-list
By default, no inband management
VLAN is configured.
The inband management VLANs of an
OpenFlow instance must be within the
list of the VLANs that are associated with
the OpenFlow instance.

11
Configuring OpenFlow to forbid MAC address learning
Step Command Remarks
1. Enter system view. system-view N/A
2. Enter OpenFlow instance
view. openflow instance instance-id N/A
3. Forbid MAC address
learning for VLANs
associated with the
OpenFlow instance. mac-learning forbidden
By default, MAC address learning
is allowed for VLANs associated
with an OpenFlow instance.
The configuration does not take
effect on inband management
VLANs.
Forbidding an OpenFlow instance from reporting the
specified types of ports to controllers
Step Command Remarks
1. Enter system view. system-view N/A
2. Enter OpenFlow instance
view. openflow instance instance-id N/A
3. Forbid the OpenFlow
instance from reporting the
specified types of ports to
controllers.
forbidden port { vlan-interface |
vsi-interface } *
By default, all ports that belong to
an OpenFlow instance are
reported to the controllers.
Configuring the default action of table-miss flow entries
Step Command Remarks
1. Enter system view. system-view N/A
2. Enter OpenFlow instance
view. openflow instance instance-id N/A
3. Change the default action of
the table-miss flow entry to
forward packets to the
normal pipeline. default table-miss permit
By default, the default action of
the table-miss flow entry is to drop
packets after the OpenFlow
instance is activated and before
the controller deploys flow entries.
Setting the datapath ID
The datapath ID is a unique identifier for an OpenFlow switch (OpenFlow instance). Do not configure
the same datapath ID for different OpenFlow switches.
To set the datapath ID:
Step Command Remarks
1. Enter system view. system-view N/A
2. Enter OpenFlow instance openflow instance instance-id N/A

12
Step Command Remarks
view.
3. Set the datapath ID. datapath-id id
By default, the datapath ID of an
OpenFlow instance contains the
instance ID and the bridge MAC
address of the device. The upper
16 bits are the instance ID and the
lower 48 bits are the bridge MAC
address of the device.
Activating or reactivating an OpenFlow instance
CAUTION:
Reactivating an OpenFlow instance refreshes the configuration data and interrupts communication
with the controllers.
To activate or reactivate an OpenFlow instance:
Step Command Remarks
1. Enter system view. system-view N/A
2. Enter OpenFlow instance
view. openflow instance instance-id N/A
3. Activate or reactivate the
OpenFlow instance. active instance By default, an OpenFlow instance
is not activated.
Configuring controllers for an OpenFlow switch
Aswitch can establish connections with multiple controllers. The controller role contains the following
types:
•Equal—In this role, the controller has full access to the switch and is equal to other controllers
in the same role. By default, the controller receives all switch asynchronous messages such as
packet-in and flow removed messages. The controller can send controller-to-switch messages
to modify the state of the switch.
•Master—This role is similar to the Equal role and has full access to the switch. The difference is
that up to one controller in this role is allowed for a switch.
•Slave—In this role, the controller has read-only access to the switch.
The controller cannot send controller-to-switch messages to perform the following tasks:
{Deploy flow entries, group entries, and meter entries.
{Modify the port and switch configurations.
{Send Packet-out messages.
By default, the controller does not receive switch asynchronous messages except Port-status
messages. The controller can send Asynchronous-Configuration messages to set the
asynchronous message types it wants to receive.
When OpenFlow operation is initiated, a switch is simultaneously connected to multiple controllers in
Equal state. A controller can request its role to be changed at any time.

13
Configuring controllers and main connections
An OpenFlow switch supports up to 64 controllers. However, the OpenFlow channel between the
OpenFlow switch and each controller can have only one main connection. The main connection
processes control messages to complete tasks such as deploying entries, obtaining data, and
sending information. The main connection must be a reliable connection using TCP or SSL.
To specify a controller for an OpenFlow switch and configure the main connection to the controller:
Step Command Remarks
1. Enter system view. system-view N/A
2. Enter OpenFlow instance
view. openflow instance instance-id N/A
3. Specify a controller and
configure the main
connection to the controller.
controller id address { ip
ip-address | ipv6 ipv6-address }
[ port port-number ] [ local
address { ip ip-address | ipv6
ipv6-address } [ port
port-number ] ] [ ssl
ssl-policy-name ][ vrf vrf-name ]
By default, an OpenFlow instance
does not have a main connection
to a controller.
Setting the connection interruption mode
An OpenFlow switch is set to either of the following modes when it is disconnected from all
controllers:
•Secure—In this mode, the OpenFlow switch forwards traffic based on flow tables and does not
delete unexpired flow entries.
•Standalone—The OpenFlow switch uses the normal forwarding process.
The OpenFlow switch forwards traffic based on flow tables when it reconnects to a controller
successfully.
To set the connection interruption mode for an OpenFlow switch:
Step Command Remarks
1. Enter system view. system-view N/A
2. Enter OpenFlow instance
view. openflow instance instance-id N/A
3. Set the connection
interruption mode. fail-open mode { secure |
standalone } By default, the secure mode is
used.
Setting OpenFlow timers
An OpenFlow switch supports the following timers:
•Connection detection interval—Interval at which the OpenFlow switch sends an Echo
Request message to a controller.When the OpenFlow switch receives no Echo Reply message
within three connection detection intervals, the OpenFlow switch is disconnected from the
controller.
•Reconnection interval—Interval for the OpenFlow switch to wait before it attempts to
reconnect to a controller.
To set OpenFlow timers for an OpenFlow switch:

14
Step Command Remarks
1. Enter system view. system-view N/A
2. Enter OpenFlow instance
view. openflow instance instance-id N/A
3. Set the connection detection
interval. controller echo-request interval
interval-value
By default, the connection
detection interval is 5 seconds.
As a best practice to reduce the
CPU load, set the connection
detection interval to a large value.
4. Set the reconnection interval. controller connect interval
interval-value By default, the reconnection
interval is 60 seconds.
Configuring an OpenFlow instance to support
dynamic MAC addresses
You can configure OpenFlow to support querying and deleting dynamic MAC addresses in MAC-IP
flow tables.
To configure an OpenFlow instance to support dynamic MAC addresses:
Step Command Remarks
1. Enter system view. system-view N/A
2. Enter OpenFlow instance
view. openflow instance instance-id N/A
3. Configure the OpenFlow
instance to support dynamic
MAC addresses. mac-ip dynamic-mac aware
By default, OpenFlow prohibits
controllers from querying and
deleting dynamic MAC
addresses.
Enabling packet loss prevention for OpenFlow
forwarding
In networks that require high OpenFlow forwarding performance, packet loss might occur on the
switch during the flow entry deployment process. The packet loss then causes OpenFlow forwarding
to fail. You can enable packet loss prevention to ensure successful OpenFlow forwarding without
packet loss.
When this feature is configured, ACLs cannot match packets by IPv6 address.
After you enable packet loss prevention, save the configuration and restart the switch to make the
configuration take effect.
To enable packet loss prevention for OpenFlow forwarding:
Step Command Remarks
1. Enter system view. system-view N/A
2. Enable packet loss
prevention for OpenFlow
forwarding. openflow lossless enable By default, the packet loss
prevention feature for OpenFlow
forwarding is disabled.

15
Enabling an OpenFlow instance to perform QinQ
tagging for double-tagged packets passing an
extensibility flow table
IMPORTANT:
This feature is available in Release 1121 and later.
By default, a double-tagged packet becomes single-tagged after it passes an extensibility flow table.
Perform this task to allow double-tagged packets to keep double-tagged after the packets pass an
extensibility flow table.
To enable an OpenFlow instance to perform QinQ tagging for double-tagged packets passing an
extensibility flow table:
Step Command Remarks
1. Enter system view. system-view N/A
2. Enter OpenFlow instance
view. openflow instance instance-id N/A
3. Enable the OpenFlow
instance to perform QinQ
tagging for double-tagged
packets passing an
extensibility flow table.
qinq-network enable
By default, a double-tagged
packet becomes single-tagged
after it passes an extensibility flow
table.
Disabling logging for successful flow table
modifications
This feature disables logging for successful flow table modifications. Logging for other events is not
affected.
To disable logging for successful flow table modifications:
Step Command Remarks
1. Enter system view. system-view N/A
2. Enter OpenFlow instance
view. openflow instance instance-id N/A
3. Disable logging for
successful flow table
modifications. flow-log disable By default, logging for successful
flow table modifications is
enabled.
Refreshing all Layer 3 flow entries in the MAC-IP
flow table for an OpenFlow instance
Perform this task to obtain all Layer 3 flow entries in the MAC-IP flow table from the controller again
if the Layer 3 flow entries have been overwritten.

16
To refresh all Layer 3 flow entries in the MAC-IP flow table for an OpenFlow instance:
Step Command
1. Enter system view system-view
2. Enter OpenFlow instance view. openflow instance instance-id
3. Refresh all Layer 3 flow entries in the MAC-IP
flow table. refresh ip-flow
Displaying and maintaining OpenFlow
Execute display commands in any view.
Task Command
Display the detailed information for an OpenFlow
instance. display openflow instance [ instance-id ]
Display flow table entries for an OpenFlow instance. display openflow instance instance-id flow-table
[ table-id ]
Display controller information for an OpenFlow
instance. display openflow instance instance-id controller
Display group table information for an OpenFlow
instance. display openflow instance instance-id group
[ group-id ]
Display meter information for an OpenFlow instance. display openflow instance instance-id meter
[ meter-id ]
Display summary OpenFlow instance information. display openflow summary
OpenFlow configuration example
Network requirements
As shown in Figure 7, perform the following tasks on the switch to enable OpenFlow communication
with the controller in specific VLANs:
•Create OpenFlow instance 1, associate VLANs 4092 and 4094 with the OpenFlow instance,
and activate the OpenFlow instance.
•Configure the controller connected to OpenFlow instance 1 to have the controller manage the
OpenFlow switch.