host as displayed by <code>xe host-list</code>.
</column>
+ <column name="other_config" key="stats-update-interval"
+ type='{"type": "integer", "minInteger": 5000}'>
+ <p>
+ Interval for updating statistics to the database, in milliseconds.
+ This option will affect the update of the <code>statistics</code>
+ column in the following tables: <code>Port</code>, <code>Interface
+ </code>, <code>Mirror</code>.
+ </p>
+ <p>
+ Default value is 5000 ms.
+ </p>
+ <p>
+ Getting statistics more frequently can be achieved via OpenFlow.
+ </p>
+ </column>
+
<column name="other_config" key="flow-restore-wait"
type='{"type": "boolean"}'>
<p>
</column>
<column name="protocols">
- List of OpenFlow protocols that may be used when negotiating a
- connection with a controller. A default value of
- <code>OpenFlow10</code> will be used if this column is empty.
+ <p>
+ List of OpenFlow protocols that may be used when negotiating
+ a connection with a controller. OpenFlow 1.0, 1.1, 1.2, and
+ 1.3 are enabled by default if this column is empty.
+ </p>
+
+ <p>
+ The current implementation of OpenFlow 1.4 support is not safe:
+ <code>ovs-vswitchd</code> will abort when certain unimplemented
+ features are tested. Thus, for now it is suitable only for
+ experimental use. For this reason, OpenFlow 1.4 is supported only
+ if, in addition to specifying <code>OpenFlow14</code> in this field,
+ <code>ovs-vswitchd</code> is invoked with the
+ <code>--enable-of14</code> option. (When support becomes safe, this
+ option will be removed.)
+ </p>
</column>
</group>
<group title="Port Statistics">
<p>
- Key-value pairs that report port statistics.
+ Key-value pairs that report port statistics. The update period
+ is controlled by <ref column="other_config"
+ key="stats-update-interval"/> in the <code>Open_vSwitch</code> table.
</p>
<group title="Statistics: STP transmit and receive counters">
<column name="statistics" key="stp_tx_count">
<group title="Statistics">
<p>
Key-value pairs that report interface statistics. The current
- implementation updates these counters periodically. Future
- implementations may update them when an interface is created, when they
- are queried (e.g. using an OVSDB <code>select</code> operation), and
- just before an interface is deleted due to virtual interface hot-unplug
- or VM shutdown, and perhaps at other times, but not on any regular
- periodic basis.
+ implementation updates these counters periodically. The update period
+ is controlled by <ref column="other_config"
+ key="stats-update-interval"/> in the <code>Open_vSwitch</code> table.
+ Future implementations may update them when an interface is created,
+ when they are queried (e.g. using an OVSDB <code>select</code>
+ operation), and just before an interface is deleted due to virtual
+ interface hot-unplug or VM shutdown, and perhaps at other times, but
+ not on any regular periodic basis.
</p>
<p>
These are the same statistics reported by OpenFlow in its <code>struct
</column>
<column name="bfd" key="forwarding_if_rx" type='{"type": "boolean"}'>
- True to consider the interface capable of packet I/O as long as it
- continues to receive any packets (not just BFD packets). This
- prevents link congestion that causes consecutive BFD control packets
- to be lost from marking the interface down.
+ When <code>true</code>, traffic received on the
+ <ref table="Interface"/> is used to indicate the capability of packet
+ I/O. BFD control packets are still transmitted and received. At
+ least one BFD control packet must be received every 100 * <ref
+ column="bfd" key="min_rx"/> amount of time. Otherwise, even if
+ traffic are received, the <ref column="bfd" key="forwarding"/>
+ will be <code>false</code>.
</column>
<column name="bfd" key="cpath_down" type='{"type": "boolean"}'>
<ref column="other_config" key="cfm_extended"/> is true, the CFM
module operates in demand mode. When in demand mode, traffic
received on the <ref table="Interface"/> is used to indicate
- liveness. CCMs are still transmitted and received, but if the
- <ref table="Interface"/> is receiving traffic, their absence does not
- cause a connectivity fault.
+ liveness. CCMs are still transmitted and received. At least one
+ CCM must be received every 100 * <ref column="other_config"
+ key="cfm_interval"/> amount of time. Otherwise, even if traffic
+ are received, the CFM module will raise the connectivity fault.
</p>
<p>
one flow table. Currently this limit is 3.
</p>
</column>
+
+ <group title="Common Columns">
+ The overall purpose of these columns is described under <code>Common
+ Columns</code> at the beginning of this document.
+
+ <column name="external_ids"/>
+ </group>
</table>
<table name="QoS" title="Quality of Service configuration">
<group title="Statistics: Mirror counters">
<p>
- Key-value pairs that report mirror statistics.
+ Key-value pairs that report mirror statistics. The update period
+ is controlled by <ref column="other_config"
+ key="stats-update-interval"/> in the <code>Open_vSwitch</code> table.
</p>
<column name="statistics" key="tx_packets">
Number of packets transmitted through this mirror.