</p>
<p>
- Open vSwitch currently assigns the OpenFlow port number for an
- interface once, when the client first adds the interface. It does
- not change the port number later if the client sets or changes or
- clears <ref column="ofport_request"/>. Therefore, to ensure that
- <ref column="ofport_request"/> takes effect, the client should set
- it in the same database transaction that creates the interface.
- (Future versions of Open vSwitch might honor changes to <ref
- column="ofport_request"/>.)
+ A client should ideally set this column's value in the same
+ database transaction that it uses to create the interface. Open
+ vSwitch version 2.1 and later will honor a later request for a
+ specific port number, althuogh it might confuse some controllers:
+ OpenFlow does not have a way to announce a port number change, so
+ Open vSwitch represents it over OpenFlow as a port deletion
+ followed immediately by a port addition.
+ </p>
+
+ <p>
+ If <ref column="ofport_request"/> is set or changed to some other
+ port's automatically assigned port number, Open vSwitch chooses a
+ new port number for the latter port.
</p>
</column>
</group>
</p>
<column name="cfm_mpid">
- A Maintenance Point ID (MPID) uniquely identifies each endpoint within
- a Maintenance Association. The MPID is used to identify this endpoint
- to other Maintenance Points in the MA. Each end of a link being
- monitored should have a different MPID. Must be configured to enable
- CFM on this <ref table="Interface"/>.
+ <p>
+ A Maintenance Point ID (MPID) uniquely identifies each endpoint
+ within a Maintenance Association. The MPID is used to identify this
+ endpoint to other Maintenance Points in the MA. Each end of a link
+ being monitored should have a different MPID. Must be configured to
+ enable CFM on this <ref table="Interface"/>.
+ </p>
+ <p>
+ According to the 802.1ag specification, MPIDs can only range between
+ [1, 8191]. However, extended mode (see <ref column="other_config"
+ key="cfm_extended"/>) supports eight byte MPIDs.
+ </p>
</column>
<column name="cfm_flap_count">
with compliant implementations which may be running concurrently on the
network. Furthermore, extended mode increases the accuracy of the
<code>cfm_interval</code> configuration parameter by breaking wire
- compatibility with 802.1ag compliant implementations. Defaults to
- <code>false</code>.
+ compatibility with 802.1ag compliant implementations. And extended
+ mode allows eight byte MPIDs. Defaults to <code>false</code>.
</column>
<column name="other_config" key="cfm_demand" type='{"type": "boolean"}'>
column has no effect.
</p>
</column>
+
+ <column name="prefixes">
+ <p>
+ This string set specifies which fields should be used for
+ address prefix tracking. Prefix tracking allows the
+ classifier to skip rules with longer than necessary prefixes,
+ resulting in better wildcarding for datapath flows.
+ </p>
+ <p>
+ Prefix tracking may be beneficial when a flow table contains
+ matches on IP address fields with different prefix lengths.
+ For example, when a flow table contains IP address matches on
+ both full addresses and proper prefixes, the full address
+ matches will typically cause the datapath flow to un-wildcard
+ the whole address field (depending on flow entry priorities).
+ In this case each packet with a different address gets handed
+ to the userspace for flow processing and generates its own
+ datapath flow. With prefix tracking enabled for the address
+ field in question packets with addresses matching shorter
+ prefixes would generate datapath flows where the irrelevant
+ address bits are wildcarded, allowing the same datapath flow
+ to handle all the packets within the prefix in question. In
+ this case many userspace upcalls can be avoided and the
+ overall performance can be better.
+ </p>
+ <p>
+ This is a performance optimization only, so packets will
+ receive the same treatment with or without prefix tracking.
+ </p>
+ <p>
+ The supported fields are: <code>tun_id</code>,
+ <code>tun_src</code>, <code>tun_dst</code>,
+ <code>nw_src</code>, <code>nw_dst</code> (or aliases
+ <code>ip_src</code> and <code>ip_dst</code>),
+ <code>ipv6_src</code>, and <code>ipv6_dst</code>. (Using this
+ feature for <code>tun_id</code> would only make sense if the
+ tunnel IDs have prefix structure similar to IP addresses.)
+ </p>
+ <p>
+ For example, <code>prefixes=ip_dst,ip_src</code> instructs the
+ flow classifier to track the IP destination and source
+ addresses used by the rules in this specific flow table. To
+ set the prefix fields, the flow table record needs to exist:
+ </p>
+ <dl>
+ <dt><code>ovs-vsctl set Bridge br0 flow_tables:0=@N1 -- --id=@N1 create Flow_Table name=table0</code></dt>
+ <dd>
+ Creates a flow table record for the OpenFlow table number 0.
+ </dd>
+
+ <dt><code>ovs-vsctl set Flow_Table table0 prefixes=ip_dst,ip_src</code></dt>
+ <dd>
+ Enables prefix tracking for IP source and destination
+ address fields.
+ </dd>
+ </dl>
+
+ <p>
+ There is a maximum number of fields that can be enabled for any
+ one flow table. Currently this limit is 3.
+ </p>
+ </column>
</table>
<table name="QoS" title="Quality of Service configuration">