1 <?xml version=
"1.0" encoding=
"utf-8"?>
6 This document aims to comprehensively document all of the OpenFlow actions
7 and instructions, both standard and non-standard, supported by Open
8 vSwitch, regardless of origin. The document includes information of
9 interest to Open vSwitch users, such as the semantics of each supported
10 action and the syntax used by Open vSwitch tools, and to developers seeking
11 to build controllers and switches compatible with Open vSwitch, such as the
12 wire format for each supported message.
18 In this document, we define an
<dfn>action
</dfn> as an OpenFlow action,
19 which is a kind of command that specifies what to do with a packet.
20 Actions are used in OpenFlow flows to describe what to do when the flow
21 matches a packet, and in a few other places in OpenFlow. Each version of
22 the OpenFlow specification defines standard actions, and beyond that many
23 OpenFlow switches, including Open vSwitch, implement extensions to the
28 OpenFlow groups actions in two ways: as an
<dfn>action list
</dfn> or an
29 <dfn>action set
</dfn>, described below.
35 An
<dfn>action list
</dfn>, a concept present in every version of OpenFlow,
36 is simply an ordered sequence of actions. The OpenFlow specifications
37 require a switch to execute actions within an action list in the order
38 specified, and to refuse to execute an action list entirely if it cannot
39 implement the actions in that order [OpenFlow
1.0, section
3.3], with one
40 exception: when an action list outputs multiple packets, the switch may
41 output the packets in an order different from that specified. Usually,
42 this exception is not important, especially in the common case when the
43 packets are output to different ports.
49 OpenFlow
1.1 introduced the concept of an
<dfn>action set
</dfn>. An action
50 set is also a sequence of actions, but the switch reorders the actions and
51 drops duplicates according to rules specified in the OpenFlow
52 specifications. Because of these semantics, some standard OpenFlow actions
53 cannot usefully be included in an action set. For some, but not all, Open
54 vSwitch extension actions, Open vSwitch defines its own action set
55 semantics and ordering.
59 The OpenFlow pipeline has an action set associated with it as a packet is
60 processed. After pipeline processing is otherwise complete, the switch
61 executes the actions in the action set.
65 Open vSwitch applies actions in an action set in the following order:
66 Except as noted otherwise below, the action set only executes at most a
67 single action of each type, and when more than one action of a given type
68 is present, the one added to the set later replaces the earlier action:
72 <li><code>strip_vlan
</code></li>
73 <li><code>pop_mpls
</code></li>
74 <li><code>decap
</code></li>
75 <li><code>encap
</code></li>
76 <li><code>push_mpls
</code></li>
77 <li><code>push_vlan
</code></li>
78 <li><code>dec_ttl
</code></li>
79 <li><code>dec_mpls_ttl
</code></li>
80 <li><code>dec_nsh_ttl
</code></li>
83 All of the following actions are executed in the order added to the
84 action set, with cumulative effect. That is, when multiple actions
85 modify the same part of a field, the later modification takes effect,
86 and when they modify different parts of a field (or different fields),
87 then both modifications are applied:
91 <li><code>load
</code></li>
92 <li><code>move
</code></li>
93 <li><code>mod_dl_dst
</code></li>
94 <li><code>mod_dl_src
</code></li>
95 <li><code>mod_nw_dst
</code></li>
96 <li><code>mod_nw_src
</code></li>
97 <li><code>mod_nw_tos
</code></li>
98 <li><code>mod_nw_ecn
</code></li>
99 <li><code>mod_nw_ttl
</code></li>
100 <li><code>mod_tp_dst
</code></li>
101 <li><code>mod_tp_src
</code></li>
102 <li><code>mod_vlan_pcp
</code></li>
103 <li><code>mod_vlan_vid
</code></li>
104 <li><code>set_field
</code></li>
105 <li><code>set_tunnel
</code></li>
106 <li><code>set_tunnel64
</code></li>
109 <li><code>set_queue
</code></li>
111 <code>group
</code>,
<code>output
</code>,
<code>resubmit
</code>,
112 <code>ct_clear
</code>, or
<code>ct
</code>. If more than one of these
113 actions is present, then the one listed earliest above is executed and
114 the others are ignored, regardless of the order in which they were added
115 to the action set. (If none of these actions is present, the action set
116 has no real effect, because the modified packet is not sent anywhere and
117 thus the modifications are not visible.)
122 An action set may only contain the actions listed above.
125 <h2>Error Handling
</h2>
128 Packet processing can encounter a variety of errors:
132 <dt>Bridge not found
</dt>
135 Open vSwitch supports an extension to the standard OpenFlow
136 <code>controller
</code> action called a ``continuation,'' which allows
137 the controller to interrupt and later resume the processing of a packet
138 through the switch pipeline. This error occurs when such a packet's
139 processing cannot be resumed, e.g. because the bridge processing it has
140 been destroyed. Open vSwitch reports this error to the controller as
141 Open vSwitch extension error
<code>NXR_STALE
</code>.
145 This error prevents packet processing entirely.
149 <dt>Recursion too deep
</dt>
152 While processing a given packet, Open vSwitch limits the flow table
153 recursion depth to
64, to ensure that packet processing uses a finite
154 amount of time and space. Actions that count against the recursion
155 limit include
<code>resubmit
</code> from a given OpenFlow table to the
156 same or an earlier table,
<code>group
</code>, and
<code>output
</code>
161 A
<code>resubmit
</code> from one table to a later one (or,
162 equivalently. a
<code>goto_table
</code> instruction) does not count
163 against the depth limit because resubmits to strictly monotonically
164 increasing tables will eventually terminate. OpenFlow tables are most
165 commonly traversed in numerically increasing order, so this limit has
166 little effect on conventionally designed OpenFlow pipelines.
170 This error terminates packet processing. Any previous side effects
171 (e.g. output actions) are retained.
175 Usually this error indicates a loop or other bug in the OpenFlow flow
176 tables. To assist debugging, when this error occurs, Open vSwitch
2.10
177 and later logs a trace of the packet execution, as if by
178 <code>ovs-appctl ofproto/trace
</code>, rate-limited to one per minute
179 to reduce the log volume.
183 <dt>Too many resubmits
</dt>
186 Open vSwitch limits the total number of
<code>resubmit
</code> actions
187 that a given packet can execute to
4,
096. For this purpose,
188 <code>goto_table
</code> instructions and output to the
189 <code>table
</code> port are treated like
<code>resubmit
</code>. This
190 limits the amount of time to process a single packet.
194 Unlike the limit on recursion depth, the limit on resubmits counts all
195 resubmits, regardless of direction.
199 This error has the same effect, including logging, as exceeding the
200 recursion depth limit.
204 <dt>Stack too deep
</dt>
207 Open vSwitch limits the amount of data that the
<code>push
</code>
208 action can put onto the stack at one time to
64 kB of data.
212 This error terminates packet processing. Any previous side effects
213 (e.g. output actions) are retained.
217 <dt>No recirculation context
</dt>
218 <dt>Recirculation conflict
</dt>
220 These errors indicate internal errors inside Open vSwitch and should
221 generally not occur. If you notice recurring log messages about these
222 errors, please report a bug.
225 <dt>Too many MPLS labels
</dt>
228 Open vSwitch can process packets with any number of MPLS labels, but
229 its ability to push and pop MPLS labels is limited, currently to
3
230 labels. Attempting to push more than the supported number of labels
231 onto a packet, or to pop any number of labels from a packet with more
232 than the supported number, raises this error.
236 This error terminates packet processing, retaining any previous side
237 effects (e.g. output actions). When this error arises within the
238 execution of a group bucket, it only terminates that bucket's
239 execution, not packet processing overall.
243 <dt>Invalid tunnel metadata
</dt>
246 Open vSwitch raises this error when it processes a Geneve packet that
247 has TLV options with an invalid form, e.g. where the length in a TLV
248 would extend past the end of the options.
252 This error prevents packet processing entirely.
256 <dt>Unsupported packet type
</dt>
259 When a
<code>encap
</code> action encapsulates a packet, Open vSwitch
260 raises this error if it does not support the combination of the new
261 encapsulation with the current packet.
<code>encap(ethernet)
</code>
262 raises this error if the current packet is not an L3 packet, and
263 <code>encap(nsh)
</code> raises this error if the current packet is not
264 Ethernet, IPv4, IPv6, or NSH.
268 When a
<code>decap
</code> action decapsulates a packet, Open vSwitch
269 raises this error if it does not support the type of inner packet.
270 <code>decap
</code> of an Ethernet header raises this error if a VLAN
271 header is present,
<code>decap
</code> of a NSH packet raises this error
272 if the NSH inner packet is not Ethernet, IPv4, IPv6, or NSH, and
273 <code>decap
</code> of other types of packets is unsupported and also
278 This error terminates packet processing, retaining any previous side
279 effects (e.g. output actions). When this error arises within the
280 execution of a group bucket, it only terminates that bucket's
281 execution, not packet processing overall.
286 <h2>Inconsistencies
</h2>
289 OpenFlow
1.0 allows any action to be part of any flow, regardless of the
290 flow's match. Some combinations do not make sense, e.g. an
291 <code>set_nw_tos
</code> action in a flow that matches only ARP packets or
292 <code>strip_vlan
</code> in a flow that matches packets without VLAN tags.
293 Other combinations have varying results depending on the kind of packet
294 that the flow processes, e.g. a
<code>set_nw_src
</code> action in a flow
295 that does not match on Ethertype will be treated as a no-op when it
296 processes a non-IPv4 packet. Nevertheless OVS allows all of the above in
297 conformance with OpenFlow
1.0, that is, the following will succeed:
301 $ ovs-ofctl -O OpenFlow10 add-flow br0 arp,actions=mod_nw_tos:
12
302 $ ovs-ofctl -O OpenFlow10 add-flow br0 dl_vlan=
0xffff,actions=strip_vlan
303 $ ovs-ofctl -O OpenFlow10 add-flow br0 actions=mod_nw_src:
1.2.3.4
307 Open vSwitch calls these kinds of combinations
<dfn>inconsistencies
</dfn>
308 between match and actions. OpenFlow
1.1 and later forbid inconsistencies,
309 and disallow the examples described above by preventing such flows from
310 being added. All of the above, for example, will fail with an error
311 message if one replaces
<code>OpenFlow10
</code> by
<code>OpenFlow11
</code>.
315 OpenFlow
1.1 and later cannot detect and disallow all inconsistencies. For
316 example, the
<code>write_actions
</code> instruction arbitrarily delays
317 execution of the actions inside it, which can even be canceled with
318 <code>clear_actions
</code>, so that there is no way to ensure that its
319 actions are consistent with the packet at the time they execute. Thus,
320 actions with
<code>write_actions
</code> and some other contexts are exempt
321 from consistency requirements.
325 When OVS executes an action inconsistent with the packet, it treats it as a
329 <h2>Inter-Version Compatibility
</h2>
332 Open vSwitch supports multiple OpenFlow versions simultaneously on a single
333 switch. When actions are added with one OpenFlow version and then
334 retrieved with another, Open vSwitch does its best to translate between
339 Inter-version compatibility issues can still arise when different
340 connections use different OpenFlow versions. Backward compatibility is the
341 most obvious case. Suppose, for example, that an OpenFlow
1.1 session adds
342 a flow with a
<code>push_vlan
</code> action, for which there is no
343 equivalent in OpenFlow
1.0. If an OpenFlow
1.0 session retrieves this
344 flow, Open vSwitch must somehow represent the action.
348 Forward compatibility can also be an issue, because later OpenFlow versions
349 sometimes remove functionality. The best example is the
350 <code>enqueue
</code> action from OpenFlow
1.0, which OpenFlow
1.1 removed.
354 In practice, Open vSwitch uses a variety of strategies for inter-version
360 Most standard OpenFlow actions, such as
<code>output
</code> actions,
361 translate without compatibility issues.
365 Open vSwitch supports its extension actions in every OpenFlow version, so
366 they do not pose inter-version compatibility problems.
370 Open vSwitch sometimes adds extension actions to ensure backward or
371 forward compatibility. For example, for backward compatibility with the
372 <code>group
</code> action added in OpenFlow
1.1, Open vSwitch includes
373 an OpenFlow
1.0 extension
<code>group
</code> action.
378 Perfect inter-version compatibility is not possible, so best results
379 require OpenFlow connections to use a consistent version. One may enforce
380 use of a particular version by setting the
<code>protocols
</code> column
381 for a bridge, e.g. to force
<code>br0
</code> to use only OpenFlow
1.3:
385 ovs-vsctl set bridge br0 protocols=OpenFlow13
388 <h2>Field Specifications
</h2>
391 Many Open vSwitch actions refer to fields. In such cases, fields may
392 usually be referred to by their common names, such as
<code>eth_dst
</code>
393 for the Ethernet destination field, or by their full OXM or NXM names, such
394 as
<code>NXM_OF_ETH_DST
</code> or
<code>OXM_OF_ETH_DST
</code>. Before Open
395 vSwitch
2.7, only OXM or NXM field names were accepted.
399 Many actions that act on fields can also act on
<dfn>subfields
</dfn>, that
400 is, parts of fields, written as
401 <code><var>field
</var>[
<var>start
</var>..
<var>end
</var>]
</code>, where
402 <var>start
</var> is the first bit and
<var>end
</var> is the last bit to use
403 in
<var>field
</var>, e.g.
<code>vlan_tci[
13.
.15]
</code> for the VLAN PCP.
404 A single-bit subfield may also be written as
405 <code><var>field
</var>[
<var>offset
</var>]
</code>,
406 e.g.
<code>vlan_tci[
13]
</code> for the least-significant bit of the VLAN
407 PCP. Empty brackets may be used to explicitly designate an entire field,
408 e.g.
<code>vlan_tci[]
</code> for the entire
16-bit VLAN TCI header. Before
409 Open vSwitch
2.7, brackets were required in field specifications.
413 See
<code>ovs-fields
</code>(
7) for a list of fields and their names.
416 <h2>Port Specifications
</h2>
419 Many Open vSwitch actions refer to OpenFlow ports. In such cases, the port
420 may be specified as a numeric port number in the range
0 to
65,
535,
421 although Open vSwitch only assigns port numbers in the range
1 through
422 62,
279 to ports. OpenFlow
1.1 and later use
32-bit port numbers, but Open
423 vSwitch never assigns a port number that requires more than
16 bits.
427 In most contexts, the name of a port may also be used. (The most obvious
428 context where a port name may not be used is in an
<code>ovs-ofctl
</code>
429 command along with the
<code>--no-names
</code> option.) When a port's name
430 contains punctuation or could be ambiguous with other actions, the name may
431 be enclosed in double quotes, with JSON-like string escapes supported (see
436 Open vSwitch also supports the following standard OpenFlow port names (even
437 in contexts where port names are not otherwise supported). The
438 corresponding OpenFlow
1.0 and
1.1+ port numbers are listed alongside them
439 but should not be used in flow syntax:
443 <li><code>in_port
</code> (
65528 or
0xfff8;
0xfffffff8)
</li>
444 <li><code>table
</code> (
65529 or
0xfff9;
0xfffffff9)
</li>
445 <li><code>normal
</code> (
65530 or
0xfffa;
0xfffffffa)
</li>
446 <li><code>flood
</code> (
65531 or
0xfffb;
0xfffffffb)
</li>
447 <li><code>all
</code> (
65532 or
0xfffc;
0xfffffffc)
</li>
448 <li><code>controller
</code> (
65533 or
0xfffd;
0xfffffffd)
</li>
449 <li><code>local
</code> (
65534 or
0xfffe;
0xfffffffe)
</li>
450 <li><code>any
</code> or
<code>none
</code> (
65535 or
0xffff;
0xffffffff)
</li>
451 <li><code>unset
</code> (not in OpenFlow
1.0;
0xfffffff7)
</li>
454 <!-- What about OVS version compatibility as opposed to OF version -->
456 <group title=
"Output Actions">
458 These actions send a packet to a physical port or a controller. A packet
459 that never encounters an output action on its trip through the Open
460 vSwitch pipeline is effectively dropped. Because actions are executed in
461 order, a packet modification action that is not eventually followed by an
462 output action will not have an externally visible effect.
465 <action name=
"OUTPUT, OUTPUT_REG, OUTPUT_TRUNC">
466 <h2>The
<code>output
</code> action
</h2>
467 <syntax><var>port
</var></syntax>
468 <syntax><code>output:
</code><var>port
</var></syntax>
469 <syntax><code>output:
<var>field
</var></code></syntax>
470 <syntax><code>output(port=
<var>port
</var>, max_len=
<var>nbytes
</var>)
</code></syntax>
473 Outputs the packet to an OpenFlow port most commonly specified as
474 <var>port
</var>. Alternatively, the output port may be read from
475 <var>field
</var>, a field or subfield in the syntax described under
476 ``Field Specifications'' above. Either way, if the port is the
477 packet's input port, the packet is not output.
481 The port may be one of the following standard OpenFlow ports:
485 <dt><code>local
</code></dt>
487 Outputs the packet on the ``local port'' that corresponds to the
488 network device that has the same name as the bridge, unless the
489 packet was received on the local port. OpenFlow switch
490 implementations are not required to have a local port, but Open
491 vSwitch bridges always do.
494 <dt><code>in_port
</code></dt>
496 Outputs the packet on the port on which it was received. This is the
497 only standard way to output the packet to the input port (but see
498 ``Output to the Input port'', below).
503 The port may also be one of the following additional OpenFlow ports,
504 unless
<code>max_len
</code> is specified:
508 <dt><code>normal
</code></dt>
510 Subjects the packet to the device's normal L2/L3 processing. This
511 action is not implemented by all OpenFlow switches, and each switch
512 implements it differently.
515 <dt><code>flood
</code></dt>
517 Outputs the packet on all switch physical ports, except the port on
518 which it was received and any ports on which flooding is disabled.
519 Flooding can be disabled automatically on a port by Open vSwitch when
520 IEEE
802.1D spanning tree (STP) or rapid spanning tree (RSTP) is
521 enabled, or by a controller using an OpenFlow
522 <code>OFPT_MOD_PORT
</code> request to set the port's
523 <code>OFPPC_NO_FLOOD
</code> flag (
<code>ovs-ofctl mod-port
</code>
524 provides a command-line interface to set this flag).
527 <dt><code>all
</code></dt>
529 Outputs the packet on all switch physical ports except the port on
530 which it was received.
533 <dt><code>controller
</code></dt>
535 Sends the packet and its metadata to an OpenFlow controller or
536 controllers encapsulated in an OpenFlow ``packet-in'' message. The
537 separate
<code>controller
</code> action, described below, provides
538 more options for output to a controller.
543 Open vSwitch rejects output to other standard OpenFlow ports, including
544 <code>none
</code>,
<code>unset
</code>, and port numbers reserved for
545 future use as standard ports, with the error
546 <code>OFPBAC_BAD_OUT_PORT
</code>.
550 With
<var>max_len
</var>, the packet is truncated to at most
551 <var>nbytes
</var> bytes before being output. In this case, the output
552 port may not be a patch port. Truncation is just for the single output
553 action, so that later actions in the OpenFlow pipeline work with the
554 complete packet. The truncation feature is meant for use in monitoring
555 applications, e.g. for mirroring packets to a collector.
559 When an
<code>output
</code> action specifies the number of a port that
560 does not currently exist (and is not in the range for standard ports),
561 the OpenFlow specification allows but does not require OVS to reject
562 the action. All versions of Open vSwitch treat such an action as a
563 no-op. If a port with the number is created later, then the action
564 will be honored at that point. (OpenFlow requires OVS to reject output
565 to a port number that will never be valid, with
566 <code>OFPBAC_BAD_OUT_PORT
</code>, but this situation does not arise
567 when OVS is a software switch, since the user can add or renumber ports
572 A controller can suppress output to a port by setting its
573 <code>OFPPC_NO_FORWARD
</code> flag using an OpenFlow
574 <code>OFPT_MOD_PORT
</code> request (
<code>ovs-ofctl mod-port
</code>
575 provides a command-line interface to set this flag). When output is
576 disabled,
<code>output
</code> actions (and other actions that output to
577 the port) are allowed but have no effect.
581 Open vSwitch allows output to a port that does not exist, although
582 OpenFlow allows switches to reject such actions.
585 <!-- XXX output to normal details -->
586 <!-- XXX output to patch ports details -->
588 <h3>Output to the Input Port
</h3>
591 OpenFlow requires a switch to ignore attempts to send a packet out its
592 ingress port in the most straightforward way. For example,
593 <code>output:
234</code> has no effect if the packet has ingress port
594 234. The rationale is that dropping these packets makes it harder to
595 loop the network. Sometimes this behavior can even be convenient,
596 e.g. it is often the desired behavior in a flow that forwards a packet
597 to several ports (``floods'' the packet).
601 Sometimes one really needs to send a packet out its ingress port
602 (``hairpin''). In this case, use
<code>in_port
</code> to explicitly
603 output the packet to its input port, e.g.:
607 $ ovs-ofctl add-flow br0 in_port=
2,actions=in_port
611 This also works in some circumstances where the flow doesn't match on
612 the input port. For example, if you know that your switch has five
613 ports numbered
2 through
6, then the following will send every received
614 packet out every port, even its ingress port:
618 $ ovs-ofctl add-flow br0 actions=
2,
3,
4,
5,
6,in_port
626 $ ovs-ofctl add-flow br0 actions=all,in_port
630 Sometimes, in complicated flow tables with multiple levels of
631 <code>resubmit
</code> actions, a flow needs to output to a particular
632 port that may or may not be the ingress port. It's difficult to take
633 advantage of output to
<code>in_port
</code> in this situation. To
634 help, Open vSwitch provides, as an OpenFlow extension, the ability to
635 modify the
<code>in_port
</code> field. Whatever value is currently in
636 the
<code>in_port
</code> field is both the port to which output will be
637 dropped and the destination for
<code>in_port
</code>. This means that
638 the following adds flows that reliably output to port
2 or to ports
2
639 through
6, respectively:
643 $ ovs-ofctl add-flow br0
"in_port=2,actions=load:0->in_port,2"
644 $ ovs-ofctl add-flow br0
"actions=load:0->in_port,2,3,4,5,6"
648 If
<code>in_port
</code> is important for matching or other reasons, one
649 may save and restore it on the stack:
653 $ ovs-ofctl add-flow br0
actions=
"push:in_port,\
660 All versions of OpenFlow and Open vSwitch support
<code>output
</code>
661 to a literal
<var>port
</var>. Output to a register is an OpenFlow
662 extension introduced in Open vSwitch
1.3. Output with truncation is an
663 OpenFlow extension introduced in Open vSwitch
2.6.
667 <action name=
"CONTROLLER">
668 <h2>The
<code>controller
</code> action
</h2>
669 <syntax><code>controller
</code></syntax>
670 <syntax><code>controller:
</code><var>max_len
</var></syntax>
671 <syntax><code>controller(
</code><var>key
</var>[
<code>=
</code><var>value
</var>]
<code>,
</code> ...
<code>)
</code></syntax>
674 Sends the packet and its metadata to an OpenFlow controller or
675 controllers encapsulated in an OpenFlow ``packet-in'' message. The
676 supported options are:
680 <dt><code>max_len=
</code><var>max_len
</var></dt>
683 Limit to
<var>max_len
</var> the number of bytes of the packet to
684 send in the ``packet-in.'' A
<var>max_len
</var> of
0 prevents any
685 of the packet from being sent (thus, only metadata is included).
686 By default, the entire packet is sent, equivalent to a
687 <var>max_len
</var> of
65535.
691 <dt><code>reason=
</code><var>reason
</var></dt>
693 Specify
<var>reason
</var> as the reason for sending the message in
694 the ``packet-in.'' The supported reasons are
<code>no_match
</code>,
695 <code>action
</code>,
<code>invalid_ttl
</code>,
696 <code>action_set
</code>,
<code>group
</code>, and
697 <code>packet_out
</code>. The default reason is
<code>action
</code>.
700 <dt><code>id=
</code><var>controller_id
</var></dt>
702 Specify
<var>controller_id
</var>, a
16-bit integer, as the connection
703 ID of the OpenFlow controller or controllers to which the
704 ``packet-in'' message should be sent. The default is zero. Zero is
705 also the default connection ID for each controller connection, and a
706 given controller connection will only have a nonzero connection ID if
707 its controller uses the
<code>NXT_SET_CONTROLLER_ID
</code> Open
708 vSwitch extension to OpenFlow.
711 <dt><code>userdata=
</code><var>hh
</var>...
</dt>
713 Supplies the bytes represented as hex digits
<var>hh
</var> as
714 additional data to the controller in the ``packet-in'' message.
715 Pairs of hex digits may be separated by periods for readability.
718 <dt><code>pause
</code></dt>
720 Causes the switch to freeze the packet's trip through Open vSwitch
721 flow tables and serializes that state into the packet-in message as a
722 ``continuation,'' an additional property in the
723 <code>NXT_PACKET_IN2
</code> message. The controller can later send
724 the continuation back to the switch in an
<code>NXT_RESUME
</code>
725 message, which will restart the packet's traversal from the point
726 where it was interrupted. This permits an OpenFlow controller to
727 interpose on a packet midway through processing in Open vSwitch.
732 All versions of OpenFlow and Open vSwitch support
733 <code>controller
</code> action and its
<code>max_len
</code> option.
734 The
<code>userdata
</code> and
<code>pause
</code> options require the
735 Open vSwitch
<code>NXAST_CONTROLLER2
</code> extension action added in
736 Open vSwitch
2.6. In the absence of these options, the
737 <var>reason
</var> (other than
<code>reason=action
</code>) and
738 <var>controller_id
</var> (option than
<code>controller_id=
0</code>)
739 options require the Open vSwitch
<code>NXAST_CONTROLLER
</code>
740 extension action added in Open vSwitch
1.6.
744 <action name=
"ENQUEUE">
745 <h2>The
<code>enqueue
</code> action
</h2>
746 <syntax><code>enqueue(
</code><var>port
</var><code>,
</code><var>queue
</var><code>)
</code></syntax>
747 <syntax><code>enqueue:
</code><var>port
</var><code>:
</code><var>queue
</var></syntax>
750 Enqueues the packet on the specified
<var>queue
</var> within port
755 <var>port
</var> must be an OpenFlow port number or name as described
756 under ``Port Specifications'' above.
<var>port
</var> may be
757 <code>in_port
</code> or
<code>local
</code> but the other standard
758 OpenFlow ports are not allowed.
762 <var>queue
</var> must be a a number between
0 and
4294967294
763 (
0xfffffffe), inclusive. The number of actually supported queues
764 depends on the switch. Some OpenFlow implementations do not support
765 queuing at all. In Open vSwitch, the supported queues vary depending
766 on the operating system, datapath, and hardware in use. Use the
767 <code>QoS
</code> and
<code>Queue
</code> tables in the Open vSwitch
768 database to configure queuing on individual OpenFlow ports (see
769 <code>ovs-vswitchd.conf.db
</code>(
5) for more information).
774 Only OpenFlow
1.0 supports
<code>enqueue
</code>. OpenFlow
1.1 added
775 the
<code>set_queue
</code> action to use in its place along with
780 Open vSwitch translates
<code>enqueue
</code> to a sequence of three
781 actions in OpenFlow
1.1 or later:
<code>set_queue:
<var>queue
</var>,
782 output:
<var>port
</var>, pop_queue
</code>. This is equivalent in
783 behavior as long as the flow table does not otherwise use
784 <code>set_queue
</code>, but it relies on the
<code>pop_queue
</code>
785 Open vSwitch extension action.
790 <action name=
"BUNDLE,BUNDLE_LOAD">
791 <h2>The
<code>bundle
</code> and
<code>bundle_load
</code> actions
</h2>
792 <syntax><code>bundle(
</code><var>fields
</var><code>,
</code><var>basis
</var><code>,
</code><var>algorithm
</var><code>, ofport, slaves:
</code><var>port
</var>...
<code>)
</code></syntax>
793 <syntax><code>bundle_load(
</code><var>fields
</var><code>,
</code><var>basis
</var><code>,
</code><var>algorithm
</var><code>, ofport,
</code><var>dst
</var><code>, slaves:
</code><var>port
</var>...
<code>)
</code></syntax>
796 These actions choose a port (``slave'') from a comma-separated OpenFlow
797 <var>port
</var> list. After selecting the port,
<code>bundle
</code>
798 outputs to it, whereas
<code>bundle_load
</code> writes its port number
799 to
<var>dst
</var>, which must be a
16-bit or wider field or subfield in
800 the syntax described under ``Field Specifications'' above.
804 These actions hash a set of
<var>fields
</var> using
<var>basis
</var> as
805 a universal hash parameter, then apply the bundle link selection
806 <var>algorithm
</var> to choose a
<var>port
</var>.
810 <var>fields
</var> must be one of the following. For the options with
811 ``symmetric'' in the name, reversing source and destination addresses
812 yields the same hash:
816 <dt><code>eth_src
</code></dt>
818 Ethernet source address.
821 <dt><code>nw_src
</code></dt>
823 IPv4 or IPv6 source address.
826 <dt><code>nw_dst
</code></dt>
828 IPv4 or IPv6 destination address.
831 <dt><code>symmetric_l4
</code></dt>
833 Ethernet source and destination, Ethernet type, VLAN ID or IDs (if
834 any), IPv4 or IPv6 source and destination, IP protocol, TCP or SCTP
835 (but not UDP) source and destination.
838 <dt><code>symmetric_l3l4
</code></dt>
840 IPv4 or IPv6 source and destination, IP protocol, TCP or SCTP (but
841 not UDP) source and destination.
844 <dt><code>symmetric_l3l4+udp
</code></dt>
846 Like
<code>symmetric_l3l4
</code> but include UDP ports.
851 <var>algorithm
</var> must be one of the following:
855 <dt><code>active_backup
</code></dt>
857 Chooses the first live port listed in
<var>slaves
</var>.
860 <dt><code>hrw
</code> (Highest Random Weight)
</dt>
863 Computes the following, considering only the live ports in
868 for
<var>i
</var> in [
1,
<var>n_slaves
</var>]:
869 <var>weights
</var>[
<var>i
</var>] = hash(
<var>flow
</var>,
<var>i
</var>)
870 <var>slave
</var> = {
<var>i
</var> such that
<var>weights
</var>[
<var>i
</var>]
>=
<var>weights
</var>[
<var>j
</var>] for all
<var>j
</var> !=
<var>i
</var> }
874 This algorithm is specified by RFC
2992.
880 The algorithms take port liveness into account when selecting slaves.
881 The definition of whether a port is live is subject to change. It
882 currently takes into account carrier status and link monitoring
883 protocols such as BFD and CFM. If none of the slaves is live,
884 <code>bundle
</code> does not output the packet and
885 <code>bundle_load
</code> stores
<code>OFPP_NONE
</code> (
65535) in the
890 Example:
<code>bundle(eth_src,
0,hrw,ofport,slaves:
4,
8)
</code> uses an
891 Ethernet source hash with basis
0, to select between OpenFlow ports
4
892 and
8 using the Highest Random Weight algorithm.
896 Open vSwitch
1.2 introduced the
<code>bundle
</code> and
897 <code>bundle_load
</code> OpenFlow extension actions.
901 <action name=
"GROUP">
902 <h2>The
<code>group
</code> action
</h2>
903 <syntax><code>group:
</code><var>group
</var></syntax>
905 Outputs the packet to the OpenFlow group
<var>group
</var>, which must
906 be a number in the range
0 to
4294967040 (
0xffffff00). The group must
907 exist or Open vSwitch will refuse to add the flow. When a group is
908 deleted, Open vSwitch also deletes all of the flows that output to it.
912 Groups contain action sets, whose semantics are described above in the
913 section ``Action Sets''. The semantics of action sets can be
914 surprising to users who expect action list semantics, since action sets
915 reorder and sometimes ignore actions.
919 A
<code>group
</code> action usually executes the action set or sets in
920 one or more group buckets. Open vSwitch saves the packet and metadata
921 before it executes each bucket, and then restores it afterward. Thus,
922 when a group executes more than one bucket, this means that each bucket
923 executes on the same packet and metadata. Moreover, regardless of the
924 number of buckets executed, the packet and metadata are the same before
925 and after executing the group.
929 Sometimes saving and restoring the packet and metadata can be
930 undesirable. In these situations, workarounds are possible. For
931 example, consider a pipeline design in which a
<code>select
</code>
932 group bucket is to communicate to a later stage of processing a value
933 based on which bucket was selected. An obvious design would be for the
934 bucket to communicate the value via
<code>set_field
</code> on a
935 register. This does not work because registers are part of the
936 metadata that
<code>group
</code> saves and restores. The following
937 alternative bucket designs do work:
942 Recursively invoke the rest of the pipeline with
943 <code>resubmit
</code>.
948 Use
<code>resubmit
</code> into a table that uses
<code>push
</code>
949 to put the value on the stack for the caller to
<code>pop
</code>
950 off. This works because
<code>group
</code> preserves only packet
951 data and metadata, not the stack.
955 (This design requires indirection through
<code>resubmit
</code>
956 because actions sets may not contain
<code>push
</code> or
957 <code>pop
</code> actions.)
963 An
<code>exit
</code> action within a group bucket terminates only
964 execution of that bucket, not other buckets or the overall pipeline.
968 OpenFlow
1.1 introduced
<code>group
</code>. Open vSwitch
2.6 and later
969 also supports
<code>group
</code> as an extension to OpenFlow
1.0.
975 <group title=
"Encapsulation and Decapsulation Actions">
976 <action name=
"STRIP_VLAN">
977 <h2>The
<code>strip_vlan
</code> and
<code>pop
</code> actions
</h2>
978 <syntax><code>strip_vlan
</code></syntax>
979 <syntax><code>pop_vlan
</code></syntax>
982 Removes the outermost VLAN tag, if any, from the packet.
986 The two names for this action are synonyms with no semantic difference.
987 The OpenFlow
1.0 specification uses the name
<code>strip_vlan
</code>
988 and later versions use
<code>pop_vlan
</code>, but OVS accepts either
989 name regardless of version.
993 In OpenFlow
1.1 and later, consistency rules allow
994 <code>strip_vlan
</code> only in a flow that matches only packets with a
995 VLAN tag (or following an action that pushes a VLAN tag, such as
996 <code>push_vlan
</code>). See ``Inconsistencies'', above, for more
1001 All versions of OpenFlow and Open vSwitch support this action.
1005 <action name=
"PUSH_VLAN">
1006 <h2>The
<code>push_vlan
</code> action
</h2>
1007 <syntax><code>push_vlan:
</code><var>ethertype
</var></syntax>
1010 Pushes a new outermost VLAN onto the packet. Uses TPID
1011 <var>ethertype
</var>, which must be
<code>0x8100</code> for an
802.1Q
1012 C-tag or
<code>0x88a8</code> for a
802.1ad S-tag.
1016 OpenFlow
1.1 and later supports this action. Open vSwitch
2.8 added
1017 support for multiple VLAN tags (with a limit of
2) and
802.1ad S-tags.
1021 <action name=
"PUSH_MPLS">
1022 <h2>The
<code>push_mpls
</code> action
</h2>
1023 <syntax><code>push_mpls:
<var>ethertype
</var></code></syntax>
1026 Pushes a new outermost MPLS label stack entry (LSE) onto the packet and
1027 changes the packet's Ethertype to
<var>ethertype
</var>, which must be
1028 either
<code>B0x8847
</code> or
<code>0x8848</code>.
1032 If the packet did not already contain any MPLS labels, initializes the
1039 2, if the packet contains IPv6,
0 otherwise.
1043 The low
3 bits of the packet's DSCP value, or
0 if the packet is not
1048 Copied from the IP TTL, or
64 if the packet is not IP.
1053 If the packet did already contain an MPLS label, initializes the new
1054 outermost label as a copy of the existing outermost label.
1058 OVS currently supports at most
3 MPLS labels.
1062 This action applies only to Ethernet packets.
1066 Open vSwitch
1.11 introduced support for MPLS. OpenFlow
1.1 and later
1067 support
<code>push_mpls
</code>. Open vSwitch implements
1068 <code>push_mpls
</code> as an extension to OpenFlow
1.0.
1072 <action name=
"POP_MPLS">
1073 <h2>The
<code>pop_mpls
</code> action
</h2>
1074 <syntax><code>pop_mpls:
<var>ethertype
</var></code></syntax>
1077 Strips the outermost MPLS label stack entry and changes the packet's
1078 Ethertype to
<var>ethertype
</var>.
1082 This action applies only to Ethernet packets with at least one MPLS
1083 label. If there is more than one MPLS label, then
<var>ethertype
</var>
1084 should be an MPLS Ethertype (
<code>B0x8847
</code> or
1085 <code>0x8848</code>).
1089 Open vSwitch
1.11 introduced support for MPLS. OpenFlow
1.1 and later
1090 support
<code>pop_mpls
</code>. Open vSwitch implements
1091 <code>pop_mpls
</code> as an extension to OpenFlow
1.0.
1095 <action name=
"ENCAP">
1096 <h2>The
<code>encap
</code> action
</h2>
1097 <syntax><code>encap(nsh(
</code>[
<code>md_type=
<var>md_type
</var></code>]
<code>,
</code>[
<code>tlv(
<var>class
</var>,
<var>type
</var>,
<var>value
</var>)
</code>]...
<code>))
</code></syntax>
1098 <syntax><code>encap(ethernet)
</code></syntax>
1101 The
<code>encap
</code> action encapsulates a packet with a specified
1102 header. It has variants for different kinds of encapsulation.
1106 The
<code>encap(nsh(
</code>...
<code>))
</code> variant encapsulates an
1107 Ethernet frame with NSH. The
<var>md_type
</var> may be
<code>1</code>
1108 or
<code>2</code> for metadata type
1 or
2, defaulting to
1. For
1109 metadata type
2, TLVs may be specified with
<var>class
</var> as a
1110 16-bit hexadecimal integer beginning with
<code>0x
</code>,
1111 <var>type
</var> as an
8-bit decimal integer, and
<var>value
</var> a
1112 sequence of pairs of hex digits beginning with
<code>0x
</code>. For
1117 <dt><code>encap(nsh(md_type=
1))
</code></dt>
1119 Encapsulates the packet with an NSH header with metadata type
1.
1122 <dt><code>encap(nsh(md_type=
2,tlv(
0x1000,
10,
0x12345678)))
</code></dt>
1124 Encapsulates the packet with an NSH header, NSH metadata type
2, and
1125 an NSH TLV with class
0x1000, type
10, and the
4-byte value
1131 The
<code>encap(ethernet)
</code> variant encapsulate a bare L3 packet
1132 in an Ethernet frame. The Ethernet type is initialized to the L3
1133 packet's type, e.g.
0x0800 if the L3 packet is IPv4. The Ethernet
1134 source and destination are initially zeroed.
1138 This action is an Open vSwitch extension to OpenFlow
1.3 and later,
1139 introduced in Open vSwitch
2.8.
1143 <action name=
"DECAP">
1144 <h2>The
<code>decap
</code> action
</h2>
1145 <syntax><code>decap
</code></syntax>
1148 Removes an outermost encapsulation from the packet:
1153 If the packet is an Ethernet packet, removes the Ethernet header,
1154 which changes the packet into a bare L3 packet. If the packet has
1155 VLAN tags, raises an unsupported packet type error (see ``Error
1160 Otherwise, if the packet is an NSH packet, removes the NSH header,
1161 revealing the inner packet. Open vSwitch supports Ethernet, IPv4,
1162 IPv6, and NSH inner packet types. Other types raise unsupported
1167 Otherwise, raises an unsupported packet type error.
1172 This action is an Open vSwitch extension to OpenFlow
1.3 and later,
1173 introduced in Open vSwitch
2.8.
1178 <group title=
"Field Modification Actions">
1180 These actions modify packet data and metadata fields.
1183 <action name=
"SET_FIELD">
1184 <h2>The
<code>set_field
</code> and
<code>load
</code> actions
</h2>
1185 <syntax><code>set_field:
</code><var>value
</var>[
<code>/
</code><var>mask
</var>]
<code>-
></code><var>dst
</var></syntax>
1186 <syntax><code>load:
</code><var>value
</var><code>-
></code><var>dst
</var><code></code></syntax>
1189 These actions loads a literal value into a field or part of a field.
1190 The
<code>set_field
</code> action takes
<var>value
</var> in the
1191 customary syntax for field
<var>dst
</var>,
1192 e.g.
<code>00:
11:
22:
33:
44:
55</code> for an Ethernet address, and
1193 <var>dst
</var> as the field's name. The optional
<var>mask
</var>
1194 allows part of a field to be set.
1198 The
<code>load
</code> action takes
<var>value
</var> as an integer value
1199 (in decimal or prefixed by
<code>0x
</code> for hexadecimal) and
1200 <var>dst
</var> as a field or subfield in the syntax described under
1201 ``Field Specifications'' above.
1205 The following all set the Ethernet source address to
00:
11:
22:
33:
44:
55:
1209 <li><code>set_field:
00:
11:
22:
33:
44:
55-
>eth_src
</code></li>
1210 <li><code>load:
0x001122334455-
>eth_src
</code></li>
1211 <li><code>load:
0x001122334455-
>OXM_OF_ETH_SRC[]
</code></li>
1215 The following all set the multicast bit in the Ethernet destination
1220 <li><code>set_field:
01:
00:
00:
00:
00:
00/
01:
00:
00:
00:
00:
00-
>eth_dst
</code></li>
1221 <li><code>load:
1-
>eth_dst[
40]
</code></li>
1225 Open vSwitch prohibits a
<code>set_field
</code> or
<code>load
</code>
1226 action whose
<var>dst
</var> is not guaranteed to be part of the packet;
1227 for example,
<code>set_field
</code> of
<code>nw_dst
</code> is only
1228 allowed in a flow that matches on Ethernet type
0x800. In some cases,
1229 such as in an action set, Open vSwitch can't statically check that
1230 <var>dst
</var> is part of the packet, and in that case if it is not
1231 then Open vSwitch treats the action as a no-op.
1235 Open vSwitch
1.1 introduced
<code>NXAST_REG_LOAD
</code> as a extension
1236 to OpenFlow
1.0 and used
<code>load
</code> to express it. Later,
1237 OpenFlow
1.2 introduced a standard
<code>OFPAT_SET_FIELD
</code> action
1238 that was restricted to loading entire fields, so Open vSwitch added the
1239 form
<code>set_field
</code> with this restriction. OpenFlow
1.5
1240 extended
<code>OFPAT_SET_FIELD
</code> to the point that it became a
1241 superset of
<code>NXAST_REG_LOAD
</code>. Open vSwitch translates
1242 either syntax as necessary for the OpenFlow version in use: in OpenFlow
1243 1.0 and
1.1,
<code>NXAST_REG_LOAD
</code>; in OpenFlow
1.2,
1.3, and
1244 1.4,
<code>NXAST_REG_LOAD
</code> for
<code>load
</code> or for loading a
1245 subfield,
<code>OFPAT_SET_FIELD
</code> otherwise; and OpenFlow
1.5 and
1246 later,
<code>OFPAT_SET_FIELD
</code>.
1250 <action name=
"REG_MOVE">
1251 <h2>The
<code>move
</code> action
</h2>
1252 <syntax><code>move:
<var>src
</var>-
><var>dst
</var></code></syntax>
1255 Copies the named bits from field or subfield
<var>src
</var> to field or
1256 subfield
<var>dst
</var>.
<var>src
</var> and
<var>dst
</var> should
1257 fields or subfields in the syntax described under ``Field
1258 Specifications'' above. The two fields or subfields must have the same
1268 <code>move:reg0[
0.
.5]-
>reg1[
26.
.31]
</code> copies the six bits
1269 numbered
0 through
5 in register
0 into bits
26 through
31 of
1273 <code>move:reg0[
0.
.15]-
>vlan_tci
</code> copies the least
1274 significant
16 bits of register
0 into the VLAN TCI field.
1279 In OpenFlow
1.0 through
1.4,
<code>move
</code> ordinarily uses an Open
1280 vSwitch extension to OpenFlow. In OpenFlow
1.5,
<code>move
</code> uses
1281 the OpenFlow
1.5 standard
<code>OFPAT_COPY_FIELD
</code> action. The
1282 ONF has also made
<code>OFPAT_COPY_FIELD
</code> available as an
1283 extension to OpenFlow
1.3. Open vSwitch
2.4 and later understands this
1284 extension and uses it if a controller uses it, but for backward
1285 compatibility with older versions of Open vSwitch,
1286 <code>ovs-ofctl
</code> does not use it.
1290 <action name=
"SET_ETH_SRC, SET_ETH_DST">
1291 <h2>The
<code>mod_dl_src
</code> and
<code>mod_dl_dst
</code> actions
</h2>
1292 <syntax><code>mod_dl_src:
</code><var>mac
</var></syntax>
1293 <syntax><code>mod_dl_dst:
</code><var>mac
</var></syntax>
1296 Sets the Ethernet source or destination address, respectively, to
1297 <var>mac
</var>, which should be expressed in the form
1298 <code><var>xx
</var>:
<var>xx
</var>:
<var>xx
</var>:
<var>xx
</var>:
<var>xx
</var>:
<var>xx
</var></code>.
1302 For L3-only packets, that is, those that lack an Ethernet header, this
1303 action has no effect.
1307 OpenFlow
1.0 and
1.1 have specialized actions for these purposes.
1308 OpenFlow
1.2 and later do not, so Open vSwitch translates them to
1309 appropriate
<code>OFPAT_SET_FIELD
</code> actions for those versions,
1313 <action name=
"SET_IP_SRC, SET_IP_DST">
1314 <h2>The
<code>mod_nw_src
</code> and
<code>mod_nw_dst
</code> actions
</h2>
1315 <syntax><code>mod_nw_src:
</code><var>ip
</var></syntax>
1316 <syntax><code>mod_nw_dst:
</code><var>ip
</var></syntax>
1319 Sets the IPv4 source or destination address, respectively, to
1320 <var>ip
</var>, which should be expressed in the form
1321 <code><var>w
</var>.
<var>x
</var>.
<var>y
</var>.
<var>z
</var></code>.
1325 In OpenFlow
1.1 and later, consistency rules allow these actions only
1326 in a flow that matches only packets that contain an IPv4 header (or
1327 following an action that adds an IPv4 header,
1328 e.g.
<code>pop_mpls:
0x0800</code>). See ``Inconsistencies'', above,
1329 for more information.
1333 OpenFlow
1.0 and
1.1 have specialized actions for these purposes.
1334 OpenFlow
1.2 and later do not, so Open vSwitch translates them to
1335 appropriate
<code>OFPAT_SET_FIELD
</code> actions for those versions,
1339 <action name=
"SET_IP_DSCP, SET_IP_ECN">
1340 <h2>The
<code>mod_nw_tos
</code> and
<code>mod_nw_ecn
</code> actions
</h2>
1341 <syntax><code>mod_nw_tos:
</code><var>tos
</var></syntax>
1342 <syntax><code>mod_nw_ecn:
</code><var>ecn
</var></syntax>
1345 The
<code>mod_nw_tos
</code> action sets the DSCP bits in the IPv4
1346 ToS/DSCP or IPv6 traffic class field to
<var>tos
</var>, which must be a
1347 multiple of
4 between
0 and
255. This action does not modify the two
1348 least significant bits of the ToS field (the ECN bits).
1352 The
<code>mod_nw_ecn
</code> action sets the ECN bits in the IPv4 ToS or
1353 IPv6 traffic class field to
<code>ecn
</code>, which must be a value
1354 between
0 and
3, inclusive. This action does not modify the six most
1355 significant bits of the field (the DSCP bits).
1359 In OpenFlow
1.1 and later, consistency rules allow these actions only
1360 in a flow that matches only packets that contain an IPv4 or IPv6 header
1361 (or following an action that adds such a header). See
1362 ``Inconsistencies'', above, for more information.
1366 OpenFlow
1.0 has a
<code>mod_nw_tos
</code> action but not
1367 <code>mod_nw_ecn
</code>. Open vSwitch implements the latter in
1368 OpenFlow
1.0 as an extension using
<code>NXAST_REG_LOAD
</code>.
1369 OpenFlow
1.1 has specialized actions for these purposes. OpenFlow
1.2
1370 and later do not, so Open vSwitch translates them to appropriate
1371 <code>OFPAT_SET_FIELD
</code> actions for those versions,
1375 <action name=
"SET_L4_SRC_PORT, SET_L4_DST_PORT">
1376 <h2>The
<code>mod_tp_src
</code> and
<code>mod_tp_dst
</code> actions
</h2>
1377 <syntax><code>mod_tp_src:
</code><var>port
</var></syntax>
1378 <syntax><code>mod_tp_dst:
</code><var>port
</var></syntax>
1381 Sets the TCP or UDP or SCTP source or destination port, respectively,
1382 to
<var>port
</var>. Both IPv4 and IPv6 are supported.
1386 In OpenFlow
1.1 and later, consistency rules allow these actions only
1387 in a flow that matches only packets that contain a TCP or UDP or SCTP
1388 header. See ``Inconsistencies'', above, for more information.
1392 OpenFlow
1.0 and
1.1 have specialized actions for these purposes.
1393 OpenFlow
1.2 and later do not, so Open vSwitch translates them to
1394 appropriate
<code>OFPAT_SET_FIELD
</code> actions for those versions,
1398 <action name=
"DEC_TTL">
1399 <h2>The
<code>dec_ttl
</code> action
</h2>
1400 <syntax><code>dec_ttl
</code></syntax>
1401 <syntax><code>dec_ttl(
<var>id1
</var>,
</code>[
<code><var>id2
</var></code>]...
<code>)
</code></syntax>
1404 Decrement TTL of IPv4 packet or hop limit of IPv6 packet. If the TTL
1405 or hop limit is initially
0 or
1, no decrement occurs, as packets
1406 reaching TTL zero must be rejected. Instead, Open vSwitch sends a
1407 ``packet-in'' message with reason code
<code>OFPR_INVALID_TTL
</code> to
1408 each connected controller that has enabled receiving such messages, and
1409 stops processing the current set of actions. (However, if the current
1410 set of actions was reached through
<code>resubmit
</code>, the remaining
1411 actions in outer levels resume processing.)
1415 As an Open vSwitch extension to OpenFlow, this action supports the
1416 ability to specify a list of controller IDs. Open vSwitch will only
1417 send the message to controllers with the given ID or IDs. Specifying
1418 no list is equivalent to specifying a single controller ID of zero.
1422 Sets the TCP or UDP or SCTP source or destination port, respectively,
1423 to
<var>port
</var>. Both IPv4 and IPv6 are supported.
1427 In OpenFlow
1.1 and later, consistency rules allow these actions only
1428 in a flow that matches only packets that contain an IPv4 or IPv6
1429 header. See ``Inconsistencies'', above, for more information.
1433 All versions of OpenFlow and Open vSwitch support this action.
1437 <action name=
"SET_MPLS_LABEL, SET_MPLS_TC, SET_MPLS_TTL">
1438 <h2>The
<code>set_mpls_label
</code>,
<code>set_mpls_tc
</code>, and
<code>set_mpls_ttl
</code> actions
</h2>
1439 <syntax><code>set_mpls_label:
</code><var>label
</var></syntax>
1440 <syntax><code>set_mpls_tc:
</code><var>tc
</var></syntax>
1441 <syntax><code>set_mpls_ttl:
</code><var>ttl
</var></syntax>
1444 The
<code>set_mpls_label
</code> action sets the label of the packet's
1445 outer MPLS label stack entry.
<var>label
</var> should be a
20-bit
1446 value that is decimal by default; use a
<code>0x
</code> prefix to
1447 specify the value in hexadecimal.
1451 The
<code>set_mpls_tc
</code> action sets the traffic class of the
1452 packet's outer MPLS label stack entry.
<var>tc
</var> should be in the
1453 range
0 to
7, inclusive.
1457 The
<code>set_mpls_ttl
</code> action sets the TTL of the packet's outer
1458 MPLS label stack entry.
<var>ttl
</var> should be in the range
0 to
255
1463 In OpenFlow
1.1 and later, consistency rules allow these actions only
1464 in a flow that matches only packets that contain an MPLS label (or
1465 following an action that adds an MPLS label,
1466 e.g.
<code>push_mpls:
0x8847</code>). See ``Inconsistencies'', above,
1467 for more information.
1471 OpenFlow
1.0 does not support MPLS, but Open vSwitch implements these
1472 actions as extensions. OpenFlow
1.1 has specialized actions for these
1473 purposes. OpenFlow
1.2 and later do not, so Open vSwitch translates
1474 them to appropriate
<code>OFPAT_SET_FIELD
</code> actions for those
1479 <action name=
"DEC_MPLS_TTL, DEC_NSH_TTL">
1480 <h2>The
<code>dec_mpls_ttl
</code> and
<code>dec_nsh_ttl
</code> actions
</h2>
1481 <syntax><code>dec_mpls_ttl
</code></syntax>
1482 <syntax><code>dec_nsh_ttl
</code></syntax>
1485 These actions decrement the TTL of the packet's outer MPLS label stack
1486 entry or its NSH header, respectively. If the TTL is initially
0 or
1,
1487 no decrement occurs. Instead, Open vSwitch sends a ``packet-in''
1488 message with reason code
<code>BOFPR_INVALID_TTL
</code> to OpenFlow
1489 controllers with ID
0, if it has enabled receiving them. Processing
1490 the current set of actions then stops. (However, if the current set of
1491 actions was reached through
<code>resubmit
</code>, remaining actions in
1492 outer levels resume processing.)
1496 In OpenFlow
1.1 and later, consistency rules allow this actions only in
1497 a flow that matches only packets that contain an MPLS label or an NSH
1498 header, respectively. See ``Inconsistencies'', above, for more
1504 Open vSwitch
1.11 introduced support for MPLS. OpenFlow
1.1 and
1505 later support
<code>dec_mpls_ttl
</code>. Open vSwitch implements
1506 <code>dec_mpls_ttl
</code> as an extension to OpenFlow
1.0.
1510 Open vSwitch
2.8 introduced support for NSH, although the NSH draft
1511 changed after release so that only Open vSwitch
2.9 and later conform
1512 to the final protocol specification. The
<code>dec_nsh_ttl
</code>
1513 action and NSH support in general is an Open vSwitch extension not
1514 supported by any version of OpenFlow.
1519 <action name=
"CHECK_PKT_LARGER">
1520 <h2>The
<code>check_pkt_larger
</code> action
</h2>
1522 <code>check_pkt_larger(
<var>pkt_len
</var>)-
><var>dst
</var></code>
1526 Checks if the packet is larger than the specified length in
1527 <var>pkt_len
</var>. If so, stores
1 in
<var>dst
</var>, which should be
1528 a
1-bit field; if not, stores
0.
1532 The packet length to check against the argument
<var>pkt_len
</var>
1533 includes the L2 header and L2 payload of the packet, but not the VLAN
1543 <code>check_pkt_larger(
1500)-
>reg0[
0]
</code>
1547 <code>check_pkt_larger(
8000)-
>reg9[
10]
</code>
1552 This action was added in Open vSwitch
2.11.90.
1556 <action name=
"DELETE_FIELD">
1557 <h2>The
<code>delete_field
</code> action
</h2>
1558 <syntax><code>delete_field:
</code><var>field
</var></syntax>
1561 The
<code>delete_field
</code> action deletes a field in the syntax
1562 described under ``Field Specifications'' above. Currently, only
1563 the tun_metadta fields are supported.
1567 This action was added in Open vSwitch
2.13.90.
1573 <group title=
"Metadata Actions">
1574 <action name=
"SET_TUNNEL">
1575 <h2>The
<code>set_tunnel
</code> action
</h2>
1576 <syntax><code>set_tunnel:
</code><var>id
</var></syntax>
1577 <syntax><code>set_tunnel64:
</code><var>id
</var></syntax>
1580 Many kinds of tunnels support a tunnel ID, e.g. VXLAN and Geneve have a
1581 24-bit VNI, and GRE has an optional
32-bit key. This action sets the
1582 value used for tunnel ID in such tunneled packets, although whether it
1583 is used for a particular tunnel depends on the tunnel's configuration.
1584 See the tunnel ID documentation in
<code>ovs-fields
</code>(
7) for more
1590 These actions are OpenFlow extensions.
<code>set_tunnel
</code> was
1591 introduced in Open vSwitch
1.0.
<code>set_tunnel64
</code>, which is
1592 needed if
<var>id
</var> is wider than
32 bits, was added in Open
1593 vSwitch
1.1. Both actions always set the entire tunnel ID field.
1597 Open vSwitch supports these actions in all versions of OpenFlow, but
1598 in OpenFlow
1.2 and later it translates them to an appropriate
1599 standardized
<code>OFPAT_SET_FIELD
</code> action.
1604 <action name=
"SET_QUEUE, POP_QUEUE">
1605 <h2>The
<code>set_queue
</code> and
<code>pop_queue
</code> actions
</h2>
1606 <syntax><code>set_queue:
</code><var>queue
</var></syntax>
1607 <syntax><code>pop_queue
</code></syntax>
1610 The
<code>set_queue
</code> action sets the queue ID to be used for
1611 subsequent output actions to
<var>queue
</var>, which must be a
32-bit
1612 integer. The range of meaningful values of
<var>queue
</var>, and their
1613 meanings, varies greatly from one OpenFlow implementation to another.
1614 Even within a single implementation, there is no guarantee that all
1615 OpenFlow ports have the same queues configured or that all OpenFlow
1616 ports in an implementation can be configured the same way queue-wise.
1617 For more information, see the documentation for the output queue field
1618 in
<code>ovs-fields
</code>(
7).
1622 The
<code>pop_queue
</code> restores the output queue to the default
1623 that was set when the packet entered the switch (generally
0).
1627 Four billion queues ought to be enough for anyone:
<url
1628 href=
"https://mailman.stanford.edu/pipermail/openflow-spec/2009-August/000394.html"/>
1633 OpenFlow
1.1 introduced the
<code>set_queue
</code> action. Open
1634 vSwitch also supports it as an extension in OpenFlow
1.0.
1638 The
<code>pop_queue
</code> action is an Open vSwitch extension.
1644 <group title=
"Firewalling Actions">
1646 Open vSwitch is often used to implement a firewall. The preferred way to
1647 implement a firewall is ``connection tracking,'' that is, to keep track
1648 of the connection state of individual TCP sessions. The
<code>ct
</code>
1649 action described in this section, added in Open vSwitch
2.5, implements
1650 connection tracking. For new deployments, it is the recommended way to
1651 implement firewalling with Open vSwitch.
1655 Before
<code>ct
</code> was added, Open vSwitch did not have built-in
1656 support for connection tracking. Instead, Open vSwitch supported the
1657 <code>learn
</code> action, which allows a received packet to add a flow
1658 to an OpenFlow flow table. This could be used to implement a primitive
1659 form of connection tracking: packets passing through the firewall in one
1660 direction could create flows that allowed response packets back through
1661 the firewall in the other direction. The additional
1662 <code>fin_timeout
</code> action allowed the learned flows to expire
1663 quickly after TCP session termination.
1667 <h2>The
<code>ct
</code> action
</h2>
1668 <syntax><code>ct(
<var>argument
</var></code>]...
<code>)
</code></syntax>
1669 <syntax><code>ct(commit
</code>[
<code>,
<var>argument
</var></code>]...
<code>)
</code></syntax>
1672 The action has two modes of operation, distinguished by whether
1673 <code>commit
</code> is present. The following arguments may be present
1678 <dt><code>zone=
<var>value
</var></code></dt>
1680 A zone is a
16-bit id that isolates connections into separate
1681 domains, allowing overlapping network addresses in different zones.
1682 If a zone is not provided, then the default is
0. The
1683 <var>value
</var> may be specified either as a
16-bit integer literal
1684 or a field or subfield in the syntax described under ``Field
1685 Specifications'' above.
1690 Without
<code>commit
</code>, this action sends the packet through the
1691 connection tracker. The connection tracker keeps track of the state of
1692 TCP connections for packets passed through it. For each packet through
1693 a connection, it checks that it satisfies TCP invariants and signals
1694 the connection state to later actions using the
<code>ct_state
</code>
1695 metadata field, which is documented in
<code>ovs-fields
</code>(
7).
1699 In this form,
<code>ct
</code> forks the OpenFlow pipeline:
1704 In one fork,
<code>ct
</code> passes the packet to the connection
1705 tracker. Afterward, it reinjects the packet into the OpenFlow
1706 pipeline with the connection tracking fields initialized. The
1707 <code>ct_state
</code> field is initialized with connection state and
1708 <code>ct_zone
</code> to the connection tracking zone specified on the
1709 <code>zone
</code> argument. If the connection is one that is already
1710 tracked,
<code>ct_mark
</code> and
<code>ct_label
</code> to its
1711 existing mark and label, respectively; otherwise they are zeroed. In
1712 addition,
<code>ct_nw_proto
</code>,
<code>ct_nw_src
</code>,
1713 <code>ct_nw_dst
</code>,
<code>ct_ipv6_src
</code>,
1714 <code>ct_ipv6_dst
</code>,
<code>ct_tp_src
</code>, and
1715 <code>ct_tp_dst
</code> are initialized appropriately for the original
1716 direction connection. See the
<code>resubmit
</code> action for a way
1717 to search the flow table with the connection tracking original
1718 direction fields swapped with the packet
5-tuple fields. See
1719 <code>ovs-fields
</code>(
7) for details on the connection tracking
1724 In the other fork, the original instance of the packet continues
1725 independent processing following the
<code>ct
</code> action. The
1726 <code>ct_state
</code> field and other connection tracking metadata
1732 Without
<code>commit
</code>, the
<code>ct
</code> action accepts the
1733 following arguments:
1737 <dt><code>table=
<var>table
</var></code></dt>
1739 Sets the OpenFlow table where the packet is reinjected. The
1740 <var>table
</var> must be a number between
0 and
254 inclusive, or a
1741 table's name. If
<var>table
</var> is not specified, then the packet
1745 <dt><code>nat
</code></dt>
1746 <dt><code>nat(
<var>type
</var>=
<var>addrs
</var></code>[
<code>:
<var>ports
</var></code>][
<code>,
<var>flag
</var></code>]...
<code>)
</code></dt>
1749 Specify address and port translation for the connection being
1750 tracked. The
<var>type
</var> must be
<code>src
</code>, for source
1751 address/port translation (SNAT), or
<code>dst
</code>, for destination
1752 address/port translation (DNAT). Setting up address translation for
1753 a new connection takes effect only if the connection is later
1754 committed with
<code>ct(commit
</code>...
<code>)
</code>.
1758 The
<code>src
</code> and
<code>dst
</code> options take the following
1763 <dt><var>addrs
</var></dt>
1765 The IP address
<var>addr
</var> or range
1766 <code><var>addr1
</var>-
<var>addr2
</var></code> from which the
1767 translated address should be selected. If only one address is
1768 given, then that address will always be selected, otherwise the
1769 address selection can be informed by the optional persistent flag
1770 as described below. Either IPv4 or IPv6 addresses can be provided,
1771 but both addresses must be of the same type, and the datapath
1772 behavior is undefined in case of providing IPv4 address range for
1773 an IPv6 packet, or IPv6 address range for an IPv4 packet. IPv6
1774 addresses must be bracketed with
<code>[
</code> and
<code>]
</code>
1775 if a port range is also given.
1778 <dt><var>ports
</var></dt>
1780 The L4
<var>port
</var> or range
1781 <code><var>port1
</var>-
<var>port2
</var></code> from which the
1782 translated port should be selected. When a port range is
1783 specified, fallback to ephemeral ports does not happen, else,
1784 it will. The port number selection can be informed by the
1785 optional
<code>random
</code> and
<code>hash
</code> flags
1786 described below. The userspace datapath only supports the
1787 <code>hash
</code> behavior.
1792 The optional flags are:
1796 <dt><code>random
</code></dt>
1798 The selection of the port from the given range should be done using
1799 a fresh random number. This flag is mutually exclusive with
1803 <dt><code>hash
</code></dt>
1805 The selection of the port from the given range should be done using
1806 a datapath specific hash of the packet's IP addresses and the
1807 other, non-mapped port number. This flag is mutually exclusive
1808 with
<code>random
</code>.
1811 <dt><code>persistent
</code></dt>
1813 The selection of the IP address from the given range should be done
1814 so that the same mapping can be provided after the system restarts.
1819 If
<code>alg
</code> is specified for the committing
<code>ct
</code>
1820 action that also includes
<code>nat
</code> with a
<code>src
</code> or
1821 <code>dst
</code> attribute, then the datapath tries to set up the
1822 helper to be NAT-aware. This functionality is datapath specific and
1823 may not be supported by all datapaths.
1827 A ``bare''
<code>nat
</code> argument with no options will only
1828 translate the packet being processed in the way the connection has been
1829 set up with an earlier, committed
<code>ct
</code> action. A
1830 <code>nat
</code> action with
<code>src
</code> or
<code>dst
</code>, when
1831 applied to a packet belonging to an established (rather than new)
1832 connection, will behave the same as a bare
<code>nat
</code>.
1836 Open vSwitch
2.6 introduced
<code>nat
</code>. Linux
4.6 was the
1837 earliest upstream kernel that implemented
<code>ct
</code> support for
1844 With
<code>commit
</code>, the connection tracker commits the connection
1845 to the connection tracking module. The
<code>commit
</code> flag should
1846 only be used from the pipeline within the first fork of
<code>ct
</code>
1847 without
<code>commit
</code>. Information about the connection is
1848 stored beyond the lifetime of the packet in the pipeline. Some
1849 <code>ct_state
</code> flags are only available for committed
1854 The following options are available only with
<code>commit
</code>:
1858 <dt><code>force
</code></dt>
1860 A committed connection always has the directionality of the packet
1861 that caused the connection to be committed in the first place. This
1862 is the ``original direction'' of the connection, and the opposite
1863 direction is the ``reply direction''. If a connection is already
1864 committed, but it is in the wrong direction,
<code>force
</code>
1865 effectively terminates the existing connection and starts a new one
1866 in the current direction. This flag has no effect if the original
1867 direction of the connection is already the same as that of the
1871 <dt><code>exec(
<var>action
</var></code>...
<code>)
</code></dt>
1874 Perform each
<var>action
</var> within the context of connection
1875 tracking. Only actions which modify the
<code>ct_mark
</code> or
1876 <code>ct_label
</code> fields are accepted within
<code>exec
</code>
1877 action, and these fields may only be modified with this option. For
1882 <dt><code>set_field:
<var>value
</var>[/
<var>mask
</var>]-
>ct_mark
</code></dt>
1884 Store a
32-bit metadata value with the connection. Subsequent
1885 lookups for packets in this connection will populate
1886 <code>ct_mark
</code> when the packet is sent to the connection
1887 tracker with the table specified.
1890 <dt><code>set_field:
<var>value
</var>[/
<var>mask
</var>]-
>ct_label
</code></dt>
1892 Store a
128-bit metadata value with the connection. Subsequent
1893 lookups for packets in this connection will populate
1894 <code>ct_label
</code> when the packet is sent to the connection
1895 tracker with the table specified.
1900 <dt><code>alg=
<var>alg
</var></code></dt>
1903 Specify application layer gateway
<var>alg
</var> to track specific
1904 connection types. If subsequent related connections are sent
1905 through the
<code>ct
</code> action, then the
<code>rel
</code> flag
1906 in the
<code>ct_state
</code> field will be set. Supported types
1911 <dt><code>ftp
</code></dt>
1913 Look for negotiation of FTP data connections. Specify this
1914 option for FTP control connections to detect related data
1915 connections and populate the
<code>rel
</code> flag for the data
1919 <dt><code>tftp
</code></dt>
1922 Look for negotiation of TFTP data connections. Specify this
1923 option for TFTP control connections to detect related data
1924 connections and populate the
<code>rel
</code> flag for the data
1931 Related connections inherit
<code>ct_mark
</code> from that stored
1932 with the original connection (i.e. the connection created by
1933 <code>ct(alg=
</code>...
<code>)
</code>).
1939 With the Linux datapath, global sysctl options affect
<code>ct
</code>
1940 behavior. In particular, if
1941 <code>net.netfilter.nf_conntrack_helper
</code> is enabled, which it is
1942 by default until Linux
4.7, then application layer gateway helpers may
1943 be executed even if
<code>alg
</code> is not specified. For security
1944 reasons, the netfilter team recommends users disable this option. For
1945 further details, please see
<url
1946 href=
"http://www.netfilter.org/news.html#2012-04-03"/>.
1950 The
<code>ct
</code> action may be used as a primitive to construct
1951 stateful firewalls by selectively committing some traffic, then
1952 matching
<code>ct_state
</code> to allow established connections while
1953 denying new connections. The following flows provide an example of how
1954 to implement a simple firewall that allows new connections from port
1
1955 to port
2, and only allows established connections to send traffic from
1960 table=
0,priority=
1,action=drop
1961 table=
0,priority=
10,arp,action=normal
1962 table=
0,priority=
100,ip,ct_state=-trk,action=ct(table=
1)
1963 table=
1,in_port=
1,ip,ct_state=+trk+new,action=ct(commit),
2
1964 table=
1,in_port=
1,ip,ct_state=+trk+est,action=
2
1965 table=
1,in_port=
2,ip,ct_state=+trk+new,action=drop
1966 table=
1,in_port=
2,ip,ct_state=+trk+est,action=
1
1970 If
<code>ct
</code> is executed on IPv4 (or IPv6) fragments, then the
1971 message is implicitly reassembled before sending to the connection
1972 tracker and refragmented upon output, to the original maximum received
1973 fragment size. Reassembly occurs within the context of the zone,
1974 meaning that IP fragments in different zones are not assembled
1975 together. Pipeline processing for the initial fragments is halted.
1976 When the final fragment is received, the message is assembled and
1977 pipeline processing continues for that flow. Packet ordering is not
1978 guaranteed by IP protocols, so it is not possible to determine which IP
1979 fragment will cause message reassembly (and therefore continue pipeline
1980 processing). As such, it is strongly recommended that multiple flows
1981 should not execute
<code>ct
</code> to reassemble fragments from the
1986 The
<code>ct
</code> action was introduced in Open vSwitch
2.5. Some of
1987 its features were introduced later, noted individually above.
1991 <action name=
"CT_CLEAR">
1992 <h2>The
<code>ct_clear
</code> action
</h2>
1993 <syntax><code>ct_clear
</code></syntax>
1996 Clears connection tracking state from the flow, zeroing
1997 <code>ct_state
</code>,
<code>ct_zone
</code>,
<code>ct_mark
</code>, and
1998 <code>ct_label
</code>.
2002 This action was introduced in Open vSwitch
2.6.90.
2006 <action name=
"LEARN">
2007 <h2>The
<code>learn
</code> action
</h2>
2008 <syntax><code>learn(
<var>argument
</var></code>...
<code>)
</code></syntax>
2011 The
<code>learn
</code> action adds or modifies a flow in an OpenFlow
2012 table, similar to
<code>ovs-ofctl --strict mod-flows
</code>. The
2013 arguments specify the match fields, actions, and other properties of
2014 the flow to be added or modified.
2018 Match fields for the new flow are specified as follows. At least one
2019 match field should ordinarily be specified:
2023 <dt><code><var>field
</var>=
<var>value
</var></code></dt>
2026 Specifies that
<var>field
</var>, in the new flow, must match the
2027 literal
<var>value
</var>, e.g.
<code>dl_type=
0x800</code>.
2028 Shorthand match syntax, such as
<code>ip
</code> in place of
2029 <code>dl_type=
0x800</code>, is not supported.
2033 <dt><code><var>field
</var>=
<var>src
</var></code></dt>
2036 Specifies that
<var>field
</var> in the new flow must match
2037 <var>src
</var> taken from the packet currently being processed.
2038 For example,
<code>udp_dst=udp_src
</code>, applied to a UDP packet
2039 with source port
53, creates a flow which matches
2040 <code>udp_dst=
53</code>.
<var>field
</var> and
<var>src
</var> must
2041 have the same width.
2045 <dt><code><var>field
</var></code></dt>
2047 Shorthand for the previous form when
<var>field
</var> and
2048 <var>src
</var> are the same. For example,
<code>udp_dst
</code>,
2049 applied to a UDP packet with destination port
53, creates a flow
2050 which matches
<code>udp_dst=
53</code>.
2055 The
<var>field
</var> and
<var>src
</var> arguments above should be
2056 fields or subfields in the syntax described under ``Field
2057 Specifications'' above.
2061 Match field specifications must honor prerequisites for both the flow
2062 with the
<code>learn
</code> and the new flow that it creates. Consider
2063 the following complete flow, in the syntax accepted by
2064 <code>ovs-ofctl
</code>. If the flow's match on
<code>udp
</code> were
2065 omitted, then the flow would not satisfy the prerequisites for the
2066 <code>learn
</code> action's use of
<code>udp_src
</code>. If
2067 <code>dl_type=
0x800</code> or
<code>nw_proto
</code> were omitted from
2068 <code>learn
</code>, then the new flow would not satisfy the
2069 prerequisite for its match on
<code>udp_dst
</code>. For more
2070 information on prerequisites, please refer to
2071 <code>ovs-fields
</code>(
7):
2075 udp, actions=learn(dl_type=
0x800, nw_proto=
17, udp_dst=udp_src)
2079 Actions for the new flow are specified as follows. At least one action
2080 should ordinarily be specified:
2084 <dt><code>load:
<var>value
</var>-
><var>dst
</var></code></dt>
2086 Adds a
<code>load
</code> action to the new flow that loads the
2087 literal
<var>value
</var> into
<var>dst
</var>. The syntax is the same
2088 as the
<code>load
</code> action explained in the ``Header
2089 Modification'' section.
2092 <dt><code>load:
<var>src
</var>-
><var>dst
</var></code></dt>
2094 Adds a
<code>load
</code> action to the new flow that loads
2095 <var>src
</var>, a field or subfield from the packet being processed,
2096 into
<var>dst
</var>.
2099 <dt><code>output:
<var>field
</var></code></dt>
2101 Adds an
<code>output
</code> action to the new flow's actions that
2102 outputs to the OpenFlow port taken from
<var>field
</var>, which must
2103 be a field as described above.
2106 <dt><code>fin_idle_timeout=
<var>seconds
</var></code></dt>
2107 <dt><code>fin_hard_timeout=
<var>seconds
</var></code></dt>
2109 Adds a
<code>fin_timeout
</code> action with the specified arguments
2110 to the new flow. This feature was added in Open vSwitch
1.5.90.
2114 The following additional arguments are optional:
2117 <dt><code>idle_timeout=
<var>seconds
</var></code></dt>
2118 <dt><code>hard_timeout=
<var>seconds
</var></code></dt>
2119 <dt><code>priority=
<var>value
</var></code></dt>
2120 <dt><code>cookie=
<var>value
</var></code></dt>
2121 <dt><code>send_flow_rem
</code></dt>
2123 These arguments have the same meaning as in the usual flow syntax
2124 documented in
<code>ovs-ofctl
</code>(
8).
2127 <dt><code>table=
<var>table
</var></code></dt>
2129 The table in which the new flow should be inserted. Specify a
2130 decimal number between
0 and
254 inclusive or the name of a table.
2131 The default, if table is unspecified, is table
1 (not
0).
2134 <dt><code>delete_learned
</code></dt>
2137 When this flag is specified, deleting the flow that contains the
2138 <code>learn
</code> action will also delete the flows created by
2139 <code>learn
</code>. Specifically, when the last
<code>learn
</code>
2140 action with this flag and particular
<code>table
</code> and
2141 <code>cookie
</code> values is removed, the switch deletes all of
2142 the flows in the specified table with the specified cookie.
2146 This flag was added in Open vSwitch
2.4.
2150 <dt><code>limit=
<var>number
</var></code></dt>
2153 If the number of flows in the new flow's table with the same cookie
2154 exceeds
<code>number
</code>, the action will not add a new flow.
2155 By default, or with
<code>limit=
0</code>, there is no limit.
2159 This flag was added in Open vSwitch
2.8.
2163 <dt><code>result_dst=
<var>field
</var>[
<var>bit
</var>]
</code></dt>
2166 If learn fails (because the number of flows exceeds
2167 <code>limit
</code>), the action sets
2168 <code><var>field
</var>[
<var>bit
</var>]
</code> to
0, otherwise it
2169 will be set to
1.
<code>field[bit]
</code> must be a single bit.
2173 This flag was added in Open vSwitch
2.8.
2179 By itself, the
<code>learn
</code> action can only put two kinds of
2180 actions into the flows that it creates:
<code>load
</code> and
2181 <code>output
</code> actions. If
<code>learn
</code> is used in
2182 isolation, these are severe limits.
2186 However,
<code>learn
</code> is not meant to be used in isolation. It
2187 is a primitive meant to be used together with other Open vSwitch
2188 features to accomplish a task. Its existing features are enough to
2189 accomplish most tasks.
2193 Here is an outline of a typical pipeline structure that allows for
2194 versatile behavior using
<code>learn
</code>:
2199 Flows in table
<var>A
</var> contain a
<code>learn
</code> action, that
2200 populates flows in table
<var>L
</var>, that use a
<code>load
</code>
2201 action to populate register
<var>R
</var> with information about what
2206 Flows in table
<var>B
</var> contain two sequential resubmit actions:
2207 one to table
<var>L
</var> and another one to table
<var>B
</var>+
1.
2211 Flows in table
<var>B
</var>+
1 match on register
<var>R
</var> and act
2212 differently depending on what the flows in table
<var>L
</var> loaded
2218 This approach can be used to implement many
<code>learn
</code>-based
2219 features. For example:
2224 Resubmit to a table selected based on learned information, e.g. see
2225 <url href=
"https://mail.openvswitch.org/pipermail/ovs-discuss/2016-June/021694.html"/>.
2229 MAC learning in the middle of a pipeline, as described in the ``Open
2230 vSwitch Advanced Features Tutorial'' in the OVS documentation.
2234 TCP state based firewalling, by learning outgoing connections based
2235 on SYN packets and matching them up with incoming packets. (This is
2236 usually better implemented using the
<code>ct
</code> action.)
2240 At least some of the features described in T. A. Hoff, ``Extending
2241 Open vSwitch to Facilitate Creation of Stateful SDN Applications''.
2246 The
<code>learn
</code> action is an Open vSwitch extension to OpenFlow
2247 added in Open vSwitch
1.3. Some features of
<code>learn
</code> were
2248 added in later versions, as noted individually above.
2252 <action name=
"FIN_TIMEOUT">
2253 <h2>The
<code>fin_timeout
</code> action
</h2>
2254 <syntax><code>fin_timeout(
<var>key
</var>=
<var>value
</var></code>...
<code>)
</code></syntax>
2257 This action changes the idle timeout or hard timeout, or both, of the
2258 OpenFlow flow that contains it, when the flow matches a TCP packet with
2259 the FIN or RST flag. When such a packet is observed, the action
2260 reduces the rule's timeouts to those specified on the action. If the
2261 rule's existing timeout is already shorter than the one that the action
2262 specifies, then that timeout is unaffected.
2266 The timeouts are specified as key-value pairs:
2270 <dt><code>idle_timeout=
</code><var>seconds
</var></dt>
2272 Causes the flow to expire after the given number of seconds of
2276 <dt><code>hard_timeout=
</code><var>seconds
</var></dt>
2278 Causes the flow to expire after the given number of
2279 <var>seconds
</var>, regardless of activity. (
<var>seconds
</var>
2280 specifies time since the flow's creation, not since the receipt of
2286 This action is normally added to a learned flow by the
2287 <code>learn
</code> action. It is unlikely to be useful otherwise.
2291 This Open vSwitch extension action was added in Open vSwitch
1.5.90.
2296 <group title=
"Programming and Control Flow Actions">
2297 <action name=
"RESUBMIT">
2298 <h2>The
<code>resubmit
</code> action
</h2>
2299 <syntax><code>resubmit:
<var>port
</var></code></syntax>
2300 <syntax><code>resubmit(
</code>[
<code><var>port
</var></code>]
<code>,
</code>[
<code><var>table
</var></code>][
<code>,ct
</code>]
<code>)
</code></syntax>
2303 Searches an OpenFlow flow table for a matching flow and executes the
2304 actions found, if any, before continuing to the following action in the
2305 current flow entry. Arguments can customize the search:
2310 If
<var>port
</var> is given as an OpenFlow port number or name, then
2311 it specifies a value to use for the input port metadata field as part
2312 of the search, in place of the input port currently in the flow.
2313 Specifying
<code>in_port
</code> as
<var>port
</var> is equivalent to
2318 If
<var>table
</var> is given as an integer between
0 and
254 or a
2319 table name, it specifies the OpenFlow table to search. If it is not
2320 specified, the table from the current flow is used.
2325 If
<code>ct
</code> is specified, then the search is done with
2326 packet
5-tuple fields swapped with the corresponding conntrack
2327 original direction tuple fields. See the documentation for
2328 <code>ct
</code> above, for more information about connection
2329 tracking, or
<code>ovs-fields
</code>(
7) for details about the
2330 connection tracking fields.
2334 This flag requires a valid connection tracking state as a match
2335 prerequisite in the flow where this action is placed. Examples of
2336 valid connection tracking state matches include
2337 <code>ct_state=+new
</code>,
<code>ct_state=+est
</code>,
2338 <code>ct_state=+rel
</code>, and
<code>ct_state=+trk-inv
</code>.
2344 The changes, if any, to the input port and connection tracking fields
2345 are just for searching the flow table. The changes are not visible to
2346 actions or to later flow table lookups.
2350 The most common use of
<code>resubmit
</code> is to visit another flow
2351 table without
<var>port
</var> or
<code>ct
</code>, like this:
2352 <code>resubmit(,
<var>table
</var>)
</code>.
2356 Recursive
<code>resubmit
</code> actions are permitted.
2361 The
<code>resubmit
</code> action is an Open vSwitch extension.
2362 However, the
<code>goto_table
</code> instruction in OpenFlow
1.1 and
2363 later can be viewed as a kind of restricted
<code>resubmit
</code>.
2367 Open vSwitch
1.2.90 added
<var>table
</var>. Open vSwitch
2.7 added
2372 Open vSwitch imposes a limit on
<code>resubmit
</code> recursion that
2373 varies among version:
2378 Open vSwitch
1.0.1 and earlier did not support recursion.
2382 Open vSwitch
1.0.2 and
1.0.3 limited recursion to
8 levels.
2386 Open vSwitch
1.1 and
1.2 limited recursion to
16 levels.
2390 Open vSwitch
1.2 through
1.8 limited recursion to
32 levels.
2394 Open vSwitch
1.9 through
2.0 limited recursion to
64 levels.
2398 Open vSwitch
2.1 through
2.5 limited recursion to
64 levels and
2399 impose a total limit of
4,
096 resubmits per flow translation
2400 (earlier versions did not impose any total limit).
2404 Open vSwitch
2.6 and later imposes the same limits as
2.5, with one
2405 exception: resubmit from table
<var>x
</var> to any table
2406 <var>y
</var> > <var>x
</var> does not count against the recursion
2413 <action name=
"CLONE">
2414 <h2>The
<code>clone
</code> action
</h2>
2415 <syntax><code>clone(
<var>action
</var>...)
</code></syntax>
2418 Executes each nested
<var>action
</var>, saving much of the packet and
2419 pipeline state beforehand and then restoring it afterward. The state
2420 that is saved and restored includes all flow data and metadata
2421 (including, for example,
<code>in_port
</code> and
2422 <code>ct_state
</code>), the stack accessed by
<code>push
</code> and
2423 <code>pop
</code> actions, and the OpenFlow action set.
2427 This action was added in Open vSwitch
2.6.90.
2431 <action name=
"STACK_PUSH, STACK_POP">
2432 <h2>The
<code>push
</code> and
<code>pop
</code> actions
</h2>
2433 <syntax><code>push:
<var>src
</var></code></syntax>
2434 <syntax><code>pop:
<var>dst
</var></code></syntax>
2436 The
<code>push
</code> action pushes
<var>src
</var> on a general-purpose
2437 stack. The
<code>pop
</code> action pops an entry off the stack into
2438 <var>dst
</var>.
<var>src
</var> and
<var>dst
</var> should be fields or
2439 subfields in the syntax described under ``Field Specifications'' above.
2443 Controllers can use the stack for saving and restoring data or metadata
2444 around
<code>resubmit
</code> actions, for swapping or rearranging data
2445 and metadata, or for other purposes. Any data or metadata field, or
2446 part of one, may be pushed, and any modifiable field or subfield may be
2451 The number of bits pushed in a stack entry do not have to match the
2452 number of bits later popped from that entry. If more bits are popped
2453 from an entry than were pushed, then the entry is conceptually
2454 left-padded with
0-bits as needed. If fewer bits are popped than
2455 pushed, then bits are conceptually trimmed from the left side of the
2460 The stack's size is limited. The limit is intended to be high enough
2461 that ``normal'' use will not pose problems. Stack overflow or
2462 underflow is an error that stops action execution (see ``Stack too
2463 deep'' under ``Error Handling'', above).
2472 <code>push:reg2[
0.
.5]
</code> or
<code>push:NXM_NX_REG2[
0.
.5]
</code>
2473 pushes on the stack the
6 bits in register
2 bits
0 through
5.
2477 <code>pop:reg2[
0.
.5]
</code> or
<code>pop:NXM_NX_REG2[
0.
.5]
</code>
2478 pops the value from top of the stack and copy bits
0 through
5 of
2479 that value into bits
0 through
5 of register
2.
2484 Open vSwitch
1.2 introduced
<code>push
</code> and
<code>pop
</code> as
2485 OpenFlow extension actions.
2489 <action name=
"EXIT">
2490 <h2>The
<code>exit
</code> action
</h2>
2491 <syntax><code>exit
</code></syntax>
2494 This action causes Open vSwitch to immediately halt execution of
2495 further actions. Actions which have already been executed are
2496 unaffected. Any further actions, including those which may be in other
2497 tables, or different levels of the
<code>resubmit
</code> call stack,
2498 are ignored. However, an
<code>exit
</code> action within a group
2499 bucket terminates only execution of that bucket, not other buckets or
2500 the overall pipeline. Actions in the action set are still executed
2501 (specify
<code>clear_actions
</code> before
<code>exit
</code> to discard
2506 <action name=
"MULTIPATH">
2507 <h2>The
<code>multipath
</code> action
</h2>
2508 <syntax><code>multipath(
<var>fields
</var>,
<var>basis
</var>,
<var>algorithm
</var>,
<var>n_links
</var>,
<var>arg
</var>,
<var>dst
</var>)
</code></syntax>
2511 Hashes
<var>fields
</var> using
<var>basis
</var> as a universal hash
2512 parameter, then the applies multipath link selection
2513 <var>algorithm
</var> (with parameter
<var>arg
</var>) to choose one of
2514 <var>n_links
</var> output links numbered
0 through
<var>n_links
</var>
2515 minus
1, and stores the link into
<var>dst
</var>, which must be a field
2516 or subfield in the syntax described under ``Field Specifications''
2521 The
<code>bundle
</code> or
<code>bundle_load
</code> actions are usually
2522 easier to use than
<code>multipath
</code>.
2526 <var>fields
</var> must be one of the following:
2530 <dt><code>eth_src
</code></dt>
2532 Hashes Ethernet source address only.
2535 <dt><code>symmetric_l4
</code></dt>
2537 Hashes Ethernet source, destination, and type, VLAN ID, IPv4/IPv6
2538 source, destination, and protocol, and TCP or SCTP (but not UDP)
2539 ports. The hash is computed so that pairs of corresponding flows in
2540 each direction hash to the same value, in environments where L2 paths
2541 are the same in each direction. UDP ports are not included in the
2542 hash to support protocols such as VXLAN that use asymmetric ports
2546 <dt><code>symmetric_l3l4
</code></dt>
2548 Hashes IPv4/IPv6 source, destination, and protocol, and TCP or SCTP
2549 (but not UDP) ports. Like
<code>symmetric_l4
</code>, this is a
2550 symmetric hash, but by excluding L2 headers it is more effective in
2551 environments with asymmetric L2 paths (e.g. paths involving VRRP IP
2552 addresses on a router). Not an effective hash function for protocols
2553 other than IPv4 and IPv6, which hash to a constant zero.
2556 <dt><code>symmetric_l3l4+udp
</code></dt>
2558 Like
<code>symmetric_l3l4+udp
</code>, but UDP ports are included in
2559 the hash. This is a more effective hash when asymmetric UDP
2560 protocols such as VXLAN are not a consideration.
2563 <dt><code>symmetric_l3
</code></dt>
2565 Hashes network source address and network destination address.
2568 <dt><code>nw_src
</code></dt>
2570 Hashes network source address only.
2573 <dt><code>nw_dst
</code></dt>
2575 Hashes network destination address only.
2580 The
<var>algorithm
</var> used to compute the final result
2581 <var>link
</var> must be one of the following:
2585 <dt><code>modulo_n
</code></dt>
2588 Computes
<var>link
</var> = hash(
<var>flow
</var>) %
<var>n_links
</var>.
2592 This algorithm redistributes all traffic when
<var>n_links
</var>
2593 changes. It has
<i>O(
1)
</i> performance.
2597 Use
65535 for
<var>max_link
</var> to get a raw hash value.
2601 This algorithm is specified by RFC
2992.
2605 <dt><code>hash_threshold
</code></dt>
2608 Computes
<var>link
</var> = hash(
<var>flow
</var>) / (
<code>MAX_HASH
</code> /
<var>n_links
</var>).
2612 Redistributes between one-quarter and one-half of traffic when
2613 n_links changes. It has
<i>O(
1)
</i> performance.
2617 This algorithm is specified by RFC
2992.
2621 <dt><code>hrw
</code> (Highest Random Weight)
</dt>
2624 Computes the following:
2628 for
<var>i
</var> in [
0,
<var>n_links
</var>]:
2629 <var>weights
</var>[
<var>i
</var>] = hash(
<var>flow
</var>,
<var>i
</var>)
2630 <var>link
</var> = {
<var>i
</var> such that
<var>weights
</var>[
<var>i
</var>]
>=
<var>weights
</var>[
<var>j
</var>] for all
<var>j
</var> !=
<var>i
</var> }
2634 Redistributes
1/
<var>n_links
</var> of traffic when
2635 <var>n_links
</var> changes. It has
<i>O(
<var>n_links
</var>)
</i>
2636 performance. If
<var>n_links
</var> is greater than a threshold
2637 (currently
64, but subject to change), Open vSwitch will substitute
2638 another algorithm automatically.
2642 This algorithm is specified by RFC
2992.
2646 <dt><code>iter_hash
</code> (Iterative Hash)
</dt>
2649 Computes the following:
2655 <var>i
</var> =
<var>i
</var> +
1
2656 <var>link
</var> = hash(
<var>flow
</var>,
<var>i
</var>) %
<var>arg
</var>
2657 while
<var>link
</var> > <var>max_link
</var>
2661 Redistributes
1/
<var>n_links
</var> of traffic when
2662 <var>n_links
</var> changes. O(
1) performance when
2663 <var>arg
</var>/
<var>max_link
</var> is bounded by a constant.
2667 Redistributes all traffic when
<var>arg
</var> changes.
2671 <var>arg
</var> must be greater than
<var>max_link
</var> and for
2672 best performance should be no more than approximately
2673 <var>max_link
</var> *
2. If
<var>arg
</var> is outside the
2674 acceptable range, Open vSwitch will automatically substitute the
2675 least power of
2 greater than
<var>max_link
</var>.
2679 This algorithm is specific to Open vSwitch.
2685 Only the
<code>iter_hash
</code> algorithm uses
<var>arg
</var>.
2689 It is an error if
<var>max_link
</var> is greater than or equal to
2690 2**
<var>n_bits
</var>.
2694 This is an OpenFlow extension added in Open vSwitch
1.1.
2699 <group title=
"Other Actions">
2700 <action name=
"CONJUNCTION">
2701 <h2>The
<code>conjunction
</code> action
</h2>
2702 <syntax><code>conjunction(
<var>id
</var>,
<var>k
</var>/
<var>n
</var>)
</code></syntax>
2705 This action allows for sophisticated ``conjunctive match'' flows.
2706 Refer to ``Conjunctive Match Fields'' in
<code>ovs-fields
</code>(
7) for
2711 A flow that has one or more
<code>conjunction
</code> actions may not
2712 have any other actions except for
<code>note
</code> actions.
2716 Open vSwitch
2.4 introduced the
<code>conjunction
</code> action and
2717 <code>conj_id
</code> field. They are Open vSwitch extensions to
2722 <action name=
"NOTE">
2723 <h2>The
<code>note
</code> action
</h2>
2724 <syntax><code>note:
</code>[
<var>hh
</var>]...
</syntax>
2727 This action does nothing at all. OpenFlow controllers may use it to
2728 annotate flows with more data than can fit in a flow cookie.
2732 The action may include any number of bytes represented as hex digits
2733 <var>hh
</var>. Periods may separate pairs of hex digits, for
2734 readability. The
<code>note
</code> action's format doesn't include an
2735 exact length for its payload, so the provided bytes will be padded on
2736 the right by enough bytes with value
0 to make the total number
6 more
2737 than a multiple of
8.
2745 This action is an extension to OpenFlow introduced in Open vSwitch
1.1.
2749 <action name=
"SAMPLE">
2750 <h2>The
<code>sample
</code> action
</h2>
2751 <syntax><code>sample(
<var>argument
</var>...)
</code></syntax>
2754 Samples packets and sends one sample for every sampled packet.
2758 The following
<var>argument
</var> forms are accepted:
2762 <dt><code>probability=
<var>packets
</var></code></dt>
2764 The number of sampled packets out of
65535. Must be greater or equal
2768 <dt><code>collector_set_id=
<var>id
</var></code></dt>
2770 The unsigned
32-bit integer identifier of the set of sample
2771 collectors to send sampled packets to. Defaults to
0.
2774 <dt><code>obs_domain_id=
<var>id
</var></code></dt>
2776 When sending samples to IPFIX collectors, the unsigned
32-bit integer
2777 Observation Domain ID sent in every IPFIX flow record. Defaults to
2781 <dt><code>obs_point_id=
<var>id
</var></code></dt>
2783 When sending samples to IPFIX collectors, the unsigned
32-bit integer
2784 Observation Point ID sent in every IPFIX flow record. Defaults to
0.
2787 <dt><code>sampling_port=
<var>port
</var></code></dt>
2789 Sample packets on
<var>port
</var>, which should be the ingress or
2790 egress port. This option, which was added in Open vSwitch
2.5.90,
2791 allows the IPFIX implementation to export egress tunnel information.
2794 <dt><code>ingress
</code></dt>
2795 <dt><code>egress
</code></dt>
2797 Specifies explicitly that the packet is being sampled on ingress to
2798 or egress from the switch. IPFIX reports sent by Open vSwitch before
2799 version
2.5.90 did not include a direction. From
2.5.90 until
2800 2.6.90, IPFIX reports inferred a direction from
2801 <var>sampling_port
</var>: if it was the packet's output port, then
2802 the direction was reported as egress, otherwise as ingress. Open
2803 vSwitch
2.6.90 introduced these options, which allow the inferred
2804 direction to be overridden. This is particularly useful when the
2805 ingress (or egress) port is not a tunnel.
2810 Refer to
<code>ovs-vswitchd.conf.db
</code>(
5) for more details on
2811 configuring sample collector sets.
2815 This action is an OpenFlow extension added in Open vSwitch
2.4.
2820 <group title=
"Instructions">
2822 Every version of OpenFlow includes actions. OpenFlow
1.1 introduced the
2823 higher-level, related concept of
<dfn>instructions
</dfn>. In OpenFlow
2824 1.1 and later, actions within a flow are always encapsulated within an
2825 instruction. Each flow has at most one instruction of each kind, which
2826 are executed in the following fixed order defined in the OpenFlow
2831 <li><code>Meter
</code></li>
2832 <li><code>Apply-Actions
</code></li>
2833 <li><code>Clear-Actions
</code></li>
2834 <li><code>Write-Actions
</code></li>
2835 <li><code>Write-Metadata
</code></li>
2836 <li><code>Stat-Trigger
</code> (not supported by Open vSwitch)
</li>
2837 <li><code>Goto-Table
</code></li>
2841 The most important instruction is
<code>Apply-Actions
</code>. This
2842 instruction encapsulates any number of actions, which the instruction
2843 executes. Open vSwitch does not explicitly represent
2844 <code>Apply-Actions
</code>. Instead, any action by itself is implicitly
2845 part of an
<code>Apply-Actions
</code> instructions.
2849 Open vSwitch syntax requires other instructions, if present, to be in the
2850 order listed above. Otherwise it will flag an error.
2853 <action name=
"METER">
2854 <h2>The
<code>meter
</code> action and instruction
</h2>
2855 <syntax><code>meter:
<var>meter_id
</var></code></syntax>
2858 Apply meter
<var>meter_id
</var>. If a meter band rate is exceeded, the
2859 packet may be dropped, or modified, depending on the meter band type.
2864 OpenFlow
1.3 introduced the
<code>meter
</code> instruction. OpenFlow
2865 1.5 changes
<code>meter
</code> from an instruction to an action.
2869 OpenFlow
1.5 allows implementations to restrict
<code>meter
</code> to
2870 be the first action in an action list and to exclude
2871 <code>meter
</code> from action sets, for better compatibility with
2872 OpenFlow
1.3 and
1.4. Open vSwitch restricts the
<code>meter
</code>
2877 Open vSwitch
2.0 introduced OpenFlow protocol support for meters, but
2878 it did not include a datapath implementation. Open vSwitch
2.7 added
2879 meter support to the userspace datapath. Open vSwitch
2.10 added
2880 meter support to the kernel datapath. Open vSwitch
2.12 added
2881 support for meter as an action in OpenFlow
1.5.
2886 <action name=
"CLEAR_ACTIONS">
2887 <h2>The
<code>clear_actions
</code> instruction
</h2>
2888 <syntax><code>clear_actions
</code></syntax>
2891 Clears the action set. See ``Action Sets'', above, for more
2896 OpenFlow
1.1 introduced
<code>clear_actions
</code>. Open vSwitch
2.1
2897 added support for
<code>clear_actions
</code>.
2901 <action name=
"WRITE_ACTIONS">
2902 <h2>The
<code>write_actions
</code> instruction
</h2>
2903 <syntax><code>write_actions(
<var>action
</var></code>...
<code>)
</code></syntax>
2906 Adds each
<var>action
</var> to the action set. The action set is
2907 carried between flow tables and then executed at the end of the
2908 pipeline. Only certain actions may be written to the action set. See
2909 ``Action Sets'', above, for more information.
2913 OpenFlow
1.1 introduced
<code>write_actions
</code>. Open vSwitch
2.1
2914 added support for
<code>write_actions
</code>.
2918 <action name=
"WRITE_METADATA">
2919 <h2>The
<code>write_metadata
</code> instruction
</h2>
2920 <syntax><code>write_metadata:
<var>value
</var></code>[
<code>/
<var>mask
</var></code>]
</syntax>
2923 Updates the flow's
<code>metadata
</code> field. If
<var>mask
</var> is
2924 omitted,
<code>metadata
</code> is set exactly to
<var>value
</var>; if
2925 <var>mask
</var> is specified, then a
1-bit in
<var>mask
</var> indicates
2926 that the corresponding bit in
<code>metadata
</code> will be replaced
2927 with the corresponding bit from
<var>value
</var>. Both
2928 <var>value
</var> and
<var>mask
</var> are
64-bit values that are decimal
2929 by default; use a
<code>0x
</code> prefix to specify them in
2934 The
<code>metadata
</code> field can also be matched in the flow table
2935 and updated with actions such as
<code>set_field
</code> and
2940 OpenFlow
1.1 introduced
<code>write_metadata
</code>. Open vSwitch
2.1
2941 added support for
<code>write_metadata
</code>.
2945 <action name=
"GOTO_TABLE">
2946 <h2>The
<code>goto_table
</code> instruction
</h2>
2947 <syntax><code>goto_table:
<var>table
</var></code></syntax>
2950 Jumps to
<var>table
</var> as the next table in the process pipeline.
2951 The table may be a number between
0 and
254 or a table name.
2955 It is an error if
<var>table
</var> is less than or equal to the table
2956 of the flow that contains it; that is,
<code>goto_table
</code> must
2957 move forward in the OpenFlow pipeline. Since
<code>goto_table
</code>
2958 must be the last instruction in a flow, it never leads to recursion.
2959 The
<code>resubmit
</code> extension action is more flexible.
2963 OpenFlow
1.1 introduced
<code>goto_table
</code>. Open vSwitch
2.1
2964 added support for
<code>goto_table
</code>.