Set of bridges managed by the daemon.
</column>
- <column name="controller">
- Default OpenFlow <ref table="Controller"/> set used by bridges. May be
- overridden on a per-bridge basis by the <ref table="Bridge"
- column="controller"/> column in <ref table="Bridge"/>.
- </column>
-
<column name="managers">
Remote database clients to which the Open vSwitch's database server
should connect or to which it should listen.
</column>
<column name="external_ids">
- Key-value pairs that identify this Open vSwitch's role in
- external systems. The currently defined key-value pairs are:
+ Key-value pairs for use by external frameworks that integrate
+ with Open vSwitch, rather than by Open vSwitch itself. System
+ integrators should either use the Open vSwitch development
+ mailing list to coordinate on common key-value definitions, or
+ choose key names that are likely to be unique. The currently
+ defined common key-value pairs are:
<dl>
<dt><code>system-uuid</code></dt>
<dd>A universally unique identifier for the Open vSwitch's
capability categories and the meaning of associated
<ref table="Capability"/> records.
</column>
+
+ <column name="statistics">
+ <p>
+ Key-value pairs that report statistics about a running Open_vSwitch
+ daemon. The current implementation updates these counters
+ periodically. In the future, we plan to, instead, update them only
+ when they are queried (e.g. using an OVSDB <code>select</code>
+ operation) and perhaps at other times, but not on any regular
+ periodic basis.</p>
+ <p>
+ The currently defined key-value pairs are listed below. Some Open
+ vSwitch implementations may not support some statistics, in which
+ case those key-value pairs are omitted.</p>
+ <dl>
+ <dt><code>load-average</code></dt>
+ <dd>
+ System load average multiplied by 100 and rounded to the nearest
+ integer.</dd>
+ </dl>
+ </column>
</group>
</table>
<group title="OpenFlow Configuration">
<column name="controller">
- OpenFlow controller set. If unset, defaults to the set of
- controllers specified by <ref column="controller"
- table="Open_vSwitch"/> in the <ref table="Open_vSwitch"/>
- table. If the default is also unset, then no OpenFlow
- controllers will be used.
+ OpenFlow controller set. If unset, then no OpenFlow controllers
+ will be used.
+ </column>
+
+ <column name="fail_mode">
+ <p>When a controller is configured, it is, ordinarily, responsible
+ for setting up all flows on the switch. Thus, if the connection to
+ the controller fails, no new network connections can be set up.
+ If the connection to the controller stays down long enough,
+ no packets can pass through the switch at all. This setting
+ determines the switch's response to such a situation. It may be set
+ to one of the following:
+ <dl>
+ <dt><code>standalone</code></dt>
+ <dd>If no message is received from the controller for three
+ times the inactivity probe interval
+ (see <ref column="inactivity_probe"/>), then Open vSwitch
+ will take over responsibility for setting up flows. In
+ this mode, Open vSwitch causes the bridge to act like an
+ ordinary MAC-learning switch. Open vSwitch will continue
+ to retry connecting to the controller in the background
+ and, when the connection succeeds, it will discontinue its
+ standalone behavior.</dd>
+ <dt><code>secure</code></dt>
+ <dd>Open vSwitch will not set up flows on its own when the
+ controller connection fails or when no controllers are
+ defined. The bridge will continue to retry connecting to
+ any defined controllers forever.</dd>
+ </dl>
+ </p>
+ <p>If this value is unset, the default is implementation-specific.</p>
+ <p>When more than one controller is configured,
+ <ref column="fail_mode"/> is considered only when none of the
+ configured controllers can be contacted.</p>
</column>
<column name="datapath_id">
</column>
<column name="external_ids">
- Key-value pairs that identify this bridge's role in external systems.
- The currently defined key-value pairs are:
+ Key-value pairs for use by external frameworks that integrate
+ with Open vSwitch, rather than by Open vSwitch itself. System
+ integrators should either use the Open vSwitch development
+ mailing list to coordinate on common key-value definitions, or
+ choose key names that are likely to be unique. The currently
+ defined common key-value pairs are:
<dl>
<dt><code>network-uuids</code></dt>
<dd>Semicolon-delimited set of universally unique identifier(s) for
</column>
<column name="external_ids">
- Key-value pairs that identify this port's role in external systems. No
- key-value pairs native to <ref table="Port"/> are currently defined.
- For fake bridges (see the <ref column="fake_bridge"/> column), external
- IDs for the fake bridge are defined here by prefixing a
- <ref table="Bridge"/> <ref table="Bridge" column="external_ids"/> key
- with <code>fake-bridge-</code>,
- e.g. <code>fake-bridge-network-uuids</code>.
+ <p>
+ Key-value pairs for use by external frameworks that integrate with
+ Open vSwitch, rather than by Open vSwitch itself. System integrators
+ should either use the Open vSwitch development mailing list to
+ coordinate on common key-value definitions, or choose key names that
+ are likely to be unique.
+ </p>
+ <p>
+ No key-value pairs native to <ref table="Port"/> are currently
+ defined. For fake bridges (see the <ref column="fake_bridge"/>
+ column), external IDs for the fake bridge are defined here by
+ prefixing a <ref table="Bridge"/> <ref table="Bridge"
+ column="external_ids"/> key with <code>fake-bridge-</code>,
+ e.g. <code>fake-bridge-network-uuids</code>.
+ </p>
</column>
<column name="other_config">
the same except one has an optional identifier and the other does
not, the more specific one is matched first. <code>in_key</code>
is considered more specific than <code>local_ip</code> if a port
- defines one and another port defines the other. The arguments
- are:
+ defines one and another port defines the other. The following
+ options may be specified in the <ref column="options"/> column:
<dl>
<dt><code>remote_ip</code></dt>
<dd>Required. The tunnel endpoint.</dd>
</dl>
</dd>
<dt><code>patch</code></dt>
- <dd>A pair of virtual devices that act as a patch cable. A
- <code>peer</code> argument is required that indicates the name
- of the other side of the patch. Since a patch must work in
- pairs, a second patch interface must be declared with the
- <code>name</code> and <code>peer</code> arguments reversed.</dd>
+ <dd>
+ <p>
+ A pair of virtual devices that act as a patch cable. The <ref
+ column="options"/> column must have the following key-value pair:
+ </p>
+ <dl>
+ <dt><code>peer</code></dt>
+ <dd>
+ The <ref column="name"/> of the <ref table="Interface"/> for
+ the other side of the patch. The named <ref
+ table="Interface"/>'s own <code>peer</code> option must specify
+ this <ref table="Interface"/>'s name. That is, the two patch
+ interfaces must have reversed <ref column="name"/> and
+ <code>peer</code> values.
+ </dd>
+ </dl>
+ </dd>
</dl>
</column>
<group title="Other Features">
<column name="external_ids">
- <p>Key-value pairs that identify this interface's role in external
- systems. All of the currently defined key-value pairs specifically
+ <p>
+ Key-value pairs for use by external frameworks that integrate
+ with Open vSwitch, rather than by Open vSwitch itself. System
+ integrators should either use the Open vSwitch development
+ mailing list to coordinate on common key-value definitions, or
+ choose key names that are likely to be unique.
+ </p>
+ <p>
+ All of the currently defined key-value pairs specifically
apply to an interface that represents a virtual Ethernet interface
connected to a virtual machine. These key-value pairs should not be
present for other types of interfaces. Keys whose names end
in <code>-uuid</code> have values that uniquely identify the entity
in question. For a Citrix XenServer hypervisor, these values are
UUIDs in RFC 4122 format. Other hypervisors may use other
- formats.</p>
+ formats.
+ </p>
<p>The currently defined key-value pairs are:</p>
<dl>
<dt><code>vif-uuid</code></dt>
field in the VIF record for this interface.</dd>
</dl>
</column>
+
+ <column name="statistics">
+ <p>
+ Key-value pairs that report interface statistics. The current
+ implementation updates these counters periodically. In the future,
+ we plan to, instead, 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>
+ The currently defined key-value pairs are listed below. These are
+ the same statistics reported by OpenFlow in its <code>struct
+ ofp_port_stats</code> structure. If an interface does not support a
+ given statistic, then that pair is omitted.</p>
+ <ul>
+ <li>
+ Successful transmit and receive counters:
+ <dl>
+ <dt><code>rx_packets</code></dt>
+ <dd>Number of received packets.</dd>
+ <dt><code>rx_bytes</code></dt>
+ <dd>Number of received bytes.</dd>
+ <dt><code>tx_packets</code></dt>
+ <dd>Number of transmitted packets.</dd>
+ <dt><code>tx_bytes</code></dt>
+ <dd>Number of transmitted bytes.</dd>
+ </dl>
+ </li>
+ <li>
+ Receive errors:
+ <dl>
+ <dt><code>rx_dropped</code></dt>
+ <dd>Number of packets dropped by RX.</dd>
+ <dt><code>rx_frame_err</code></dt>
+ <dd>Number of frame alignment errors.</dd>
+ <dt><code>rx_over_err</code></dt>
+ <dd>Number of packets with RX overrun.</dd>
+ <dt><code>rx_crc_err</code></dt>
+ <dd>Number of CRC errors.</dd>
+ <dt><code>rx_errors</code></dt>
+ <dd>
+ Total number of receive errors, greater than or equal
+ to the sum of the above.
+ </dd>
+ </dl>
+ </li>
+ <li>
+ Transmit errors:
+ <dl>
+ <dt><code>tx_dropped</code></dt>
+ <dd>Number of packets dropped by TX.</dd>
+ <dt><code>collisions</code></dt>
+ <dd>Number of collisions.</dd>
+ <dt><code>tx_errors</code></dt>
+ <dd>
+ Total number of transmit errors, greater
+ than or equal to the sum of the above.
+ </dd>
+ </dl>
+ </li>
+ </ul>
+ </column>
</group>
</table>
Mbps.</dd>
</dl>
</column>
+
+ <column name="external_ids">
+ Key-value pairs for use by external frameworks that integrate with Open
+ vSwitch, rather than by Open vSwitch itself. System integrators should
+ either use the Open vSwitch development mailing list to coordinate on
+ common key-value definitions, or choose key names that are likely to be
+ unique. No common key-value pairs are currently defined.
+ </column>
</table>
<table name="Queue" title="QoS output queue.">
values are unimportant; only relative ordering matters.</dd>
</dl>
</column>
+
+ <column name="external_ids">
+ Key-value pairs for use by external frameworks that integrate with Open
+ vSwitch, rather than by Open vSwitch itself. System integrators should
+ either use the Open vSwitch development mailing list to coordinate on
+ common key-value definitions, or choose key names that are likely to be
+ unique. No common key-value pairs are currently defined.
+ </column>
</table>
<table name="Mirror" title="Port mirroring (SPAN/RSPAN).">
in the appropriate <ref table="Bridge"/> table or tables.</p>
</column>
</group>
+
+ <group title="Other Features">
+ <column name="external_ids">
+ Key-value pairs for use by external frameworks that integrate with Open
+ vSwitch, rather than by Open vSwitch itself. System integrators should
+ either use the Open vSwitch development mailing list to coordinate on
+ common key-value definitions, or choose key names that are likely to be
+ unique. No common key-value pairs are currently defined.
+ </column>
+ </group>
</table>
<table name="Controller" title="OpenFlow controller configuration.">
<p>An OpenFlow controller.</p>
- <p>Open vSwitch permits a bridge to have any number of OpenFlow
- controllers. When multiple controllers are configured, Open vSwitch
- connects to all of them simultaneously. OpenFlow 1.0 does not specify
- how multiple controllers coordinate in interacting with a single switch,
- so more than one controller should be specified only if the controllers
- are themselves designed to coordinate with each other.</p>
+ <p>
+ Open vSwitch supports two kinds of OpenFlow controllers:
+ </p>
+
+ <dl>
+ <dt>Primary controllers</dt>
+ <dd>
+ <p>
+ This is the kind of controller envisioned by the OpenFlow 1.0
+ specification. Usually, a primary controller implements a network
+ policy by taking charge of the switch's flow table.
+ </p>
+
+ <p>
+ Open vSwitch initiates and maintains persistent connections to
+ primary controllers, retrying the connection each time it fails or
+ drops. The <ref table="Bridge" column="fail_mode"/> column in the
+ <ref table="Bridge"/> table applies to primary controllers.
+ </p>
+
+ <p>
+ Open vSwitch permits a bridge to have any number of primary
+ controllers. When multiple controllers are configured, Open
+ vSwitch connects to all of them simultaneously. Because
+ OpenFlow 1.0 does not specify how multiple controllers
+ coordinate in interacting with a single switch, more than
+ one primary controller should be specified only if the
+ controllers are themselves designed to coordinate with each
+ other. (The Nicira-defined <code>NXT_ROLE</code> OpenFlow
+ vendor extension may be useful for this.)
+ </p>
+ </dd>
+ <dt>Service controllers</dt>
+ <dd>
+ <p>
+ These kinds of OpenFlow controller connections are intended for
+ occasional support and maintenance use, e.g. with
+ <code>ovs-ofctl</code>. Usually a service controller connects only
+ briefly to inspect or modify some of a switch's state.
+ </p>
+
+ <p>
+ Open vSwitch listens for incoming connections from service
+ controllers. The service controllers initiate and, if necessary,
+ maintain the connections from their end. The <ref table="Bridge"
+ column="fail_mode"/> column in the <ref table="Bridge"/> table does
+ not apply to service controllers.
+ </p>
+
+ <p>
+ Open vSwitch supports configuring any number of service controllers.
+ </p>
+ </dd>
+ </dl>
+
+ <p>
+ The <ref column="target"/> determines the type of controller.
+ </p>
<group title="Core Features">
<column name="target">
- <p>Connection method for controller.
- The following connection methods are currently
- supported:</p>
+ <p>Connection method for controller.</p>
+ <p>
+ The following connection methods are currently supported for primary
+ controllers:
+ </p>
<dl>
<dt><code>ssl:<var>ip</var></code>[<code>:<var>port</var></code>]</dt>
<dd>
<p>The specified SSL <var>port</var> (default: 6633) on the host at
- the given <var>ip</var>, which must be expressed as an IP address
- (not a DNS name). The <ref table="Open_vSwitch" column="ssl"/>
- column in the <ref table="Open_vSwitch"/> must point to a valid
- SSL configuration when this form is used.</p>
+ the given <var>ip</var>, which must be expressed as an IP address
+ (not a DNS name). The <ref table="Open_vSwitch" column="ssl"/>
+ column in the <ref table="Open_vSwitch"/> table must point to a
+ valid SSL configuration when this form is used.</p>
<p>SSL support is an optional feature that is not always built as
part of Open vSwitch.</p>
</dd>
used only for bootstrapping the OpenFlow PKI at initial switch
setup; <code>ovs-vswitchd</code> does not use it at all.</p>
</dd>
- <dt><code>none</code></dt>
- <dd>Disables the controller.</dd>
+ </dl>
+ <p>
+ The following connection methods are currently supported for service
+ controllers:
+ </p>
+ <dl>
+ <dt><code>pssl:</code>[<var>port</var>][<code>:<var>ip</var></code>]</dt>
+ <dd>
+ <p>
+ Listens for SSL connections on the specified TCP <var>port</var>
+ (default: 6633). If <var>ip</var>, which must be expressed as an
+ IP address (not a DNS name), is specified, then connections are
+ restricted to the specified local IP address.
+ </p>
+ <p>
+ The <ref table="Open_vSwitch" column="ssl"/> column in the <ref
+ table="Open_vSwitch"/> table must point to a valid SSL
+ configuration when this form is used.
+ </p>
+ <p>SSL support is an optional feature that is not always built as
+ part of Open vSwitch.</p>
+ </dd>
+ <dt><code>ptcp:</code>[<var>port</var>][<code>:<var>ip</var></code>]</dt>
+ <dd>
+ Listens for connections on the specified TCP <var>port</var>
+ (default: 6633). If <var>ip</var>, which must be expressed as an
+ IP address (not a DNS name), is specified, then connections are
+ restricted to the specified local IP address.
+ </dd>
</dl>
<p>When multiple controllers are configured for a single bridge, the
<ref column="target"/> values must be unique. Duplicate
assumes the connection has been broken and attempts to reconnect.
Default is implementation-specific.
</column>
-
- <column name="fail_mode">
- <p>When a controller is configured, it is, ordinarily, responsible
- for setting up all flows on the switch. Thus, if the connection to
- the controller fails, no new network connections can be set up.
- If the connection to the controller stays down long enough,
- no packets can pass through the switch at all. This setting
- determines the switch's response to such a situation. It may be set
- to one of the following:
- <dl>
- <dt><code>standalone</code></dt>
- <dd>If no message is received from the controller for three
- times the inactivity probe interval
- (see <ref column="inactivity_probe"/>), then Open vSwitch
- will take over responsibility for setting up flows. In
- this mode, Open vSwitch causes the bridge to act like an
- ordinary MAC-learning switch. Open vSwitch will continue
- to retry connecting to the controller in the background
- and, when the connection succeeds, it will discontinue its
- standalone behavior.</dd>
- <dt><code>secure</code></dt>
- <dd>Open vSwitch will not set up flows on its own when the
- controller connection fails. It will continue retry
- connecting to the controller forever.</dd>
- </dl>
- </p>
- <p>If this value is unset, the default is implementation-specific.</p>
- <p>When more than one controller is configured,
- <ref column="fail_mode"/> is considered only when none of the
- configured controllers can be contacted. At that point, the bridge
- enters secure mode if any of the controllers'
- <ref column="fail_mode"/> is set to <code>secure</code>. Otherwise,
- it enters standalone mode if at least one <ref column="fail_mode"/>
- is set to <code>standalone</code>. If none of the
- <ref column="fail_mode"/> values are set, the default is
- implementation-defined.</p>
- </column>
</group>
<group title="OpenFlow Rate Limiting">
this network has no gateway.
</column>
</group>
+
+ <group title="Other Features">
+ <column name="external_ids">
+ Key-value pairs for use by external frameworks that integrate with Open
+ vSwitch, rather than by Open vSwitch itself. System integrators should
+ either use the Open vSwitch development mailing list to coordinate on
+ common key-value definitions, or choose key names that are likely to be
+ unique. No common key-value pairs are currently defined.
+ </column>
+ </group>
</table>
<table name="NetFlow">
disambiguate the traffic.</p>
<p>When this option is enabled, a maximum of 508 ports are supported.</p>
</column>
+
+ <column name="external_ids">
+ Key-value pairs for use by external frameworks that integrate with Open
+ vSwitch, rather than by Open vSwitch itself. System integrators should
+ either use the Open vSwitch development mailing list to coordinate on
+ common key-value definitions, or choose key names that are likely to be
+ unique. No common key-value pairs are currently defined.
+ </column>
</table>
<table name="SSL">
SSL connection to a man-in-the-middle attack obtaining the initial
CA certificate.</em> It may still be useful for bootstrapping.
</column>
+
+ <column name="external_ids">
+ Key-value pairs for use by external frameworks that integrate with Open
+ vSwitch, rather than by Open vSwitch itself. System integrators should
+ either use the Open vSwitch development mailing list to coordinate on
+ common key-value definitions, or choose key names that are likely to be
+ unique. No common key-value pairs are currently defined.
+ </column>
</table>
<table name="sFlow">
sFlow targets in the form
<code><var>ip</var>:<var>port</var></code>.
</column>
+
+ <column name="external_ids">
+ Key-value pairs for use by external frameworks that integrate with Open
+ vSwitch, rather than by Open vSwitch itself. System integrators should
+ either use the Open vSwitch development mailing list to coordinate on
+ common key-value definitions, or choose key names that are likely to be
+ unique. No common key-value pairs are currently defined.
+ </column>
</table>
<table name="Capability">