<code>inport</code> to <code>outport</code>; if they are equal, it treats
the <code>output</code> as a no-op. In the common case, where they are
different, the packet enters the egress pipeline. This transition to the
- egress pipeline discards register data, e.g. <code>reg0</code>
- ... <code>reg5</code>, to achieve uniform behavior regardless of whether
- the egress pipeline is on a different hypervisor (because registers
- aren't preserve across tunnel encapsulation).
+ egress pipeline discards register data, e.g. <code>reg0</code> ...
+ <code>reg4</code> and connection tracking state, to achieve
+ uniform behavior regardless of whether the egress pipeline is on a
+ different hypervisor (because registers aren't preserve across
+ tunnel encapsulation).
</p>
<p>
</p>
<ul>
- <li><code>reg0</code>...<code>reg5</code></li>
+ <li><code>reg0</code>...<code>reg4</code></li>
<li><code>inport</code> <code>outport</code></li>
<li><code>eth.src</code> <code>eth.dst</code> <code>eth.type</code></li>
<li><code>vlan.tci</code> <code>vlan.vid</code> <code>vlan.pcp</code> <code>vlan.present</code></li>
<li><code>icmp4.type</code> <code>icmp4.code</code></li>
<li><code>icmp6.type</code> <code>icmp6.code</code></li>
<li><code>nd.target</code> <code>nd.sll</code> <code>nd.tll</code></li>
+ <li>
+ <p>
+ <code>ct_state</code>, which has the following Boolean subfields:
+ </p>
+ <ul>
+ <li><code>ct.new</code>: True for a new flow</li>
+ <li><code>ct.est</code>: True for an established flow</li>
+ <li><code>ct.rel</code>: True for a related flow</li>
+ <li><code>ct.rpl</code>: True for a reply flow</li>
+ <li><code>ct.inv</code>: True for a connection entry in a bad state</li>
+ </ul>
+ <p>
+ <code>ct_state</code> and its subfields are initialized by the
+ <code>ct_next</code> action, described below.
+ </p>
+ </li>
</ul>
<p>
</p>
<p>
- The following actions are defined:
+ The following actions are defined:
</p>
<dl>
<dt><code>output;</code></dt>
<dd>
<p>
- In the ingress pipeline, this action executes the
- <code>egress</code> pipeline as a subroutine. If
- <code>outport</code> names a logical port, the egress pipeline
- executes once; if it is a multicast group, the egress pipeline runs
- once for each logical port in the group.
+ In the ingress pipeline, this action executes the
+ <code>egress</code> pipeline as a subroutine. If
+ <code>outport</code> names a logical port, the egress pipeline
+ executes once; if it is a multicast group, the egress pipeline runs
+ once for each logical port in the group.
</p>
<p>
<code>output</code> becomes a no-op if <code>outport</code> ==
<code>inport</code>.
</p>
- </dd>
+ </dd>
<dt><code>next;</code></dt>
+ <dt><code>next(<var>table</var>);</code></dt>
<dd>
- Executes the next logical datapath table as a subroutine.
+ Executes another logical datapath table as a subroutine. By default,
+ the table after the current one is executed. Specify
+ <var>table</var> to jump to a specific table in the same pipeline.
</dd>
<dt><code><var>field</var> = <var>constant</var>;</code></dt>
<code>ingress</code> pipeline but not in the <code>egress</code>
pipeline.
</p>
- </dd>
+ </dd>
<dt><code><var>field1</var> = <var>field2</var>;</code></dt>
<dd>
that a logical flow with such an assignment will never be matched.
</p>
</dd>
+
+ <dt><code><var>field1</var> <-> <var>field2</var>;</code></dt>
+ <dd>
+ <p>
+ Similar to <code><var>field1</var> = <var>field2</var>;</code>
+ except that the two values are exchanged instead of copied. Both
+ <var>field1</var> and <var>field2</var> must modifiable.
+ </p>
+ </dd>
+
+ <dt><code>ct_next;</code></dt>
+ <dd>
+ <p>
+ Apply connection tracking to the flow, initializing
+ <code>ct_state</code> for matching in later tables.
+ Automatically moves on to the next table, as if followed by
+ <code>next</code>.
+ </p>
+
+ <p>
+ As a side effect, IP fragments will be reassembled for matching.
+ If a fragmented packet is output, then it will be sent with any
+ overlapping fragments squashed. The connection tracking state is
+ scoped by the logical port, so overlapping addresses may be used.
+ To allow traffic related to the matched flow, execute
+ <code>ct_commit</code>.
+ </p>
+
+ <p>
+ It is possible to have actions follow <code>ct_next</code>,
+ but they will not have access to any of its side-effects and
+ is not generally useful.
+ </p>
+ </dd>
+
+ <dt><code>ct_commit;</code></dt>
+ <dd>
+ Commit the flow to the connection tracking entry associated
+ with it by a previous call to <code>ct_next</code>.
+ </dd>
</dl>
<p>
<dl>
<dt><code>learn</code></dt>
- <dt><code>conntrack</code></dt>
-
<dt><code>dec_ttl { <var>action</var>, </code>...<code> } { <var>action</var>; </code>...<code>};</code></dt>
<dd>
decrement TTL; execute first set of actions if
projects / cascardo / ovs.git / blobdiff