X-Git-Url: http://git.onelab.eu/?a=blobdiff_plain;f=vswitchd%2Fvswitch.xml;h=4cc29da03b7f975bc86c6cf27f0feadacf6e3a17;hb=e16a28b5854823e2d67099d49f7690235162b555;hp=b21b56004f06986571f5ca5c9f52e6648bad3cdf;hpb=8936565369410daa099708be4cd3fa7e0e39bade;p=sliver-openvswitch.git diff --git a/vswitchd/vswitch.xml b/vswitchd/vswitch.xml index b21b56004..4cc29da03 100644 --- a/vswitchd/vswitch.xml +++ b/vswitchd/vswitch.xml @@ -1,3 +1,4 @@ +

A database with this schema holds the configuration for one Open vSwitch daemon. The root of the configuration for the daemon is @@ -15,21 +16,28 @@ Set of bridges managed by the daemon. - - Default used by bridges. If a - record has a column, then this - is used instead. - - - - Remote database clients to which the Open vSwitch's database server - should connect or to which it should listen. - - SSL used globally by the daemon. + + + 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: +

+
system-id
+
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 + xs-system-uuid.
+
xs-system-uuid
+
The Citrix XenServer universally unique identifier for the + physical host as displayed by xe host-list.
+
+ @@ -42,9 +50,244 @@ Sequence number that Open vSwitch sets to the current value of - after it finishing applying a set of + after it finishes applying a set of configuration changes. + + + Describes functionality supported by the hardware and software platform + on which this Open vSwitch is based. Clients should not modify this + column. See the description for defined + capability categories and the meaning of associated + records. + + + +

+ Key-value pairs that report statistics about a system running an Open + vSwitch. These are updated periodically (currently, every 5 + seconds). Key-value pairs that cannot be determined or that do not + apply to a platform are omitted. +

+ +
+
cpu
+
+

+ Number of CPU processors, threads, or cores currently online and + available to the operating system on which Open vSwitch is + running, as an integer. This may be less than the number + installed, if some are not online or if they are not available to + the operating system. +

+

+ Open vSwitch userspace processes are not multithreaded, but the + Linux kernel-based datapath is. +

+
+ +
load_average
+
+

+ A comma-separated list of three floating-point numbers, + representing the system load average over the last 1, 5, and 15 + minutes, respectively. +

+
+ +
memory
+
+

+ A comma-separated list of integers, each of which represents a + quantity of memory in kilobytes that describes the operating + system on which Open vSwitch is running. In respective order, + these values are: +

+ +
    +
  1. Total amount of RAM allocated to the OS.
    2. +
  2. RAM allocated to the OS that is in use.
    3. +
  3. RAM that can be flushed out to disk or otherwise discarded + if that space is needed for another purpose. This number is + necessarily less than or equal to the previous value.
    4. +
  4. Total disk space allocated for swap.
    5. +
  5. Swap space currently in use.
    6. +
+ +

+ On Linux, all five values can be determined and are included. On + other operating systems, only the first two values can be + determined, so the list will only have two values. +

+
+ +
process_name
+
+

+ One such key-value pair will exist for each running Open vSwitch + daemon process, with name replaced by the daemon's + name (e.g. process_ovs-vswitchd). The value is a + comma-separated list of integers. The integers represent the + following, with memory measured in kilobytes and durations in + milliseconds: +

+ +
    +
  1. The process's virtual memory size.
    2. +
  2. The process's resident set size.
    3. +
  3. The amount of user and system CPU time consumed by the + process.
    4. +
  4. The number of times that the process has crashed and been + automatically restarted by the monitor.
    5. +
  5. The duration since the process was started.
    6. +
  6. The duration for which the process has been running.
    7. +
+ +

+ The interpretation of some of these values depends on whether the + process was started with the . If it + was not, then the crash count will always be 0 and the two + durations will always be the same. If + was given, then the crash count may be positive; if it is, the + latter duration is the amount of time since the most recent crash + and restart. +

+ +

+ There will be one key-value pair for each file in Open vSwitch's + ``run directory'' (usually /var/run/openvswitch) + whose name ends in .pid, whose contents are a + process ID, and which is locked by a running process. The + name is taken from the pidfile's name. +

+ +

+ Currently Open vSwitch is only able to obtain all of the above + detail on Linux systems. On other systems, the same key-value + pairs will be present but the values will always be the empty + string. +

+
+ +
file_systems
+
+

+ A space-separated list of information on local, writable file + systems. Each item in the list describes one file system and + consists in turn of a comma-separated list of the following: +

+ +
    +
  1. Mount point, e.g. / or /var/log. + Any spaces or commas in the mount point are replaced by + underscores.
    2. +
  2. Total size, in kilobytes, as an integer.
    3. +
  3. Amount of storage in use, in kilobytes, as an integer.
    4. +
+ +

+ This key-value pair is omitted if there are no local, writable + file systems or if Open vSwitch cannot obtain the needed + information. +

+
+
+ + + + +

+ These columns report the types and versions of the hardware and + software running Open vSwitch. We recommend in general that software + should test whether specific features are supported instead of relying + on version number checks. These values are primarily intended for + reporting to human administrators. +

+ + + The Open vSwitch version number, e.g. 1.1.0pre2. + If Open vSwitch was configured with a build number, then it is + also included, e.g. 1.1.0pre2+build4948. + + + +

+ The database schema version number in the form + major.minor.tweak, + e.g. 1.2.3. Whenever the database schema is changed in + a non-backward compatible way (e.g. deleting a column or a table), + major is incremented. When the database schema is changed + in a backward compatible way (e.g. adding a new column), + minor is incremented. When the database schema is changed + cosmetically (e.g. reindenting its syntax), tweak is + incremented. +

+ +

+ The schema version is part of the database schema, so it can also be + retrieved by fetching the schema using the Open vSwitch database + protocol. +

+ + + +

+ An identifier for the type of system on top of which Open vSwitch + runs, e.g. XenServer or KVM. +

+

+ System integrators are responsible for choosing and setting an + appropriate value for this column. +

+ + + +

+ The version of the system identified by , + e.g. 5.5.0-24648p on XenServer 5.5.0 build 24648. +

+

+ System integrators are responsible for choosing and setting an + appropriate value for this column. +

+ + + + + +

+ These columns primarily configure the Open vSwitch database + (ovsdb-server), not the Open vSwitch switch + (ovs-vswitchd). The OVSDB database also uses the settings. +

+ +

+ The Open vSwitch switch does read the database configuration to + determine remote IP addresses to which in-band control should apply. +

+ + + Database clients to which the Open vSwitch database server should + connect or to which it should listen, along with options for how these + connection should be configured. See the table + for more information. + + + +

+ Remote database clients to which the Open vSwitch's database server + should connect or to which it should listen. Adding an OVSDB target + to this set is equivalent to adding it to with all of the default options. +

+ +

+ Use of this column is deprecated and may be removed sometime in the + future. New applications should use and set instead. +

+ @@ -93,14 +336,47 @@ - OpenFlow controller. If unset, defaults to that specified by - in the - table. If the default is also unset, then - no OpenFlow controller will be used. + OpenFlow controller set. If unset, then no OpenFlow controllers + will be used. + + + +

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: +

+
standalone
+
If no message is received from the controller for three + times the inactivity probe interval + (see ), 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.
+
secure
+
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.
+
+

+

If this value is unset, the default is implementation-specific.

+

When more than one controller is configured, + is considered only when none of the + configured controllers can be contacted.

 - Reports the OpenFlow datapath ID in use. Exactly 12 hex digits. + Reports the OpenFlow datapath ID in use. Exactly 16 hex + digits. (Setting this column will have no useful effect. Set + :other-config + instead.) @@ -112,15 +388,21 @@ - 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:
+
bridge-id
+
A unique identifier of the bridge. On Citrix XenServer this + will commonly be the same as xs-network-uuids.
xs-network-uuids
-
Space-delimited set of the Citrix XenServer network UUIDs with - which this bridge is associated.
-
xs-network-names
-
Semicolon-delimited set of Citrix XenServer network names with - which this bridge is associated.
+
Semicolon-delimited set of universally unique identifier(s) for + 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., xe network-list.
 @@ -129,14 +411,25 @@ features. The currently defined key-value pairs are:
datapath-id
-
Exactly 12 hex +
Exactly 16 hex digits to set the OpenFlow datapath ID to a specific - value.
+ value. May not be all-zero. +
disable-in-band
+
If set to true, disable in-band control on + the bridge regardless of controller and manager settings.
hwaddr
-
Exactly 12 hex digits in the form +
An Ethernet address in the form xx:xx:xx:xx:xx:xx to set the hardware address of the local port and influence the datapath ID.
+
in-band-queue
+
+ A queue ID as a nonnegative integer. This sets the OpenFlow queue + ID that will be used by flows set up by in-band control on this + bridge. If unset, or if the port used by an in-band control flow + does not have QoS configured, or if the port does not have a queue + with the specified ID, the default queue is used instead. +
@@ -145,7 +438,7 @@

A port within a .

Most commonly, a port has exactly one ``interface,'' pointed to by its - column. Such a port logically + column. Such a port logically corresponds to a port on a physical Ethernet switch. A port with more than one interface is a ``bonded port'' (see ).

@@ -168,37 +461,48 @@

A bridge port must be configured for VLANs in one of two mutually exclusive ways:

If and are both nonempty, the configuration is ill-formed.

-

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 value. Frames forwarded - to this port will not have an 802.1Q header.

-

When a frame with a 802.1Q header that indicates a nonzero VLAN is - received on an implicit VLAN port, it is discarded.

-

Must be empty if this is a trunk port.

+

+ If this is an access port (see above), the port's implicitly + tagged VLAN. Must be empty if this is a trunk port. +

+

+ Frames arriving on trunk ports will be forwarded to this + port only if they are tagged with the given VLAN (or, if + 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 + value. Frames forwarded to this port will not have an + 802.1Q header. +

+

+ When a frame with a 802.1Q header that indicates a nonzero + VLAN is received on an access port, it is discarded. +

-

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 0 is included, then frames without an 802.1Q - header are also accepted.

-

Must be empty unless this is a trunk port.

+

+ 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. +

+

+ 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. +

@@ -206,11 +510,10 @@

A port that has more than one interface is a ``bonded port.'' Bonding allows for load balancing and fail-over. Open vSwitch supports ``source load balancing'' (SLB) bonding, which - assigns flows to slaves based on source MAC address, with - periodic rebalancing as traffic patterns change. This form of - bonding does not require 802.3ad or other special support from - the upstream switch to which the slave devices are - connected.

+ assigns flows to slaves based on source MAC address and output VLAN, + with periodic rebalancing as traffic patterns change. This form of + bonding does not require 802.3ad or other special support from the + upstream switch to which the slave devices are connected.

These columns apply only to bonded ports. Their values are otherwise ignored.

@@ -227,17 +530,21 @@ For a bonded port, the number of milliseconds for which carrier must stay down on an interface before the interface is considered to be - down. Specify 0 to enable the interface immediately. + down. Specify 0 to disable the interface immediately. - For a bonded port, whether to create a fake interface with the name of - the port. Use only for compatibility with legacy software that + For a bonded port, whether to create a fake internal interface with the + name of the port. Use only for compatibility with legacy software that requires this. + + Quality of Service configuration for this port. + + 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 @@ -251,12 +558,21 @@ - Key-value pairs that identify this port's role in external systems. No - key-value pairs native to are currently defined. - For fake bridges (see the column), external - IDs for the fake bridge are defined here by prefixing their keys - with fake-bridge-, - e.g. fake-bridge-xs-network-uuids. +

+ 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 key-value pairs native to are currently + defined. For fake bridges (see the + column), external IDs for the fake bridge are defined here by + prefixing a key with fake-bridge-, + e.g. fake-bridge-xs-network-uuids. +

@@ -264,8 +580,15 @@ currently defined key-value pairs are:
hwaddr
-
Exactly 12 hex digits in the form +
An Ethernet address in the form xx:xx:xx:xx:xx:xx.
+
bond-rebalance-interval
+
For a bonded port, the number of milliseconds between + successive attempts to rebalance the bond, that is, to + move source MACs and their flows from one interface on + the bond to another in an attempt to keep usage of each + interface roughly equal. The default is 10000 (10 + seconds), and the minimum is 1000 (1 second).
 @@ -293,7 +616,7 @@ whose name is first in alphabetical order). Internal ports and bridge ports that are used as port mirroring destinations (see the table) are ignored. -
  • For other internal interface, the default MAC is randomly +
  • For other internal interfaces, the default MAC is randomly generated.
  • External interfaces typically have a MAC address associated with their hardware.
    • @@ -310,10 +633,10 @@

    Open vSwitch populates this column when the port number becomes known. If the interface is successfully added, will be set to a number between 1 and 65535 - (generally either in the range 1 to 0xff00, exclusive, - or 0xfffe, the port number for the OpenFlow ``local - port''). If the interface cannot be added then Open vSwitch sets - this column to -1.

    + (generally either in the range 1 to 65279, inclusive, or 65534, the + port number for the OpenFlow ``local port''). If the interface + cannot be added then Open vSwitch sets this column + to -1.

    @@ -328,7 +651,7 @@ vSwitch is running. The empty string is a synonym for system.
    internal
    -
    A simulated network devices that sent and receive traffic. An +
    A simulated network device that sends and receives traffic. An internal interface whose is the same as its bridge's is called the ``local interface.'' It does not make sense to bond an internal @@ -337,7 +660,281 @@
    tap
    A TUN/TAP device managed by Open vSwitch.
    gre
    -
    A GRE tunnel device managed by Open vSwitch.
    +
    An Ethernet over RFC 2890 Generic Routing Encapsulation over IPv4 + tunnel. Each tunnel must be uniquely identified by the + combination of remote_ip, local_ip, and + in_key. 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. in_key + is considered more specific than local_ip if a port + defines one and another port defines the other. The following + options may be specified in the column: +
    +
    remote_ip
    +
    Required. The tunnel endpoint.
    +
    +
    +
    local_ip
    +
    Optional. The destination IP that received packets must + match. Default is to match all addresses.
    +
    +
    +
    in_key
    +
    Optional. The GRE key that received packets must contain. + It may either be a 32-bit number (no key and a key of 0 are + treated as equivalent) or the word flow. If + flow is specified then any key will be accepted + and the key will be placed in the tun_id field + for matching in the flow table. The ovs-ofctl manual page + contains additional information about matching fields in + OpenFlow flows. Default is no key.
    +
    +
    +
    out_key
    +
    Optional. The GRE key to be set on outgoing packets. It may + either be a 32-bit number or the word flow. If + flow is specified then the key may be set using + the set_tunnel Nicira OpenFlow vendor extension (0 + 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.
    +
    +
    +
    key
    +
    Optional. Shorthand to set in_key and + out_key at the same time.
    +
    +
    +
    tos
    +
    Optional. The value of the ToS bits to be set on the + encapsulating packet. It may also be the word + inherit, 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.
    +
    +
    +
    ttl
    +
    Optional. The TTL to be set on the encapsulating packet. + It may also be the word inherit, 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.
    +
    +
    +
    csum
    +
    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 true to enable.
    +
    +
    +
    pmtud
    +
    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 false to disable.
    +
    +
    +
    header_cache
    +
    Optional. Enable caching of tunnel headers and the output + path. This can lead to a significant performance increase + without changing behavior. In general it should not be + necessary to adjust this setting. However, the caching can + bypass certain components of the IP stack (such as IP tables) + and it may be useful to disable it if these features are + required or as a debugging measure. Default is enabled, set to + false to disable.
    +
    +
    +
    ipsec_gre
    +
    An Ethernet over RFC 2890 Generic Routing Encapsulation over + IPv4 IPsec tunnel. Each tunnel (including those of type + gre) must be uniquely identified by the + combination of remote_ip and + local_ip. 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. + The following options may be specified in the + column: +
    +
    remote_ip
    +
    Required. The tunnel endpoint.
    +
    +
    +
    local_ip
    +
    Optional. The destination IP that received packets must + match. Default is to match all addresses.
    +
    +
    +
    ipsec_psk
    +
    Required. Specifies a pre-shared key for authentication + that must be identical on both sides of the tunnel.
    +
    +
    +
    in_key
    +
    Optional. The GRE key that received packets must contain. + It may either be a 32-bit number (no key and a key of 0 are + treated as equivalent) or the word flow. If + flow is specified then any key will be accepted + and the key will be placed in the tun_id field + for matching in the flow table. The ovs-ofctl manual page + contains additional information about matching fields in + OpenFlow flows. Default is no key.
    +
    +
    +
    out_key
    +
    Optional. The GRE key to be set on outgoing packets. It may + either be a 32-bit number or the word flow. If + flow is specified then the key may be set using + the set_tunnel Nicira OpenFlow vendor extension (0 + 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.
    +
    +
    +
    key
    +
    Optional. Shorthand to set in_key and + out_key at the same time.
    +
    +
    +
    tos
    +
    Optional. The value of the ToS bits to be set on the + encapsulating packet. It may also be the word + inherit, 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.
    +
    +
    +
    ttl
    +
    Optional. The TTL to be set on the encapsulating packet. + It may also be the word inherit, 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.
    +
    +
    +
    csum
    +
    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 true to enable.
    +
    +
    +
    pmtud
    +
    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 false to disable.
    +
    +
    +
    capwap
    +
    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 remote_ip and + local_ip. If two ports are defined that are the same + except one includes local_ip 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 column: +
    +
    remote_ip
    +
    Required. The tunnel endpoint.
    +
    +
    +
    local_ip
    +
    Optional. The destination IP that received packets must + match. Default is to match all addresses.
    +
    +
    +
    tos
    +
    Optional. The value of the ToS bits to be set on the + encapsulating packet. It may also be the word + inherit, 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.
    +
    +
    +
    ttl
    +
    Optional. The TTL to be set on the encapsulating packet. + It may also be the word inherit, 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.
    +
    +
    +
    pmtud
    +
    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 false to disable.
    +
    +
    +
    header_cache
    +
    Optional. Enable caching of tunnel headers and the output + path. This can lead to a significant performance increase + without changing behavior. In general it should not be + necessary to adjust this setting. However, the caching can + bypass certain components of the IP stack (such as IP tables) + and it may be useful to disable it if these features are + required or as a debugging measure. Default is enabled, set to + false to disable.
    +
    +
    +
    patch
    +
    +

    + A pair of virtual devices that act as a patch cable. The column must have the following key-value pair: +

    +
    +
    peer
    +
    + The of the for + the other side of the patch. The named 's own peer option must specify + this 's name. That is, the two patch + interfaces must have reversed and + peer values. +
    +
    +
    @@ -345,49 +942,425 @@ Configuration options whose interpretation varies based on . + + +

    + Key-value pairs that report port status. Supported status + values are type-dependent. +

    +

    The only currently defined key-value pair is:

    +
    +
    source_ip
    +
    The source IP address used for an IPv4 tunnel end-point, + such as gre or capwap. Not + supported by all implementations.
    +
    +     +

    + These settings control ingress policing for packets received on this + interface. On a physical interface, this limits the rate at which + traffic is allowed into the system from the outside; on a virtual + interface (one connected to a virtual machine), this limits the rate at + which the VM is able to transmit. +

    +

    + Policing is a simple form of quality-of-service that simply drops + packets received in excess of the configured rate. Due to its + simplicity, policing is usually less accurate and less effective than + egress QoS (which is configured using the and tables). +

    +

    + Policing is currently implemented only on Linux. The Linux + implementation uses a simple ``token bucket'' approach: +

    +
      +
    • + The size of the bucket corresponds to . Initially the bucket is full. +
      • +
    • + Whenever a packet is received, its size (converted to tokens) is + compared to the number of tokens currently in the bucket. If the + required number of tokens are available, they are removed and the + packet is forwarded. Otherwise, the packet is dropped. +
      • +
    • + Whenever it is not full, the bucket is refilled with tokens at the + rate specified by . +
      • +
    +

    + Policing interacts badly with some network protocols, and especially + with fragmented IP packets. Suppose that there is enough network + activity to keep the bucket nearly empty all the time. Then this token + bucket algorithm will forward a single packet every so often, with the + period depending on packet size and on the configured rate. All of the + fragments of an IP packets are normally transmitted back-to-back, as a + group. In such a situation, therefore, only one of these fragments + will be forwarded and the rest will be dropped. IP does not provide + any way for the intended recipient to ask for only the remaining + fragments. In such a case there are two likely possibilities for what + will happen next: either all of the fragments will eventually be + retransmitted (as TCP will do), in which case the same problem will + recur, or the sender will not realize that its packet has been dropped + and data will simply be lost (as some UDP-based protocols will do). + Either way, it is possible that no forward progress will ever occur. +

    + +

    + Maximum rate for data received on this interface, in kbps. Data + received faster than this rate is dropped. Set to 0 + (the default) to disable policing. +

    +     +

    Maximum burst size for data received on this interface, in kb. The default burst size if set to 0 is 1000 kb. This value has no effect if is 0.

    -

    The burst size should be at least the size of the interface's - MTU.

    -     - - -

    Maximum rate for data received on this interface, in kbps. Data - received faster than this rate is dropped. Set to 0 to - disable policing.

    -

    The meaning of ``ingress'' is from Open vSwitch's perspective. If - configured on a physical interface, then it limits the rate at which - traffic is allowed into the system from the outside. If configured - on a virtual interface that is connected to a virtual machine, then - it limits the rate at which the guest is able to transmit.

    +

    + Specifying a larger burst size lets the algorithm be more forgiving, + which is important for protocols like TCP that react severely to + dropped packets. The burst size should be at least the size of the + interface's MTU. Specifying a value that is numerically at least as + large as 10% of helps TCP come + closer to achieving the full rate. +

    + + + Connectivity monitor configuration for this interface. + + - Key-value pairs that identify this interface'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: +
    +
    attached-mac
    +
    + The MAC address programmed into the ``virtual hardware'' for this + interface, in the form + xx:xx:xx:xx:xx:xx. + For Citrix XenServer, this is the value of the MAC + field in the VIF record for this interface.
    +
    iface-id
    +
    A system-unique identifier for the interface. On XenServer, + this will commonly be the same as xs-vif-uuid.
    +
    +

    + 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 -uuid 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. +

    +

    The currently defined key-value pairs for XenServer are:

    xs-vif-uuid
    -
    UUID of the Citrix XenServer VIF associated with this - interface
    +
    The virtual interface associated with this interface.
    xs-network-uuid
    -
    UUID of the Citrix XenServer network to which this interface is - attached
    -
    xs-vif-vm-uuid
    -
    UUID of the Citrix XenServer VM to which this interface - belongs
    -
    xs-vif-mac
    -
    The value of the "MAC" field in the Citrix XenServer VIF record - for this interface.
    +
    The virtual network to which this interface is attached.
    +
    xs-vm-uuid
    +
    The VM to which this interface belongs.
     + + + Key-value pairs for rarely used interface features. Currently, + there are none defined. + + + +

    + 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 select 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.

    +

    + The currently defined key-value pairs are listed below. These are + the same statistics reported by OpenFlow in its struct + ofp_port_stats structure. If an interface does not support a + given statistic, then that pair is omitted.

    +
      +
    • + Successful transmit and receive counters: +
      +
      rx_packets
      +
      Number of received packets.
      +
      rx_bytes
      +
      Number of received bytes.
      +
      tx_packets
      +
      Number of transmitted packets.
      +
      tx_bytes
      +
      Number of transmitted bytes.
      +
      +
      • +
    • + Receive errors: +
      +
      rx_dropped
      +
      Number of packets dropped by RX.
      +
      rx_frame_err
      +
      Number of frame alignment errors.
      +
      rx_over_err
      +
      Number of packets with RX overrun.
      +
      rx_crc_err
      +
      Number of CRC errors.
      +
      rx_errors
      +
      + Total number of receive errors, greater than or equal + to the sum of the above. +
      +
      +
      • +
    • + Transmit errors: +
      +
      tx_dropped
      +
      Number of packets dropped by TX.
      +
      collisions
      +
      Number of collisions.
      +
      tx_errors
      +
      + Total number of transmit errors, greater + than or equal to the sum of the above. +
      +
      +
      • +
    +     +     +
    + + +

    Quality of Service (QoS) configuration for each Port that + references it.

    + + +

    The type of QoS to implement. The column in the table + identifies the types that a switch actually supports. The currently + defined types are listed below:

    +
    +
    linux-htb
    +
    + Linux ``hierarchy token bucket'' classifier. See tc-htb(8) (also at + http://linux.die.net/man/8/tc-htb) and the HTB manual + (http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm) + for information on how this classifier works and how to configure it. +
    +
    +
    +
    linux-hfsc
    +
    + Linux "Hierarchical Fair Service Curve" classifier. + See http://linux-ip.net/articles/hfsc.en/ for + information on how this classifier works. +
    +
    +     + + +

    A map from queue numbers to records. The + supported range of queue numbers depend on . The + queue numbers are the same as the queue_id used in + OpenFlow in struct ofp_action_enqueue and other + structures. Queue 0 is used by OpenFlow output actions that do not + specify a specific queue.

    +     + + +

    Key-value pairs for configuring QoS features that depend on + .

    +

    The linux-htb and linux-hfsc classes support + the following key-value pairs:

    +
    +
    max-rate
    +
    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.
    +
    +     + + + 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. + +
    + + +

    A configuration for a port output queue, used in configuring Quality of + Service (QoS) features. May be referenced by column in table.

    + + +

    Key-value pairs for configuring the output queue. The supported + key-value pairs and their meanings depend on the + of the records that reference this row.

    +

    The key-value pairs defined for of min-rate are:

    +
    +
    min-rate
    +
    Minimum guaranteed bandwidth, in bit/s. Required. The + floor value is 1500 bytes/s (12,000 bit/s).
    +
    +

    The key-value pairs defined for of linux-htb are:

    +
    +
    min-rate
    +
    Minimum guaranteed bandwidth, in bit/s. Required.
    +
    max-rate
    +
    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.
    +
    burst
    +
    Burst size, in bits. This is the maximum amount of ``credits'' + that a queue can accumulate while it is idle. Optional. Details of + the linux-htb implementation require a minimum burst + size, so a too-small burst will be silently + ignored.
    +
    priority
    +
    A nonnegative 32-bit integer. Defaults to 0 if + unspecified. A queue with a smaller priority + 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.
    +
    +

    The key-value pairs defined for of linux-hfsc are:

    +
    +
    min-rate
    +
    Minimum guaranteed bandwidth, in bit/s. Required.
    +
    max-rate
    +
    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.
    +
    +     + + + 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. + +
    + + +

    + A attaches to an to + implement 802.1ag Connectivity Fault Management (CFM). CFM allows a + group of Maintenance Points (MPs) called a Maintenance Association (MA) + to detect connectivity problems with each other. MPs within a MA should + have complete and exclusive interconnectivity. This is verified by + occasionally broadcasting Continuity Check Messages (CCMs) at a + configurable transmission interval. A is + responsible for collecting data about other MPs in its MA and + broadcasting CCMs. +

    + + + + A Maintenance Point ID (MPID) uniquely identifies each endpoint within + a Maintenance Association (see ). The MPID is + used to identify this to other endpoints in the + MA. + + + + A set of which this + should have connectivity to. If this + does not have connectivity to any MPs in this + set, or has connectivity to any MPs not in this set, a fault is + signaled. + + + + A Maintenance Association (MA) name pairs with a Maintenance Domain + (MD) name to uniquely identify a MA. A MA is a group of endpoints who + have complete and exclusive interconnectivity. Defaults to + ovs if unset. + + + + A Maintenance Domain name pairs with a Maintenance Association name to + uniquely identify a MA. Defaults to ovs if unset. + + + + The transmission interval of CCMs in milliseconds. Three missed CCMs + indicate a connectivity fault. Defaults to 1000ms. + + + + + + A set of MPIDs representing MPs to which this + has detected connectivity that are not in the + set. This should not + have connectivity to any MPs not listed in . + Thus, if this set is non-empty a fault is indicated. + + + + A set of MAIDs representing foreign Maintenance Associations (MAs) + which this has detected connectivity to. A + should not have connectivity to a Maintenance + Association other than its own. Thus, if this set is non-empty a fault + is indicated. + + + + Indicates a Connectivity Fault caused by a configuration error, a down + remote MP, or unexpected connectivity to a remote MAID or remote MP. + + +
    + + +

    + A represents a MP which a + has or should have connectivity to. +

    + + + + A Maintenance Point ID (MPID) uniquely identifies each endpoint within + a Maintenance Association. All MPs within a MA should have a unique + MPID. + + + + + + Indicates a connectivity fault. +
    @@ -403,14 +1376,17 @@ + + If true, every packet arriving or departing on any port is + selected for mirroring. + + Ports on which departing packets are selected for mirroring. - Ports on which arriving packets are selected for mirroring. If this - column and are both empty, then all - packets on all ports are selected for mirroring. + Ports on which arriving packets are selected for mirroring. @@ -467,24 +1443,95 @@ in the appropriate table or tables.

         + + + + 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. + + - An OpenFlow controller. +

    An OpenFlow controller.

    + +

    + Open vSwitch supports two kinds of OpenFlow controllers: +

    + +
    +
    Primary controllers
    +
    +

    + 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. +

    + +

    + Open vSwitch initiates and maintains persistent connections to + primary controllers, retrying the connection each time it fails or + drops. The column in the + table applies to primary controllers. +

    + +

    + 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 NXT_ROLE OpenFlow + vendor extension may be useful for this.) +

    +
    +
    Service controllers
    +
    +

    + These kinds of OpenFlow controller connections are intended for + occasional support and maintenance use, e.g. with + ovs-ofctl. Usually a service controller connects only + briefly to inspect or modify some of a switch's state. +

    + +

    + Open vSwitch listens for incoming connections from service + controllers. The service controllers initiate and, if necessary, + maintain the connections from their end. The column in the table does + not apply to service controllers. +

    + +

    + Open vSwitch supports configuring any number of service controllers. +

    +
    +
    + +

    + The determines the type of controller. +

    - Connection method for controller. - The following connection methods are currently - supported: +

    Connection method for controller.

    +

    + The following connection methods are currently supported for primary + controllers: +

    ssl:ip[:port]

    The specified SSL port (default: 6633) on the host at - the given ip, which must be expressed as an IP address - (not a DNS name). The - column in the must point to a valid - SSL configuration when this form is used.

    + the given ip, which must be expressed as an IP address + (not a DNS name). The + column in the table must point to a + valid SSL configuration when this form is used.

    SSL support is an optional feature that is not always built as part of Open vSwitch.

    @@ -493,15 +1540,85 @@ the given ip, which must be expressed as an IP address (not a DNS name).
    discover
    -
    Enables controller discovery.
    -
    none
    -
    Disables the controller.
    +
    +

    Enables controller discovery.

    +

    In controller discovery mode, Open vSwitch broadcasts a DHCP + request with vendor class identifier OpenFlow across + all of the bridge's network devices. It will accept any valid + DHCP reply that has the same vendor class identifier and includes + a vendor-specific option with code 1 whose contents are a string + specifying the location of the controller in the same format as + .

    +

    The DHCP reply may also, optionally, include a vendor-specific + option with code 2 whose contents are a string specifying the URI + to the base of the OpenFlow PKI + (e.g. http://192.168.0.1/openflow/pki). This URI is + used only for bootstrapping the OpenFlow PKI at initial switch + setup; ovs-vswitchd does not use it at all.

    +
    +

    + The following connection methods are currently supported for service + controllers: +

    +
    +
    pssl:[port][:ip]
    +
    +

    + Listens for SSL connections on the specified TCP port + (default: 6633). If ip, which must be expressed as an + IP address (not a DNS name), is specified, then connections are + restricted to the specified local IP address. +

    +

    + The column in the table must point to a valid SSL + configuration when this form is used. +

    +

    SSL support is an optional feature that is not always built as + part of Open vSwitch.

    +
    +
    ptcp:[port][:ip]
    +
    + Listens for connections on the specified TCP port + (default: 6633). If ip, which must be expressed as an + IP address (not a DNS name), is specified, then connections are + restricted to the specified local IP address. +
    +
    +

    When multiple controllers are configured for a single bridge, the + values must be unique. Duplicate + values yield unspecified results.

     - Either in-band or out-of-band. If not - specified, the default is implementation-specific. +

    If it is specified, this setting must be one of the following + strings that describes how Open vSwitch contacts this OpenFlow + controller over the network:

    + +
    +
    in-band
    +
    In this mode, this controller's OpenFlow traffic travels over the + bridge associated with the controller. With this setting, Open + vSwitch allows traffic to and from the controller regardless of the + contents of the OpenFlow flow table. (Otherwise, Open vSwitch + would never be able to connect to the controller, because it did + not have a flow to enable it.) This is the most common connection + mode because it is not necessary to maintain two independent + networks.
    +
    out-of-band
    +
    In this mode, OpenFlow traffic uses a control network separate + from the bridge associated with this controller, that is, the + bridge does not use any of its own network devices to communicate + with the controller. The control network must be configured + separately, before or after ovs-vswitchd is started. +
    +
    + +

    If not specified, the default is implementation-specific. If + is discover, the connection mode + is always treated as in-band regardless of the actual + setting.

         @@ -520,45 +1637,9 @@ assumes the connection has been broken and attempts to reconnect. Default is implementation-specific. - - -

    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: -

    -
    standalone
    -
    If no message is received from the controller for three - times the inactivity probe interval - (see ), then Open vSwitch - will take over responsibility for setting up flows. In - this mode, Open vSwitch causes the datapath 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.
    -
    secure
    -
    Open vSwitch will not set up flows on its own when the - controller connection fails. It will continue retry - connecting to the controller forever.
    -
    -

    -

    If this value is unset, the default is - implementation-specific.

    -     - - In conjunction with , - the maximum number of unused packet credits that the bridge will - allow to accumulate, in packets. If not specified, the default - is implementation-specific. - -

    The maximum rate at which packets in unknown flows will be forwarded to the OpenFlow controller, in packets per second. This @@ -578,11 +1659,21 @@ actual rate that packets are sent to the controller is up to twice the specified rate.

     + + + In conjunction with , + the maximum number of unused packet credits that the bridge will + allow to accumulate, in packets. If not specified, the default + is implementation-specific. +     - + +

    These values are considered only when + is discover.

    + - If is discover, a POSIX + A POSIX extended regular expression against which the discovered controller location is validated. The regular expression is implicitly anchored at the beginning of the controller location string, as @@ -591,8 +1682,7 @@ - If is discover, - whether to update /etc/resolv.conf when the + Whether to update /etc/resolv.conf when the controller is discovered. If not specified, the default is implementation-specific. Open vSwitch will only modify /etc/resolv.conf if the DHCP response that it receives @@ -600,20 +1690,184 @@     - - - If is not discover, the IP - address of the gateway to configure on the local port. - + +

    These values are considered only in in-band control mode (see + ) and only when + is not discover. (For controller discovery, the network + configuration obtained via DHCP is used instead.)

    + +

    When multiple controllers are configured on a single bridge, there + should be only one set of unique values in these columns. If different + values are set for these columns in different controllers, the effect + is unspecified.

    - If is not discover, the IP - address to configure on the local port. + The IP address to configure on the local port, + e.g. 192.168.0.123. If this value is unset, then + and are + ignored. - If is not discover, the IP - netmask to configure on the local port. + The IP netmask to configure on the local port, + e.g. 255.255.255.0. If is set + but this value is unset, then the default is chosen based on whether + the IP address is class A, B, or C. + + + + The IP address of the gateway to configure on the local port, as a + string, e.g. 192.168.0.1. Leave this column unset if + this network has no gateway. + +     + + + + 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. + + +
    + + +

    + Configuration for a database connection to an Open vSwitch database + (OVSDB) client. +

    + +

    + This table primarily configures the Open vSwitch database + (ovsdb-server), not the Open vSwitch switch + (ovs-vswitchd). The switch does read the table to determine + what connections should be treated as in-band. +

    + +

    + The Open vSwitch database server can initiate and maintain active + connections to remote clients. It can also listen for database + connections. +

    + + + +

    Connection method for managers.

    +

    + The following connection methods are currently supported: +

    +
    +
    ssl:ip[:port]
    +
    +

    + The specified SSL port (default: 6632) on the host at + the given ip, which must be expressed as an IP address + (not a DNS name). The + column in the table must point to a + valid SSL configuration when this form is used. +

    +

    + SSL support is an optional feature that is not always built as + part of Open vSwitch. +

    +
    + +
    tcp:ip[:port]
    +
    + The specified TCP port (default: 6632) on the host at + the given ip, which must be expressed as an IP address + (not a DNS name). +
    +
    pssl:[port][:ip]
    +
    +

    + Listens for SSL connections on the specified TCP port + (default: 6632). If ip, which must be expressed as an + IP address (not a DNS name), is specified, then connections are + restricted to the specified local IP address. +

    +

    + The column in the table must point to a valid SSL + configuration when this form is used. +

    +

    + SSL support is an optional feature that is not always built as + part of Open vSwitch. +

    +
    +
    ptcp:[port][:ip]
    +
    + Listens for connections on the specified TCP port + (default: 6632). If ip, which must be expressed as an + IP address (not a DNS name), is specified, then connections are + restricted to the specified local IP address. +
    +
    +

    When multiple managers are configured, the + values must be unique. Duplicate values yield + unspecified results.

    +     + + +

    + If it is specified, this setting must be one of the following strings + that describes how Open vSwitch contacts this OVSDB client over the + network: +

    + +
    +
    in-band
    +
    + In this mode, this connection's traffic travels over a bridge + managed by Open vSwitch. With this setting, Open vSwitch allows + traffic to and from the client regardless of the contents of the + OpenFlow flow table. (Otherwise, Open vSwitch would never be able + to connect to the client, because it did not have a flow to enable + it.) This is the most common connection mode because it is not + necessary to maintain two independent networks. +
    +
    out-of-band
    +
    + In this mode, the client's traffic uses a control network separate + from that managed by Open vSwitch, that is, Open vSwitch does not + use any of its own network devices to communicate with the client. + The control network must be configured separately, before or after + ovs-vswitchd is started. +
    +
    + +

    + If not specified, the default is implementation-specific. +

    +     +     + + + + Maximum number of milliseconds to wait between connection attempts. + Default is implementation-specific. + + + + Maximum number of milliseconds of idle time on connection to the client + before sending an inactivity probe message. If Open vSwitch does not + communicate with the client for the specified number of seconds, it + will send a probe. If a response is not received for the same + additional amount of time, Open vSwitch assumes the connection has been + broken and attempts to reconnect. Default is implementation-specific. + + + + + + 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.
    @@ -657,6 +1911,14 @@ disambiguate the traffic.

    When this option is enabled, a maximum of 508 ports are supported.

    + + + 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. + @@ -689,6 +1951,14 @@ SSL connection to a man-in-the-middle attack obtaining the initial CA certificate. It may still be useful for bootstrapping. + + + 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. +
    @@ -696,10 +1966,11 @@ of switches.

    - IP address to report as ``agent address'' to collectors. If not - specified, defaults to the in - the collector's . If neither is specified, - sFlow is disabled. + Name of the network device whose IP address should be reported as the + ``agent address'' to collectors. If not specified, the IP address + defaults to the in the + collector's . If an agent IP address cannot be + determined either way, sFlow is disabled. @@ -722,5 +1993,55 @@ sFlow targets in the form ip:port. + + + 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. + +
    + + +

    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.

    + +

    A record in this table is meaningful only if it is referenced by the + column in the + table. The key used to reference it, called + the record's ``category,'' determines the meanings of the + column. The following general forms of + categories are currently defined:

    + +
    +
    qos-type
    +
    type is supported as the value for + in the table. +
    +
    + + +

    Key-value pairs that describe capabilities. The meaning of the pairs + depends on the category key that the column in the table + uses to reference this record, as described above.

    + +

    The presence of a record for category qos-type + indicates that the switch supports type as the value of + the column in the + table. The following key-value pairs are defined to further describe + QoS capabilities:

    + +
    +
    n-queues
    +
    Number of supported queues, as a positive integer. Keys in the + column for + records whose value + equals type must range between 0 and this value minus one, + inclusive.
    +
    +