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
- physical host. The form of the identifier depends on the
- type of the host. On a Citrix XenServer, this is the host
- UUID displayed by, e.g., <code>xe host-list</code>.</dd>
+ <dt><code>system-type</code></dt>
+ <dd>An identifier for the switch type, such as
+ <code>XenServer</code> or <code>KVM</code>.</dd>
+ <dt><code>system-version</code></dt>
+ <dd>The version of the switch software, such as
+ <code>5.6.0</code> on XenServer.</dd>
+ <dt><code>system-id</code></dt>
+ <dd>A unique identifier for the Open vSwitch's physical host.
+ The form of the identifier depends on the type of the host.
+ On a Citrix XenServer, this will likely be the same as
+ <code>xs-system-uuid</code>.</dd>
+ <dt><code>xs-system-uuid</code></dt>
+ <dd>The Citrix XenServer universally unique identifier for the
+ physical host as displayed by <code>xe host-list</code>.</dd>
</dl>
</column>
</group>
<ref column="next_cfg"/> after it finishes applying a set of
configuration changes.
</column>
+
+ <column name="capabilities">
+ Describes functionality supported by the hardware and software platform
+ on which this Open vSwitch is based. Clients should not modify this
+ column. See the <ref table="Capability"/> description for defined
+ 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 key-value pairs are:
<dl>
- <dt><code>network-uuids</code></dt>
+ <dt><code>bridge-id</code></dt>
+ <dd>A unique identifier of the bridge. On Citrix XenServer this
+ will commonly be the same as <code>xs-network-uuids</code>.</dd>
+ <dt><code>xs-network-uuids</code></dt>
<dd>Semicolon-delimited set of universally unique identifier(s) for
- the network with which this bridge is associated. The form of the
- identifier(s) depends on the type of the host. On a Citrix
- XenServer host, the network identifiers are RFC 4122 UUIDs as
+ the network with which this bridge is associated on a Citrix
+ XenServer host. The network identifiers are RFC 4122 UUIDs as
displayed by, e.g., <code>xe network-list</code>.</dd>
</dl>
</column>
<p>A bridge port must be configured for VLANs in one of two
mutually exclusive ways:
<ul>
- <li>A ``trunk port'' has an empty value for
- <ref column="tag"/> and a possibly non-empty
- <ref column="trunks"/> value.</li>
+ <li>A ``trunk port'' has an empty value for <ref
+ column="tag"/>. Its <ref column="trunks"/> value may be
+ empty or non-empty.</li>
<li>An ``implicitly tagged VLAN port'' or ``access port''
- has an nonempty value for <ref column="tag"/> and an empty
- <ref column="trunks"/> value.</li>
+ has an nonempty value for <ref column="tag"/>. Its
+ <ref column="trunks"/> value must be empty.</li>
</ul>
If <ref column="trunks"/> and <ref column="tag"/> are both
nonempty, the configuration is ill-formed.
</p>
<column name="tag">
- <p>If nonempty, this port's implicitly tagged VLAN. Frames
- arriving on trunk ports will be forwarded to this port only
- if they are tagged with the given VLAN. Frames arriving on
- other VLAN ports will be forwarded to this port only if they
- have the same <ref column="tag"/> value. Frames forwarded
- to this port will not have an 802.1Q header.</p>
- <p>When a frame with a 802.1Q header that indicates a nonzero VLAN is
- received on an implicit VLAN port, it is discarded.</p>
- <p>Must be empty if this is a trunk port.</p>
+ <p>
+ If this is an access port (see above), the port's implicitly
+ tagged VLAN. Must be empty if this is a trunk port.
+ </p>
+ <p>
+ Frames arriving on trunk ports will be forwarded to this
+ port only if they are tagged with the given VLAN (or, if
+ <ref column="tag"/> is 0, then if they lack a VLAN header).
+ Frames arriving on other access ports will be forwarded to
+ this port only if they have the same <ref column="tag"/>
+ value. Frames forwarded to this port will not have an
+ 802.1Q header.
+ </p>
+ <p>
+ When a frame with a 802.1Q header that indicates a nonzero
+ VLAN is received on an access port, it is discarded.
+ </p>
</column>
<column name="trunks">
- <p>The 802.1Q VLAN(s) that this port trunks. If the column is
- empty, then the port trunks all VLANs as well as packets that
- have no VLAN header. Otherwise, only frames that have an
- 802.1Q header with one of the specified VLANs are accepted.
- If <code>0</code> is included, then frames without an 802.1Q
- header are also accepted.</p>
- <p>Must be empty unless this is a trunk port.</p>
+ <p>
+ If this is a trunk port (see above), the 802.1Q VLAN(s) that
+ this port trunks; if it is empty, then the port trunks all
+ VLANs. Must be empty if this is an access port.
+ </p>
+ <p>
+ Frames arriving on trunk ports are dropped if they are not
+ in one of the specified VLANs. For this purpose, packets
+ that have no VLAN header are treated as part of VLAN 0.
+ </p>
</column>
</group>
</group>
<group title="Other Features">
+ <column name="qos">
+ Quality of Service configuration for this port.
+ </column>
+
<column name="mac">
The MAC address to use for this port for the purpose of choosing the
bridge's MAC address. This column does not necessarily reflect the
</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-xs-network-uuids</code>.
+ </p>
</column>
<column name="other_config">
<dt><code>tap</code></dt>
<dd>A TUN/TAP device managed by Open vSwitch.</dd>
<dt><code>gre</code></dt>
- <dd>An Ethernet over RFC 1702 Generic Routing Encapsulation over IPv4
+ <dd>An Ethernet over RFC 2890 Generic Routing Encapsulation over IPv4
tunnel. Each tunnel must be uniquely identified by the
combination of <code>remote_ip</code>, <code>local_ip</code>, and
<code>in_key</code>. Note that if two ports are defined that are
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>
either be a 32-bit number or the word <code>flow</code>. If
<code>flow</code> is specified then the key may be set using
the <code>set_tunnel</code> Nicira OpenFlow vendor extension (0
- is used in the absense of an action). The ovs-ofctl manual
+ is used in the absence of an action). The ovs-ofctl manual
page contains additional information about the Nicira OpenFlow
vendor extensions. Default is no key.</dd>
</dl>
</dl>
<dl>
<dt><code>csum</code></dt>
- <dd>Optional. Compute GRE checksums for outgoing packets and
- require checksums for incoming packets. Default is enabled,
- set to <code>false</code> to disable.</dd>
+ <dd>Optional. Compute GRE checksums on outgoing packets.
+ Checksums present on incoming packets will be validated
+ regardless of this setting. Note that GRE checksums
+ impose a significant performance penalty as they cover the
+ entire packet. As the contents of the packet is typically
+ covered by L3 and L4 checksums, this additional checksum only
+ adds value for the GRE and encapsulated Ethernet headers.
+ Default is disabled, set to <code>true</code> to enable.</dd>
+ </dl>
+ <dl>
+ <dt><code>pmtud</code></dt>
+ <dd>Optional. Enable tunnel path MTU discovery. If enabled
+ ``ICMP destination unreachable - fragmentation'' needed
+ messages will be generated for IPv4 packets with the DF bit set
+ and IPv6 packets above the minimum MTU if the packet size
+ exceeds the path MTU minus the size of the tunnel headers. It
+ also forces the encapsulating packet DF bit to be set (it is
+ always set if the inner packet implies path MTU discovery).
+ Note that this option causes behavior that is typically
+ reserved for routers and therefore is not entirely in
+ compliance with the IEEE 802.1D specification for bridges.
+ Default is enabled, set to <code>false</code> to disable.</dd>
+ </dl>
+ </dd>
+ <dt><code>capwap</code></dt>
+ <dd>Ethernet tunneling over the UDP transport portion of CAPWAP
+ (RFC 5415). This allows interoperability with certain switches
+ where GRE is not available. Note that only the tunneling component
+ of the protocol is implemented. Due to the non-standard use of
+ CAPWAP, UDP ports 58881 and 58882 are used as the source and
+ destinations ports respectivedly. Each tunnel must be uniquely
+ identified by the combination of <code>remote_ip</code> and
+ <code>local_ip</code>. If two ports are defined that are the same
+ except one includes <code>local_ip</code> and the other does not,
+ the more specific one is matched first. CAPWAP support is not
+ available on all platforms. Currently it is only supported in the
+ Linux kernel module with kernel versions >= 2.6.25. 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>
+ <dl>
+ <dt><code>local_ip</code></dt>
+ <dd>Optional. The destination IP that received packets must
+ match. Default is to match all addresses.</dd>
+ </dl>
+ <dl>
+ <dt><code>tos</code></dt>
+ <dd>Optional. The value of the ToS bits to be set on the
+ encapsulating packet. It may also be the word
+ <code>inherit</code>, in which case the ToS will be copied from
+ the inner packet if it is IPv4 or IPv6 (otherwise it will be
+ 0). Note that the ECN fields are always inherited. Default is
+ 0.</dd>
+ </dl>
+ <dl>
+ <dt><code>ttl</code></dt>
+ <dd>Optional. The TTL to be set on the encapsulating packet.
+ It may also be the word <code>inherit</code>, in which case the
+ TTL will be copied from the inner packet if it is IPv4 or IPv6
+ (otherwise it will be the system default, typically 64).
+ Default is the system default TTL.</dd>
</dl>
<dl>
<dt><code>pmtud</code></dt>
</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>
Configuration options whose interpretation varies based on
<ref column="type"/>.
</column>
+
+ <column name="status">
+ <p>
+ Key-value pairs that report port status. Supported status
+ values are <code>type</code>-dependent.
+ </p>
+ <p>The only currently defined key-value pair is:</p>
+ <dl>
+ <dt><code>source_ip</code></dt>
+ <dd>The source IP address used for an IPv4 tunnel end-point,
+ such as <code>gre</code> or <code>capwap</code>. Not
+ supported by all implementations.</dd>
+ </dl>
+ </column>
</group>
<group title="Ingress Policing">
<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
+ 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>attached-mac</code></dt>
+ <dd>
+ The MAC address programmed into the ``virtual hardware'' for this
+ interface, in the form
+ <var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>.
+ For Citrix XenServer, this is the value of the <code>MAC</code>
+ field in the VIF record for this interface.</dd>
+ <dt><code>iface-id</code></dt>
+ <dd>A system-unique identifier for the interface. On XenServer,
+ this will commonly be the same as <code>xs-vif-uuid</code>.</dd>
+ </dl>
+ <p>
+ Additionally the following 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>
- <p>The currently defined key-value pairs are:</p>
+ formats.
+ </p>
+ <p>The currently defined key-value pairs for XenServer are:</p>
<dl>
- <dt><code>vif-uuid</code></dt>
+ <dt><code>xs-vif-uuid</code></dt>
<dd>The virtual interface associated with this interface.</dd>
- <dt><code>network-uuid</code></dt>
+ <dt><code>xs-network-uuid</code></dt>
<dd>The virtual network to which this interface is attached.</dd>
- <dt><code>vm-uuid</code></dt>
+ <dt><code>xs-vm-uuid</code></dt>
<dd>The VM to which this interface belongs.</dd>
- <dt><code>vif-mac</code></dt>
- <dd>The MAC address programmed into the "virtual hardware" for this
- interface, in the
- form <var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>.
- For Citrix XenServer, this is the value of the <code>MAC</code>
- 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>
+ <table name="QoS" title="Quality of Service configuration">
+ <p>Quality of Service (QoS) configuration for each Port that
+ references it.</p>
+
+ <column name="type">
+ <p>The type of QoS to implement. The <ref table="Open_vSwitch"
+ column="capabilities"/> column in the <ref table="Open_vSwitch"/> table
+ identifies the types that a switch actually supports. The currently
+ defined types are listed below:</p>
+ <dl>
+ <dt><code>linux-htb</code></dt>
+ <dd>Linux ``hierarchy token bucket'' classifier.</dd>
+ </dl>
+ </column>
+
+ <column name="queues">
+ <p>A map from queue numbers to <ref table="Queue"/> records. The
+ supported range of queue numbers depend on <ref column="type"/>. The
+ queue numbers are the same as the <code>queue_id</code> used in
+ OpenFlow in <code>struct ofp_action_enqueue</code> and other
+ structures. Queue 0 is used by OpenFlow output actions that do not
+ specify a specific queue.</p>
+ </column>
+
+ <column name="other_config">
+ <p>Key-value pairs for configuring QoS features that depend on
+ <ref column="type"/>.</p>
+ <p>The <code>linux-htb</code> class supports the following key-value
+ pairs:</p>
+ <dl>
+ <dt><code>max-rate</code></dt>
+ <dd>Maximum rate shared by all queued traffic, in bit/s.
+ Optional. If not specified, for physical interfaces, the
+ default is the link rate. For other interfaces or if the
+ link rate cannot be determined, the default is currently 100
+ 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.">
+ <p>A configuration for a port output queue, used in configuring Quality of
+ Service (QoS) features. May be referenced by <ref column="queues"
+ table="QoS"/> column in <ref table="QoS"/> table.</p>
+
+ <column name="other_config">
+ <p>Key-value pairs for configuring the output queue. The supported
+ key-value pairs and their meanings depend on the <ref column="type"/>
+ of the <ref column="QoS"/> records that reference this row.</p>
+ <p>The key-value pairs defined for <ref table="QoS"/> <ref table="QoS"
+ column="type"/> of <code>min-rate</code> are:</p>
+ <dl>
+ <dt><code>min-rate</code></dt>
+ <dd>Minimum guaranteed bandwidth, in bit/s. Required.</dd>
+ </dl>
+ <p>The key-value pairs defined for <ref table="QoS"/> <ref table="QoS"
+ column="type"/> of <code>linux-htb</code> are:</p>
+ <dl>
+ <dt><code>min-rate</code></dt>
+ <dd>Minimum guaranteed bandwidth, in bit/s. Required.</dd>
+ <dt><code>max-rate</code></dt>
+ <dd>Maximum allowed bandwidth, in bit/s. Optional. If specified, the
+ queue's rate will not be allowed to exceed the specified value, even
+ if excess bandwidth is available. If unspecified, defaults to no
+ limit.</dd>
+ <dt><code>burst</code></dt>
+ <dd>Burst size, in bits. This is the maximum amount of ``credits''
+ that a queue can accumulate while it is idle. Optional. Details of
+ the <code>linux-htb</code> implementation require a minimum burst
+ size, so a too-small <code>burst</code> will be silently
+ ignored.</dd>
+ <dt><code>priority</code></dt>
+ <dd>A nonnegative 32-bit integer. Defaults to 0 if
+ unspecified. A queue with a smaller <code>priority</code>
+ will receive all the excess bandwidth that it can use before
+ a queue with a larger value receives any. Specific priority
+ 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).">
<p>A port mirror within a <ref table="Bridge"/>.</p>
<p>A port mirror configures a bridge to send selected frames to special
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">
+ <p>Records in this table describe functionality supported by the hardware
+ and software platform on which this Open vSwitch is based. Clients
+ should not modify this table.</p>
+
+ <p>A record in this table is meaningful only if it is referenced by the
+ <ref table="Open_vSwitch" column="capabilities"/> column in the
+ <ref table="Open_vSwitch"/> table. The key used to reference it, called
+ the record's ``category,'' determines the meanings of the
+ <ref column="details"/> column. The following general forms of
+ categories are currently defined:</p>
+
+ <dl>
+ <dt><code>qos-<var>type</var></code></dt>
+ <dd><var>type</var> is supported as the value for
+ <ref column="type" table="QoS"/> in the <ref table="QoS"/> table.
+ </dd>
+ </dl>
+
+ <column name="details">
+ <p>Key-value pairs that describe capabilities. The meaning of the pairs
+ depends on the category key that the <ref table="Open_vSwitch"
+ column="capabilities"/> column in the <ref table="Open_vSwitch"/> table
+ uses to reference this record, as described above.</p>
+
+ <p>The presence of a record for category <code>qos-<var>type</var></code>
+ indicates that the switch supports <var>type</var> as the value of
+ the <ref table="QoS" column="type"/> column in the <ref table="QoS"/>
+ table. The following key-value pairs are defined to further describe
+ QoS capabilities:</p>
+
+ <dl>
+ <dt><code>n-queues</code></dt>
+ <dd>Number of supported queues, as a positive integer. Keys in the
+ <ref table="QoS" column="queues"/> column for <ref table="QoS"/>
+ records whose <ref table="QoS" column="type"/> value
+ equals <var>type</var> must range between 0 and this value minus one,
+ inclusive.</dd>
+ </dl>
+ </column>
</table>
</database>
git://git.onelab.eu / sliver-openvswitch.git / blobdiff