<p>
The following modes require the upstream switch to support 802.3ad with
- successful LACP negotiation:
+ successful LACP negotiation. If LACP negotiation fails and
+ other-config:lacp-fallback-ab is true, then <code>active-backup</code>
+ mode is used:
</p>
<dl>
in LACP negotiations initiated by a remote switch, but not allowed to
initiate such negotiations themselves. If LACP is enabled on a port
whose partner switch does not support LACP, the bond will be
- disabled. Defaults to <code>off</code> if unset.
+ disabled, unless other-config:lacp-fallback-ab is set to true.
+ Defaults to <code>off</code> if unset.
</column>
<column name="other_config" key="lacp-system-id">
rate of once every 30 seconds.
</p>
</column>
+
+ <column name="other_config" key="lacp-fallback-ab"
+ type='{"type": "boolean"}'>
+ <p>
+ Determines the behavior of openvswitch bond in LACP mode. If
+ the partner switch does not support LACP, setting this option
+ to <code>true</code> allows openvswitch to fallback to
+ active-backup. If the option is set to <code>false</code>, the
+ bond will be disabled. In both the cases, once the partner switch
+ is configured to LACP mode, the bond will use LACP.
+ </p>
+ </column>
</group>
<group title="Rebalancing Configuration">
</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>
<dt><code>lisp</code></dt>
<dd>
- A layer 3 tunnel over the experimental, UDP-based Locator/ID
- Separation Protocol (RFC 6830).
+ <p>
+ A layer 3 tunnel over the experimental, UDP-based Locator/ID
+ Separation Protocol (RFC 6830).
+ </p>
+ <p>
+ Only IPv4 and IPv6 packets are supported by the protocol, and
+ they are sent and received without an Ethernet header. Traffic
+ to/from LISP ports is expected to be configured explicitly, and
+ the ports are not intended to participate in learning based
+ switching. As such, they are always excluded from packet
+ flooding.
+ </p>
</dd>
<dt><code>patch</code></dt>
In case of a problem, set to a short message that reports what the
remote endpoint's BFD session thinks is wrong.
</column>
+
+ <column name="bfd_status" key="flap_count"
+ type='{"type": "integer", "minInteger": 0}'>
+ Counts the number of <ref column="bfd_status" key="forwarding" />
+ flaps since start. A flap is considered as a change of the
+ <ref column="bfd_status" key="forwarding" /> value.
+ </column>
</group>
</group>
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">