H3C MSR1000 OpenFlow Config Guide
H3C MSR1000 OpenFlow Config Guide
Audience
This documentation is intended for:
• Network planners.
• Field technical support and servicing engineers.
• Network administrators.
Conventions
The following information describes the conventions used in the documentation.
Command conventions
Convention Description
Boldface Bold text represents commands and keywords that you enter literally as shown.
Italic Italic text represents arguments that you replace with actual values.
[] Square brackets enclose syntax choices (keywords or arguments) that are optional.
Braces enclose a set of required syntax choices separated by vertical bars, from which
{ x | y | ... }
you select one.
Square brackets enclose a set of optional syntax choices separated by vertical bars,
[ x | y | ... ]
from which you select one or none.
Asterisk marked braces enclose a set of required syntax choices separated by vertical
{ x | y | ... } *
bars, from which you select a minimum of one.
Asterisk marked square brackets enclose optional syntax choices separated by vertical
[ x | y | ... ] *
bars, from which you select one choice, multiple choices, or none.
The argument or keyword and argument combination before the ampersand (&) sign
&<1-n>
can be entered 1 to n times.
# A line that starts with a pound (#) sign is comments.
GUI conventions
Convention Description
Window names, button names, field names, and menu items are in Boldface. For
Boldface
example, the New User window opens; click OK.
> Multi-level menus are separated by angle brackets. For example, File > Create >
Convention Description
Folder.
Symbols
Convention Description
An alert that calls attention to important information that if not understood or followed
WARNING! can result in personal injury.
An alert that calls attention to important information that if not understood or followed
CAUTION: can result in data loss, data corruption, or damage to hardware or software.
Convention Description
Documentation feedback
You can e-mail your comments about product documentation to info@[Link].
We appreciate your comments.
Contents
Configuring OpenFlow ··················································································· 1
About OpenFlow ················································································································································ 1
OpenFlow network components················································································································· 1
OpenFlow switch ········································································································································ 1
OpenFlow port············································································································································ 1
OpenFlow instance ···································································································································· 2
OpenFlow flow table··································································································································· 3
Group table ················································································································································ 5
Meter table ················································································································································· 5
OpenFlow channel ····································································································································· 6
OpenFlow controller ··································································································································· 8
Protocols and standards ···························································································································· 9
OpenFlow tasks at a glance ······························································································································· 9
Configuring OpenFlow instances ······················································································································· 9
Creating an OpenFlow instance ················································································································· 9
Configuring the OpenFlow instance mode ······························································································· 10
Configuring inband management VLANs ································································································· 10
Configuring flow tables and flow entries for an OpenFlow instance························································· 11
Setting the controller connection mode ···································································································· 12
Preventing an OpenFlow instance from reporting the specified types of ports to controllers ·················· 12
Enabling the OpenFlow data plane forwarding feature ············································································ 13
Activating or reactivating an OpenFlow instance ····················································································· 13
Configuring OpenFlow instance attributes ······························································································· 13
Configuring controllers for an OpenFlow switch ······························································································ 14
Excluding the specified VLANs from the VLANs in which traffic is forwarded in the OpenFlow forwarding
process····························································································································································· 15
Configuring an OpenFlow instance to act as an SSL server to listen to controllers········································· 15
Refreshing all Layer 3 flow entries in the MAC-IP flow tables for an OpenFlow instance ······························· 16
Shutting down an interface by OpenFlow ········································································································ 16
Enabling SNMP notifications for OpenFlow ····································································································· 17
Configuring OpenFlow flow monitor parameters ······························································································ 17
Verifying and maintaining OpenFlow ··············································································································· 18
Displaying the configuration and operating status of OpenFlow ······························································ 18
Clearing statistics on packets that a controller sends and receives for an OpenFlow instance ··············· 19
OpenFlow configuration examples ··················································································································· 19
Example: Configuring OpenFlow in global mode ····················································································· 19
Example: Configuring OpenFlow in VLAN mode ····················································································· 20
Appendix A Application restrictions ·················································································································· 21
Flow entry restrictions ······························································································································ 21
Restrictions for merging the action list into the action set ········································································ 22
Packet-out messages restrictions ············································································································ 23
Packet-in messages restrictions ·············································································································· 23
LLDP frame matching ······························································································································ 24
Flow table modification messages restrictions ························································································· 24
Appendix B MAC-IP flow table ························································································································· 24
Capabilities supported by the MAC-IP flow table ····················································································· 24
MAC-IP flow table restrictions ·················································································································· 27
Table-miss flow entry of MAC-IP flow tables···························································································· 28
Dynamic aware ········································································································································ 28
MAC-IP flow table cooperating with extensibility flow table ····································································· 28
Appendix C VLAN tagging and untagging flow tables ····················································································· 29
Capabilities supported by the VLAN tagging flow table ··········································································· 29
Capabilities supported by the VLAN untagging flow table ······································································· 30
i
Configuring OpenFlow
About OpenFlow
OpenFlow is the communications interface defined between the control and forwarding layers of a
Software-Defined Networking architecture. With OpenFlow, you can perform centralized data
forwarding management for physical and virtual devices through controllers.
Switch
OpenFlow
OpenFlow channel protocol
SSL
Controller
Flow table
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.
OpenFlow port
OpenFlow supports the following types of ports:
• Physical port—Corresponds to a hardware interface, such as an Ethernet interface. A physical
port can be either an ingress port or an output port.
1
• Logical port—Does not correspond to a hardware interface and might be defined by
non-OpenFlow methods. For example, aggregate interfaces and tunnel interfaces are logical
ports. 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 ports that can be used to forward a packet.
Controller—OpenFlow controller.
Table—Flow table.
In port—Packet ingress port.
Any—Generic port description.
Local—Local CPU.
Normal—Normal forwarding process.
Flood—Flooding.
Except the Any type, all reserved ports can be used as output ports. Only the Controller and
Local types can be used as ingress ports.
OpenFlow instance
Unless otherwise stated, an OpenFlow switch refers to an OpenFlow instance throughout this
document.
You can configure one or more OpenFlow instances on the same device. A controller considers each
OpenFlow instance as a separate OpenFlow switch and deploys forwarding instructions to it.
OpenFlow instance mode
An OpenFlow instance operates in one of the following modes:
• Global mode—When the global mode is enabled for an OpenFlow instance, the flow entries
take effect on packets within the network. All service interfaces on the device belong to the
OpenFlow instance.
• VLAN mode—When the VLAN mode is enabled for an OpenFlow instance, the flow entries
take effect only on packets within VLANs associated with the OpenFlow instance. You must
associate the OpenFlow instance with VLANs. All interfaces in the associated VLANs belong to
the OpenFlow instance.
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 device information to the controller:
• Capabilities supported by OpenFlow.
• Information about ports that belong to the OpenFlow instance.
An activated OpenFlow instance must be reactivated when any of the OpenFlow instance
configurations are changed.
After reactivation, the OpenFlow instance is disconnected from all controllers and then reconnected
to them.
OpenFlow instance port
An OpenFlow switch sends information about the following ports to the controller:
• Physical ports.
• Logical ports.
2
• 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
order specified by the instruction list. 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:
(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—No explicit action exists 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 the output action, the packet is assigned to the queue
attached to this port for scheduling and forwarding. The forwarding behavior is dictated by
the configuration of the queue and provides basic QoS support.
(Optional.) Push-Tag/Pop-Tag—Switches support the ability to push or pop tags, such as
VLAN tags, MPLS tags, and PBB tags.
(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.
(Optional.) Change-TTL—The Change-TTL actions modify the values of the IPv4 TTL,
IPv6 Hop Limit, or MPLS TTL in the packet. Change-TTL actions are always applied to the
outermost header. The Change-TTL actions include the following the actions: Set TTL,
Decrement TTL, and Copy TTL (outwards or inwards).
• 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, regardless
of whether or not it has matched packets.
• Cookie—Custom data specified by the controller. The data are not used for processing packets,
and might be used by the controller for matching flow entries.
• Flags—Flag for modifying the flow entry management method. For example, the
OFPFF_SEND_FLOW_REM flag triggers the switch to send Flow-Removed messages for the
flow entry to the controller.
Figure 2 Flow entry components
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 with flow entries of the first flow table, which is flow table 0. A flow 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 a flow table contains an action list, the OpenFlow switch immediately executes the actions for
a copy of the packet in this table.
4
Figure 3 OpenFlow forwarding workflow
OpenFlow Switch
Packet+
Ingress Ingress port+
Packet port Execute Packet
Metadata Packet
In Table 0 Table 1 Table n Action Out
Action Action Action Set
Set = {} Set Set
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.
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.
Select—Execute one bucket in the group.
Indirect—Execute the one defined bucket in the group.
Fast failover—Execute the first live bucket.
• 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.
Figure 4 Group entry components
Meter table
Meters enable OpenFlow to implement various simple QoS operations, such as rate-limiting. A
meter table contains meter entries.
A meter entry contains the following fields:
• Meter Identifier—A 32 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.
5
Figure 5 Meter entry components
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 with the switch to perform the
following operations:
• Configure and manage the switch.
• Receive events from the switch.
• Send packets out the switch.
The OpenFlow channel is usually encrypted by using TLS. Also, an OpenFlow channel can be run
directly over TCP.
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
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 representing 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.
6
• 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
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
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
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.
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 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.
7
OpenFlow controller
Controller roles
A switch can establish connections with multiple controllers. 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. 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 operations:
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.
Controller connection modes
An OpenFlow instance can connect to one or more controllers, depending on the controller
connection 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.
• 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.
Main and auxiliary connections
The OpenFlow channel can have one main connection and multiple auxiliary connections.
• Main connection—Processes control messages to complete operations such as deploying
entries, obtaining data, and sending information. The main connection must be a reliable TCP
or SSL connection.
• Auxiliary connection—Improves the communication performance between the controller and
OpenFlow switches. An auxiliary connection can have the different destination IP address and
port number than the main connection.
Connection interruption mode
When an OpenFlow switch is disconnected from all controllers, the OpenFlow switch is set to either
of the following modes:
• Secure—The OpenFlow switch forwards traffic based on flow tables and does not remove
unexpired flow entries. If the output action in a matching flow entry is to forward traffic to a
controller, the traffic is discarded. This is the default forwarding mode.
• 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.
8
Protocols and standards
OpenFlow Switch Specification Version 1.3.3
9
tcp dscp dscp-value
By default, no DSCP value is set for OpenFlow packets.
10
Procedure
1. Enter system view.
system-view
2. Enter OpenFlow instance view.
openflow instance instance-id
3. Configure inband management VLANs for the OpenFlow instance.
in-band management vlan vlan-id-list
By default, no inband management VLANs are configured for an OpenFlow instance.
11
precedence dynamic arp
By default, an OpenFlow instance does not allow dynamic ARP entries to overwrite OpenFlow
ARP entries.
Only MAC-IP flow tables support this feature.
6. Allow the deployed flow tables to include link aggregation member ports.
permit-port-type member-port
By default, the deployed flow tables cannot include link aggregation member ports.
7. Configure the default action of table-miss flow entries to forward packets to the normal pipeline.
default table-miss permit
By default, the default action of table-miss flow entries is to drop packets.
12
Enabling the OpenFlow data plane forwarding feature
About this task
In a forwarding-control separated network, you must enable this feature to deliver the following
mappings to the controller:
• Site-facing interface (where an AC is created) to VXLAN mappings.
Based on these mappings, the controller generates flow entries and then deploys the flow entries to
the switch.
Procedure
1. Enter system view.
system-view
2. Enter OpenFlow instance view.
openflow instance instance-id
3. Enable the OpenFlow data plane forwarding feature.
data-plane enable
By default, the OpenFlow data plane forwarding feature is disabled.
13
Set the reconnection interval.
controller connect interval interval
The default setting is 60 seconds.
5. Configure MAC address-related features.
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.
Configure the OpenFlow instance to support matching the dynamic MAC addresses in the
query and deletion flow entry instructions sent from controllers.
mac-ip dynamic-mac aware
By default, an OpenFlow instance ignores dynamic MAC addresses in the query and
deletion flow entry instructions sent from controllers.
Only MAC-IP flow tables support this feature.
6. Prevent the OpenFlow instance from reporting ARP packets to the specified controllers.
forbidden packet-in arp controller controller-id-list
By default, no controllers to which ARP packets are forbidden to be reported are configured.
This feature forbids an OpenFlow instance to report ARP packets to the specified controllers to
prevent the controllers from being affected by a large number of packets.
7. Disable logging for successful flow table modifications.
flow-log disable
By default, logging for successful flow table modifications is enabled.
14
By default, an OpenFlow instance does not have auxiliary connections to a controller.
If no destination IP address and port number are specified, the auxiliary connection uses the
destination IP address and port number configured for the main connection.
5. (Optional.) Set the connection interruption mode.
fail-open mode { secure standalone }
By default, the secure mode is used.
6. (Optional.) Enable OpenFlow connection backup.
tcp-connection backup
By default, OpenFlow connection backup is enabled.
This feature is available only on a system with two MPUs.
This feature prevents connection interruption when an active/standby switchover occurs.
This feature is available for only OpenFlow connections established over TCP.
15
Procedure
1. Enter system view.
system-view
2. Enter OpenFlow instance view.
openflow instance instance-id
3. Configure an OpenFlow instance to act as an SSL server to listen to controllers.
listening port port-number ssl ssl-policy-name
By default, an OpenFlow instance is not configured to acts as an SSL server listen to
controllers.
16
Enabling SNMP notifications for OpenFlow
About this task
This feature enables OpenFlow to generate SNMP notifications for important OpenFlow events. For
the notifications to be sent correctly, you must also configure SNMP on the device. For more
information about SNMP configuration, see SNMP configuration in Network Management and
Monitoring Configuration Guide.
Procedure
1. Enter system view.
system-view
2. Enable SNMP notifications for OpenFlow.
snmp-agent trap enable openflow [ connect-state ]
By default, SNMP notifications are enabled for OpenFlow.
NOTE:
Use the display openflow flow-table command to view flow entries. In the command
output, the byte count and packet count fields for a flow entry represent the number of bytes
matching the flow entry and the number of packets matching the flow entry.
The controller deploys the <action> operation to enable flow monitor for a flow entry on the device.
The following NETCONF message enables flow monitor for all flow entries with CookieID 1 in flow
table 0 for the OpenFlow instance corresponding to the specified datapath ID.
<rpc message-id="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<action>
<error-option>stop-on-error</error-option>
<top xmlns="[Link]
<OFP>
<FlowMonitor>
<Application>
<DatapathID>410026760491999</DatapathID>
<TableID>0</TableID>
<CookieID>1</CookieID>
<Enable>1</Enable>
</Application>
</FlowMonitor>
</OFP>
17
</top>
</action>
</rpc>
18
• Display group table information for an OpenFlow instance.
display openflow instance instance-id group [ group-id ]
• Display meter table information for an OpenFlow instance.
display openflow instance instance-id meter [ meter-id ]
Host B
[Link]
Procedure
# Create OpenFlow instance 1 and configure it to operate in global mode.
[Device] openflow instance 1
[Device-of-inst-1] classification global
19
Configuration information:
Description : --
Active status : Active
Inactive configuration:
None
Active configuration:
Classification: Global(Standard)
...
Port information:
Route-Aggregation1
Active channel information:
Controller 1 IP address: [Link] port: 6633
Host B
[Link]
Procedure
# Create VLANs 4092 and 4094.
<Switch> system-view
[Switch] vlan 4092
[Switch-vlan4092] quit
[Switch] vlan 4094
[Switch-vlan4094] quit
20
Verifying the configuration
# View detailed information about the OpenFlow instance.
[Switch] display openflow instance 1
Instance 1 information:
Configuration information:
Description : --
Active status : Active
Inactive configuration:
None
Active configuration:
Classification: VLAN, total VLANs(2)
4092, 4094
...
Port information:
GigabitEthernet0/0/3
Active channel information:
Controller 1 IP address: [Link] port: 6633
21
If protocols are enabled, protocol packets (except LLDP frames) are processed by the corresponding
protocols instead of the OpenFlow protocol.
For more information about LLDP frame matching, see "LLDP frame matching."
Metadata matching
Metadata passes matching information between flow tables. The controller deploys metadata
matching entries only to non-first flow tables. If the controller deploys a metadata matching entry to
the first flow table, the switch returns an unsupported flow error.
Instruction restrictions
Table 2 Instruction restrictions
Write-Metadata/mask The flow entries of the last table of the pipeline cannot include this
Goto-Table instruction. Otherwise, the switch returns an unsupported flow error.
Restrictions for merging the action list into the action set
The switch follows the following restrictions to merge the action list into the action set.
Non-output actions
When the action set and the action list do not contain the Output or Group action, the following rules
apply:
• If actions in the action set do not conflict with actions in the action list, the switch merges the
action list into the action set.
• If actions in the action set conflict with actions in the action list, actions in the action list are
replaced with actions in the action set.
Output actions
When the action set and the action list contain the Output action or the Group action, the following
rules apply:
• If both the action list and the action set contain an Output action, the Output action in the action
list takes precedence. The Output action in the action list does not modify the packet. The
Output action in the action set is executed at the last step of the pipeline processing to modify
the packet.
• If either the action list or the action set contains an Output action, the port specified by the
Output action is treated as the output port. The actions are executed in the order defined by the
action set rules.
• If the action list contains an Output action and the action set contains a Group action, the
following rules apply:
The Output action does not modify the packet.
22
The Group action is executed.
23
• If the VLAN tag of the packet is the same as the PVID of the ingress port, the switch removes
the VLAN tag.
• If the VLAN tag of the packet is different from the PVID of the ingress port, the switch does not
remove the VLAN tag.
Packet buffer
If a packet-in message is sent to controller due to no matching flow entry, the switch supports
buffering the packet contained in the packet-in message. The buffer size is 1K packets.
If a packet-in message is sent to controller for other reasons, the switch does not support buffering
the packet contained in the packet-in message. The switch must send the full packet to the controller,
and the cookie field of the packet is set to 0xFFFFFFFFFFFFFFFF.
24
The Layer 2 flow entries are implemented by using MAC address entries. Table 3 describes the
capabilities supported by Layer 2 flow entries.
Table 3 Capabilities supported by Layer 2 flow entries
Item Capabilities
The MAC-IP flow table must support the following match fields:
Required match fields • VLAN ID.
• Unicast destination MAC address.
Optional match fields N/A
Required actions Specifying the output port.
The MAC-IP flow table can optionally support the following instructions:
• Goto-Table—When the switch has multiple tables, the switch adds this
Optional actions instruction by default if the controller does not deploy it.
• Write-Metadata—When the switch has multiple tables, the switch adds this
instruction by default if the controller does not deploy it.
The Layer 3 flow entries are implemented by using routing entries. Table 4 describes the capabilities
supported by Layer 3 flow entries.
Table 4 Capabilities supported by Layer 3 flow entries
Item Capabilities
The MAC-IP flow table must support the following match fields:
• VLAN ID.
• Ethernet type.
Required match fields
• Unicast destination IP address.
• Unicast destination MAC address, which must be the MAC address of the
VLAN interface for the VLAN that is matched.
The VXLAN Layer 2 flow entries are implemented by using MAC address entries. Table 5 describes
the capabilities supported by VXLAN Layer 2 flow entries.
Table 5 Capabilities supported by VXLAN Layer 2 flow entries
Item Capabilities
Required match fields Unicast destination MAC address.
Optional match fields N/A
The MAC-IP flow table must support the following actions:
Required actions • Specifying a tunnel interface as the output port.
• Specifying the tunnel ID.
25
Item Capabilities
The MAC-IP flow table can optionally support the following instructions:
• Goto-Table—When the switch has multiple tables, the switch adds this
Optional actions instruction by default if the controller does not deploy it.
• Write-Metadata—When the switch has multiple tables, the switch adds this
instruction by default if the controller does not deploy it.
The VXLAN Layer 3 flow entries are implemented by using routing entries. Table 6 describes the
capabilities supported by VXLAN Layer 3 flow entries.
Table 6 Capabilities supported by VXLAN Layer 3 flow entries
Item Capabilities
The MAC-IP flow table must support the following match fields:
Required match fields • Ethernet type.
• Unicast destination IP address.
Optional match fields N/A
The MAC-IP flow table must support the following actions:
• Specifying a tunnel interface as the output port.
Required actions
• Specifying the tunnel ID.
• Modifying the destination MAC address.
The MAC-IP flow table can optionally support the following actions:
• Goto-Table—When the switch has multiple tables, the switch adds this
Optional actions instruction by default if the controller does not deploy it.
• Write-Metadata—When the switch has multiple tables, the switch adds this
instruction by default if the controller does not deploy it.
The VXLAN QinQ flow entries are implemented by using ARP entries. Table 7 describes the
capabilities supported by VXLAN QinQ flow entries.
Table 7 Capabilities supported by VXLAN QinQ entries
Item Capabilities
The MAC-IP flow table must support the following match fields:
• Ethernet type.
Required match fields
• Unicast destination IP address.
• Tunnel ID.
Optional match fields N/A
The MAC-IP flow table must support the following actions:
• Specifying a tunnel interface or interface where an AC resides as the output
Required actions port.
• Modifying the destination MAC address.
• Adding a VLAN tag.
Optional actions Adding an inner VLAN tag.
The routing flow entries are implemented by using routing entries. Table 8 describes the capabilities
supported by routing flow entries.
Table 8 Capabilities supported by routing entries
Item Capabilities
Required match fields The MAC-IP flow table must support the following match fields:
26
Item Capabilities
• Ethernet type.
• Unicast destination IP address and subnet mask.
Item Restrictions
The destination MAC address cannot be the MAC address of the switch to which
Match fields
the flow entry is deployed.
Actions The output port must belong to the VLAN that is matched.
Table 10 Restrictions for deploying Layer 3 flow entries for the MAC-IP flow table
Item Restrictions
The VLAN interface of the VLAN that is matched is in up state.
The destination MAC address is the MAC address of the VLAN interface for the
Match fields VLAN that is matched.
The destination IP address cannot be the IP address of the switch to which the
flow entry is deployed.
The specified output port must belong to the destination VLAN.
The destination MAC address cannot be the MAC address of the switch to which
the flow entry is deployed.
Actions
If the switch modifies the source MAC address, the source MAC address must be
the MAC address of the VLAN interface for the VLAN to which the output port
belongs.
To deploy a Layer 3 flow entry, make sure the following requirements are met:
• The VLAN interface of the matched VLAN is in up state.
• The switch sends the controller a packet that indicates the VLAN interface acts as an OpenFlow
port. The link state and the MAC address of the VLAN interface are also included in the packet.
The switch reports the VLAN interface deletion to the controller and the controller removes the
corresponding Layer 3 flow entry.
The controller ensures the correctness of Layer 3 flow entries. The switch does not check for the
restrictions for Lay 3 flow entries.
Table 11 Restrictions for deploying VXLAN Layer 2 flow entries for the MAC-IP flow table
Item Restrictions
The destination MAC address cannot be MAC address of the switch to which the
Match fields
flow entry is deployed.
The output port must be an existing tunnel interface.
Actions
The VXLAN that corresponds to the specified tunnel ID (VNI) must exist.
27
Table 12 Restrictions for deploying VXLAN Layer 3 flow entries for the MAC-IP flow table
Item Restrictions
The destination IP address cannot be the IP address of the switch to which the
Match fields
flow entry is deployed.
The output port must be an existing tunnel interface.
The VXLAN and the VSI interface that correspond to the specified tunnel ID (VNI)
Actions must exist.
The destination MAC address cannot be MAC address of the switch to which the
flow entry is deployed.
Table 13 Restrictions for deploying VXLAN QinQ entries for the MAC-IP flow table
Item Restrictions
Match fields The tunnel ID must be the VXLAN ID of the VSI mapped to the AC.
The VXLAN ID of the VSI mapped to the output port must be the same as the
tunnel ID.
A gateway interface (VSI interface) must be specified for the VSI.
Actions
On a forwarding-control separated network, the inner VLAN tag and outer VLAN
tag must match the frame match criteria of the AC and the interface where the AC
resides must be configured with the vtep access port command.
Dynamic aware
On an OpenFlow switch that supports MAC-IP flow tables, you can configure OpenFlow to support
querying and deleting dynamic MAC address flow entries.
The controller can query and delete dynamic MAC address flow entries by specifying a VLAN, a
MAC address, or the combination of a MAC address and a VLAN.
28
Table 14 Metadata mask meanings
Matching restrictions
When the output action in an extensibility flow table is not Normal, the following rules apply:
• The MAC-IP flow table does not take effect.
• All actions are executed according to the extensibility flow table.
When the output action in an extensibility flow table is Normal, the following rules apply:
• The output action is executed according to the MAC-IP flow table.
• The other actions are executed according to the extensibility flow table.
Item Capabilities
The VLAN tagging flow table must support the following match fields:
Required match fields • input-port.
• vlan.
The VLAN tagging flow table can optionally support the following actions:
Optional actions • Output (normal).
• Goto-Table.
29
The Push-Tag and Set-Field (VLAN) actions must be in the action list of the Apply-Actions instruction.
The Push-Tag and Set-Field (VLAN) actions can be used as follows:
• Push-Tag + Set-Field (value1)—Adds a VLAN tag value1.
• Set-Field (value1) + Push-Tag + Set-Field (value2)—Modifies the VLAN tag of the packet to
value1 and adds a VLAN tag value2.
• Push-Tag + Set-Field (value1) + Push-Tag + Set-Field (value2)—Adds inner VLAN tag
value2 and outer VLAN tag value1.
The Goto-Table instruction is optional and does not take effect. The flow table specified by this
instruction can only be the next of the VLAN tagging flow table.
Item Capabilities
The VLAN untagging flow table must support the following match fields:
Required match fields • egress port—Matches the egress port of packets.
• vlan—Matches the outer VLAN tag of packets.
The VLAN untagging flow table can optionally support the inner vlan match field
Optional match fields
that matches the inner VLAN tag of double-tagged packets.
The following actions in the action list of the Apply-Actions instruction must be
applied immediately:
Required actions
• Pop-Tag.
• Set-Field (VLAN).
Optional actions The VLAN untagging flow table can optionally support the Output (normal) action.
30