X-Git-Url: http://git.onelab.eu/?a=blobdiff_plain;f=vswitchd%2Fvswitch.xml;h=2889a4105511ae473c547d1e3770d1a4dad8aded;hb=7f8f2757f3d6749f832f9fe2c0229d6587cfbad9;hp=d2fba341f905fa61b69777721da4da2b2ab99d0a;hpb=484c8355ded7682e2a722eb7da8782b9f9b576c5;p=sliver-openvswitch.git

diff --git a/vswitchd/vswitch.xml b/vswitchd/vswitch.xml
index d2fba341f..2889a4105 100644
--- a/vswitchd/vswitch.xml
+++ b/vswitchd/vswitch.xml
@@ -941,7 +941,9 @@
 
       <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>
@@ -1031,7 +1033,8 @@
           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">
@@ -1059,6 +1062,18 @@
             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">
@@ -1291,14 +1306,19 @@
 	  </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>
@@ -1372,8 +1392,18 @@
 
           <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>
@@ -1994,6 +2024,13 @@
 	  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>
 
@@ -2502,6 +2539,68 @@
         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">