X-Git-Url: http://git.onelab.eu/?a=blobdiff_plain;f=vswitchd%2Fvswitch.xml;h=7739793cfb13709a1272296c5a39d4dd6669e115;hb=c473936b9af693ad88907e739013f34d9c70860d;hp=53c2650d17246bc8506a06d9b7995a27a14cb920;hpb=6333182946ffd368eb7623d7408185a521058b46;p=sliver-openvswitch.git diff --git a/vswitchd/vswitch.xml b/vswitchd/vswitch.xml index 53c2650d1..7739793cf 100644 --- a/vswitchd/vswitch.xml +++ b/vswitchd/vswitch.xml @@ -1,15 +1,55 @@ -

A database with this schema holds the configuration for one Open - vSwitch daemon. The root of the configuration for the daemon is - the table, which must have exactly one +

+ A database with this schema holds the configuration for one Open + vSwitch daemon. The top-level configuration for the daemon is the + table, which must have exactly one record. Records in other tables are significant only when they - can be reached directly or indirectly from the - table.

+ can be reached directly or indirectly from the table. Records that are not reachable from + the table are automatically deleted + from the database, except for records in a few distinguished + ``root set'' tables. +

+ +

Common Columns

+ +

+ Most tables contain two special columns, named other_config + and external_ids. These columns have the same form and + purpose each place that they appear, so we describe them here to save space + later. +

+ +
+
other_config: map of string-string pairs
+
+

+ Key-value pairs for configuring rarely used features. Supported keys, + along with the forms taken by their values, are documented individually + for each table. +

+

+ A few tables do not have other_config columns because no + key-value pairs have yet been defined for them. +

+
+ +
external_ids: map of string-string pairs
+
+ 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. In some cases, where key-value pairs have been defined that are + likely to be widely useful, they are documented individually for each + table. +
+
- Configuration for an Open vSwitch daemon. There must be exactly one record - in the table. + Configuration for an Open vSwitch daemon. There must be exactly + one record in the table. @@ -20,23 +60,16 @@ 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.
-
+ + 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 + . + + + + The Citrix XenServer universally unique identifier for the physical + host as displayed by xe host-list. @@ -54,145 +87,139 @@ 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. + The statistics column contains 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. -

+ + Statistics are disabled by default to avoid overhead in the common + case when statistics gathering is not useful. Set this value to + true to enable populating the + column or to false to explicitly disable it. + -

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

+ +

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

+ -

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

-
+ + A comma-separated list of three floating-point numbers, + representing the system load average over the last 1, 5, and 15 + minutes, respectively. + -
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: -

+ +

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

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

+ One such key-value pair, with NAME replaced by + a process name, 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. +

+ -

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

-
-
- + +

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

+ + @@ -205,9 +232,9 @@

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

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

System integrators are responsible for choosing and setting an @@ -273,21 +300,14 @@ 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. -

+ + The overall purpose of these columns is described under Common + Columns at the beginning of this document. -

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

- + +
@@ -326,57 +346,154 @@ - VLAN IDs of VLANs on which MAC address learning should be disabled, so - that packets are flooded instead of being sent to specific ports that - are believed to contain packets' destination MACs. This should - ordinarily be used to disable MAC learning on VLANs used for mirroring - (RSPAN VLANs). It may also be useful for debugging. +

+ VLAN IDs of VLANs on which MAC address learning should be disabled, + so that packets are flooded instead of being sent to specific ports + that are believed to contain packets' destination MACs. This should + ordinarily be used to disable MAC learning on VLANs used for + mirroring (RSPAN VLANs). It may also be useful for debugging. +

+

+ SLB bonding (see the column in + the table) is incompatible with + flood_vlans. Consider using another bonding mode or + a different type of mirror instead. +

- OpenFlow controller set. If unset, then no OpenFlow controllers - will be used. +

+ OpenFlow controller set. If unset, then no OpenFlow controllers + will be used. +

+ +

+ If there are primary controllers, removing all of them clears the + flow table. If there are no primary controllers, adding one also + clears the flow table. Other changes to the set of controllers, such + as adding or removing a service controller, adding another primary + controller to supplement an existing primary controller, or removing + only one of two primary controllers, have no effect on the flow + table. +

+ + + + Configuration for OpenFlow tables. Each pair maps from an OpenFlow + table ID to configuration for that table.

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

+ is considered only when none of the + configured controllers can be contacted.

+

+ Changing when no primary controllers are + configured clears the flow table. +

- Reports the OpenFlow datapath ID in use. Exactly 16 hex - digits. (Setting this column will have no useful effect. Set - :other-config - instead.) + Reports the OpenFlow datapath ID in use. Exactly 16 hex digits. + (Setting this column has no useful effect. Set instead.) + + + + Exactly 16 hex digits to set the OpenFlow datapath ID to a specific + value. May not be all-zero. + + + + If set to true, disable in-band control on the bridge + regardless of controller and manager settings. + + + + 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. + + + + + The IEEE 802.1D Spanning Tree Protocol (STP) is a network protocol + that ensures loop-free topologies. It allows redundant links to + be included in the network to provide automatic backup paths if + the active links fails. + + + Enable spanning tree on the bridge. By default, STP is disabled + on bridges. Bond, internal, and mirror ports are not supported + and will not participate in the spanning tree. + + + + The bridge's STP identifier (the lower 48 bits of the bridge-id) + in the form + xx:xx:xx:xx:xx:xx. + By default, the identifier is the MAC address of the bridge. + + + + The bridge's relative priority value for determining the root + bridge (the upper 16 bits of the bridge-id). A bridge with the + lowest bridge-id is elected the root. By default, the priority + is 0x8000. + + + + The interval between transmissions of hello messages by + designated ports, in seconds. By default the hello interval is + 2 seconds. + + + + The maximum age of the information transmitted by the bridge + when it is the root bridge, in seconds. By default, the maximum + age is 20 seconds. + + + + The delay to wait between transitioning root and designated + ports to forwarding, in seconds. By default, the + forwarding delay is 15 seconds. @@ -387,63 +504,120 @@ type netdev. - - 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
-
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.
-
+ + A unique identifier of the bridge. On Citrix XenServer this will + commonly be the same as + . - - Key-value pairs for configuring rarely used bridge - features. The currently defined key-value pairs are: -
-
datapath-id
-
Exactly 16 hex - digits to set the OpenFlow datapath ID to a specific - 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
-
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. -
-
+ + 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. + + + + 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. + + + +

+ A number of flows as a nonnegative integer. This sets number of + flows at which eviction from the kernel flow table will be triggered. + If there are a large number of flows then increasing this value to + around the number of flows present can result in reduced CPU usage + and packet loss. +

+

+ The default is 1000. Values below 100 will be rounded up to 100. +

+ + + + Option to allow forwarding of BPDU frames when NORMAL action is + invoked. Frames with reserved Ethernet addresses (e.g. STP + BPDU) will be forwarded when this option is enabled and the + switch is not providing that functionality. If STP is enabled + on the port, STP BPDUs will never be forwarded. If the Open + vSwitch bridge is used to connect different Ethernet networks, + and if Open vSwitch node does not run STP, then this option + should be enabled. Default is disabled, set to + true to enable. + + + +

+ The maximum number of seconds to retain a MAC learning entry for + which no packets have been seen. The default is currently 300 + seconds (5 minutes). The value, if specified, is forced into a + reasonable range, currently 15 to 3600 seconds. +

+ +

+ A short MAC aging time allows a network to more quickly detect that a + host is no longer connected to a switch port. However, it also makes + it more likely that packets will be flooded unnecessarily, when they + are addressed to a connected host that rarely transmits packets. To + reduce the incidence of unnecessary flooding, use a MAC aging time + longer than the maximum interval at which a host will ordinarily + transmit packets. +

+ + + + +

+ Status information about bridges. +

+ + Key-value pairs that report bridge status. + + +

+ The bridge-id (in hex) used in spanning tree advertisements. + Configuring the bridge-id is described in the + stp-system-id and stp-priority keys + of the other_config section earlier. +

+ +

+ The designated root (in hex) for this spanning tree. +

+ + +

+ The path cost of reaching the designated bridge. A lower + number is better. +

+ + + + + The overall purpose of these columns is described under Common + Columns at the beginning of this document. + + +

A port within a .

Most commonly, a port has exactly one ``interface,'' pointed to by its - 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 - ).

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

Some properties that one might think as belonging to a port are actually - part of the port's members.

+ part of the port's members.

Port name. Should be alphanumeric and no more than about 8 @@ -458,88 +632,318 @@ -

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

Bridge ports support the following types of VLAN configuration:

+
+
trunk
+
+

+ A trunk port carries packets on one or more specified VLANs + specified in the column (often, on every + VLAN). A packet that ingresses on a trunk port is in the VLAN + specified in its 802.1Q header, or VLAN 0 if the packet has no + 802.1Q header. A packet that egresses through a trunk port will + have an 802.1Q header if it has a nonzero VLAN ID. +

+ +

+ Any packet that ingresses on a trunk port tagged with a VLAN that + the port does not trunk is dropped. +

+
+ +
access
+
+

+ An access port carries packets on exactly one VLAN specified in the + column. Packets egressing on an access port + have no 802.1Q header. +

+ +

+ Any packet with an 802.1Q header with a nonzero VLAN ID that + ingresses on an access port is dropped, regardless of whether the + VLAN ID in the header is the access port's VLAN ID. +

+
+ +
native-tagged
+
+ A native-tagged port resembles a trunk port, with the exception that + a packet without an 802.1Q header that ingresses on a native-tagged + port is in the ``native VLAN'' (specified in the + column). +
+ +
native-untagged
+
+ A native-untagged port resembles a native-tagged port, with the + exception that a packet that egresses on a native-untagged port in + the native VLAN will not have an 802.1Q header. +
+
+

+ A packet will only egress through bridge ports that carry the VLAN of + the packet, as described by the rules above. +

+ + +

+ The VLAN mode of the port, as described above. When this column is + empty, a default mode is selected as follows: +

    -
  • A ``trunk port'' has an empty value for . Its value may be - empty or non-empty.
    • -
  • An ``implicitly tagged VLAN port'' or ``access port'' - has an nonempty value for . Its - value must be empty.
    • +
  • + If contains a value, the port is an access + port. The column should be empty. +
    • +
  • + Otherwise, the port is a trunk port. The + column value is honored if it is present. +
- If and are both - nonempty, the configuration is ill-formed. -

+

- If this is an access port (see above), the port's implicitly - tagged VLAN. Must be empty if this is a trunk port. + For an access port, the port's implicitly tagged VLAN. For a + native-tagged or native-untagged port, the port's native 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. + For a trunk, native-tagged, or native-untagged port, the 802.1Q VLAN + or VLANs that this port trunks; if it is empty, then the port trunks + all VLANs. Must be empty if this is an access port.

- When a frame with a 802.1Q header that indicates a nonzero - VLAN is received on an access port, it is discarded. + A native-tagged or native-untagged port always trunks its native + VLAN, regardless of whether includes that + VLAN.

- + +

+ An 802.1Q header contains two important pieces of information: a VLAN + ID and a priority. A frame with a zero VLAN ID, called a + ``priority-tagged'' frame, is supposed to be treated the same way as + a frame without an 802.1Q header at all (except for the priority). +

+

- 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. + However, some network elements ignore any frame that has 802.1Q + header at all, even when the VLAN ID is zero. Therefore, by default + Open vSwitch does not output priority-tagged frames, instead omitting + the 802.1Q header entirely if the VLAN ID is zero. Set this key to + true to enable priority-tagged frames on a port.

+ +

+ Regardless of this setting, Open vSwitch omits the 802.1Q header on + output if both the VLAN ID and priority would be zero. +

+

- 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. + All frames output to native-tagged ports have a nonzero VLAN ID, so + this setting is not meaningful on native-tagged ports.

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) and "active backup" bonding. SLB - bonding assigns flows to slaves based on source MAC address and output - VLAN, with periodic rebalancing as traffic patterns change. Active - backup bonding assigns all flows to one slave, failing over to a backup - slave when the active slave is disabled. Neither form of bonding - require 802.3ad or other special support from the upstream switch to - which the slave devices are connected.

+ allows for load balancing and fail-over. Some kinds of bonding will + work with any kind of upstream switch:

+ +
+
balance-slb
+
+ Balances flows among slaves based on source MAC address and output + VLAN, with periodic rebalancing as traffic patterns change. +
+ +
active-backup
+
+ Assigns all flows to one slave, failing over to a backup slave when + the active slave is disabled. +
+
+ +

+ The following modes require the upstream switch to support 802.3ad with + successful LACP negotiation: +

+ +
+
balance-tcp
+
+ Balances flows among slaves based on L2, L3, and L4 protocol + information such as destination MAC address, IP address, and TCP + port. +
+ +
stable
+
+

Attempts to always assign a given flow to the same slave + consistently. In an effort to maintain stability, no load + balancing is done. Uses a similar hashing strategy to + balance-tcp, always taking into account L3 and L4 + fields even if LACP negotiations are unsuccessful.

+

Slave selection decisions are made based on if set. Otherwise, + OpenFlow port number is used. Decisions are consistent across all + ovs-vswitchd instances with equivalent + + values.

+
+

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

+ otherwise ignored.

-

The type of bonding used for a bonded port. Currently supported - values are balance-slb and active-backup. - Defaults to SLB if unset.

+

The type of bonding used for a bonded port. Defaults to + active-backup if unset. +

- -

For a bonded port, the number of milliseconds for which carrier must - stay up on an interface before the interface is considered to be up. - Specify 0 to enable the interface immediately.

-

This setting is honored only when at least one bonded interface is - already enabled. When no interfaces are enabled, then the first bond - interface to come up is enabled immediately.

+ + An integer hashed along with flows when choosing output slaves in load + balanced bonds. When changed, all flows will be assigned different + hash values possibly causing slave selection decisions to change. Does + not affect bonding modes which do not employ load balancing such as + active-backup. - - 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 disable the interface immediately. - + +

+ An important part of link bonding is detecting that links are down so + that they may be disabled. These settings determine how Open vSwitch + detects link failure. +

+ + + The means used to detect link failures. Defaults to + carrier which uses each interface's carrier to detect + failures. When set to miimon, will check for failures + by polling each interface's MII. + + + + The interval, in milliseconds, between successive attempts to poll + each interface's MII. Relevant only when is miimon. + + + +

+ The number of milliseconds for which carrier must stay up on an + interface before the interface is considered to be up. Specify + 0 to enable the interface immediately. +

+ +

+ This setting is honored only when at least one bonded interface is + already enabled. When no interfaces are enabled, then the first + bond interface to come up is enabled immediately. +

+ + + + The number of milliseconds for which carrier must stay down on an + interface before the interface is considered to be down. Specify + 0 to disable the interface immediately. + + + + +

+ LACP, the Link Aggregation Control Protocol, is an IEEE standard that + allows switches to automatically detect that they are connected by + multiple links and aggregate across those links. These settings + control LACP behavior. +

+ + + Configures LACP on this port. LACP allows directly connected + switches to negotiate which links may be bonded. LACP may be enabled + on non-bonded ports for the benefit of any switches they may be + connected to. active ports are allowed to initiate LACP + negotiations. passive ports are allowed to participate + in LACP negotiations initiated by a remote switch, but not allowed to + initiate such negotiations themselves. If LACP is enabled on a port + whose partner switch does not support LACP, the bond will be + disabled. Defaults to off if unset. + + + + The LACP system ID of this . The system ID of a + LACP bond is used to identify itself to its partners. Must be a + nonzero MAC address. Defaults to the bridge Ethernet address if + unset. + + + + The LACP system priority of this . In LACP + negotiations, link status decisions are made by the system with the + numerically lower priority. + + + +

+ The LACP timing which should be used on this . + Possible values are fast, slow and a + positive number of milliseconds. By default slow is + used. When configured to be fast LACP heartbeats are + requested at a rate of once per second causing connectivity + problems to be detected more quickly. In slow mode, + heartbeats are requested at a rate of once every 30 seconds. +

+ +

+ Users may manually set a heartbeat transmission rate to increase + the fault detection speed further. When manually set, OVS expects + the partner switch to be configured with the same transmission + rate. Manually setting lacp-time to something other + than fast or slow is not supported by the + LACP specification. +

+ + + + Treat LACP like a simple heartbeat protocol for link state + monitoring. Most features of the LACP protocol are disabled + when this mode is in use. The default if not specified is + false. + + + + +

+ These settings control behavior when a bond is in + balance-slb mode, regardless of whether the bond was + intentionally configured in SLB mode or it fell back to SLB mode + because LACP negotiation failed. +

+ + + For a load balanced bonded port, the number of milliseconds between + successive attempts to rebalance the bond, that is, to move flows + from one interface on the bond to another in an attempt to keep usage + of each interface roughly equal. If zero, load balancing is disabled + on the bond (carrier status changes still cause flows to move). If + less than 1000ms, the rebalance interval will be 1000ms. + + For a bonded port, whether to create a fake internal interface with the @@ -548,6 +952,40 @@ + + + If spanning tree is enabled on the bridge, member ports are + enabled by default (with the exception of bond, internal, and + mirror ports which do not work with STP). If this column's + value is false spanning tree is disabled on the + port. + + + + The port number used for the lower 8 bits of the port-id. By + default, the numbers will be assigned automatically. If any + port's number is manually configured on a bridge, then they + must all be. + + + + The port's relative priority value for determining the root + port (the upper 8 bits of the port-id). A port with a lower + port-id will be chosen as the root port. By default, the + priority is 0x80. + + + + Spanning tree path cost for the port. A lower number indicates + a faster link. By default, the cost is based on the maximum + speed of the link. + + + Quality of Service configuration for this port. @@ -565,54 +1003,84 @@ Bridge? See ovs-vsctl(8) for more information. - + + External IDs for a fake bridge (see the + column) are defined by prefixing a key with + fake-bridge-, + e.g. fake-bridge-xs-network-uuids. + + + + +

+ Status information about ports attached to bridges. +

+ + Key-value pairs that report port status. + +

- 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 port-id (in hex) used in spanning tree advertisements for + this port. Configuring the port-id is described in the + stp-port-num and stp-port-priority + keys of the other_config section earlier.

+ +

- 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. + STP state of the port.

- - - Key-value pairs for configuring rarely used port features. The - currently defined key-value pairs are: -
-
hwaddr
-
An Ethernet address in the form - xx:xx:xx:xx:xx:xx.
-
bond-rebalance-interval
-
For an SLB 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).
-
bond-detect-mode
-
Sets the method used to detect link failures in a bonded port. - Options are carrier and miimon. Defaults - to carrier which uses each interface's carrier to detect - failures. When set to miimon, will check for failures - by polling each interface's MII.
-
bond-miimon-interval
-
The number of milliseconds between successive attempts to - poll each interface's MII. Only relevant on ports which use - miimon to detect failures.
-
+ +

+ The amount of time (in seconds) port has been in the current + STP state. +

+ + +

+ STP role of the port. +

-
- + +

+ Key-value pairs that report port statistics. +

+ + + Number of STP BPDUs sent on this port by the spanning + tree library. + + + Number of STP BPDUs received on this port and accepted by the + spanning tree library. + + + Number of bad STP BPDUs received on this port. Bad BPDUs + include runt packets and those with an unexpected protocol ID. + + + + + + The overall purpose of these columns is described under Common + Columns at the beginning of this document. + + + + +
+ + An interface within a . @@ -625,19 +1093,19 @@

Ethernet address to set for this interface. If unset then the - default MAC address is used:

+ default MAC address is used:

  • For the local interface, the default is the lowest-numbered MAC - address among the other bridge ports, either the value of the - in its record, - if set, or its actual MAC (for bonded ports, the MAC of its slave - whose name is first in alphabetical order). Internal ports and - bridge ports that are used as port mirroring destinations (see the - table) are ignored.
    • + address among the other bridge ports, either the value of the + in its record, + if set, or its actual MAC (for bonded ports, the MAC of its slave + 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 interfaces, the default MAC is randomly - generated.
    • + generated.
  • External interfaces typically have a MAC address associated with - their hardware.
    • + their hardware.

Some interfaces may not have a software-controllable MAC address.

@@ -645,365 +1113,461 @@

OpenFlow port number for this interface. Unlike most columns, this - column's value should be set only by Open vSwitch itself. Other - clients should set this column to an empty set (the default) when - creating an .

+ column's value should be set only by Open vSwitch itself. Other + clients should set this column to an empty set (the default) when + creating an .

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

+ known. If the interface is successfully added, + will be set to a number between 1 and 65535 + (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.

 - The interface type, one of: +

+ The interface type, one of: +

+
system
An ordinary network device, e.g. eth0 on Linux. - Sometimes referred to as ``external interfaces'' since they are - generally connected to hardware external to that on which the Open - vSwitch is running. The empty string is a synonym for - system.
+ Sometimes referred to as ``external interfaces'' since they are + generally connected to hardware external to that on which the Open + vSwitch is running. The empty string is a synonym for + system. +
internal
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 - interface, so the terms ``port'' and ``interface'' are often used - imprecisely for internal interfaces.
+ internal interface whose is the same as its + bridge's is called the + ``local interface.'' It does not make sense to bond an internal + interface, so the terms ``port'' and ``interface'' are often used + imprecisely for internal interfaces. +
tap
A TUN/TAP device managed by Open vSwitch.
+
gre
-
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.
-
+
+ An Ethernet over RFC 2890 Generic Routing Encapsulation over IPv4 + tunnel. See for information on + configuring GRE tunnels.
+
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. - An authentication method of peer_cert or - psk must be defined. 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.
-
-
-
peer_cert
-
Required for certificate authentication. A string - containing the peer's certificate in PEM format. - Additionally the host's certificate must be specified - with the certificate option.
-
-
-
certificate
-
Required for certificate authentication. The name of a - PEM file containing a certificate that will be presented - to the peer during authentication.
-
-
-
private_key
-
Optional for certificate authentication. The name of - a PEM file containing the private key associated with - certificate. If certificate - contains the private key, this option may be omitted.
-
-
-
psk
-
Required for pre-shared key authentication. 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.
-
+
+ An Ethernet over RFC 2890 Generic Routing Encapsulation over IPv4 + IPsec tunnel.
+
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.
-
+
+ An Ethernet tunnel over the UDP transport portion of CAPWAP (RFC + 5415). This allows interoperability with certain switches that do + not support GRE. Only the tunneling component of the protocol is + implemented. UDP ports 58881 and 58882 are used as the source and + destination ports respectively. CAPWAP is currently supported only + with the Linux kernel datapath with kernel version 2.6.26 or later.
+
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. -
-
+ A pair of virtual devices that act as a patch cable.
+ +
null
+
An ignored interface.
 + + + +

+ These options apply to interfaces with of + gre, ipsec_gre, and capwap. +

+ +

+ Each tunnel must be uniquely identified by the combination of , , , and . 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. is + considered more specific than if + a port defines one and another port defines the other. +

+ + +

+ Required. The tunnel endpoint. Unicast and multicast endpoints are + both supported. +

+ +

+ When a multicast endpoint is specified, a routing table lookup occurs + only when the tunnel is created. Following a routing change, delete + and then re-create the tunnel to force a new routing table lookup. +

+ - - Configuration options whose interpretation varies based on - . + + Optional. The destination IP that received packets must match. + Default is to match all addresses. Must be omitted when is a multicast address. - + +

Optional. The key that received packets must contain, one of:

+ +
    +
  • + 0. The tunnel receives packets with no key or with a + key of 0. This is equivalent to specifying no at all. +
    • +
  • + A positive 32-bit (for GRE) or 64-bit (for CAPWAP) number. The + tunnel receives only packets with the specified key. +
    • +
  • + The word flow. The tunnel accepts packets with any + key. 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. +
    • +
+

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

-

The currently defined key-value pairs are:

-
-
source_ip
-
The source IP address used for an IPv4 tunnel end-point, - such as gre or capwap. Not - supported by all implementations.
-
-
-
tunnel_egress_iface
-
Egress interface for tunnels. Currently only relevant for GRE - and CAPWAP tunnels. On Linux systems, this column will show - the name of the interface which is responsible for routing - traffic destined for the configured remote_ip. - This could be an internal interface such as a bridge port.
-
+ + +

Optional. The key to be set on outgoing packets, one of:

+ +
    +
  • + 0. Packets sent through the tunnel will have no key. + This is equivalent to specifying no at all. +
    • +
  • + A positive 32-bit (for GRE) or 64-bit (for CAPWAP) number. Packets + sent through the tunnel will have the specified key. +
    • +
  • + The word flow. Packets sent through the tunnel will + have the key 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. +
    • +
+ + + + Optional. Shorthand to set in_key and + out_key at the same time. + + + + 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). The ECN fields are always inherited. + Default is 0. + + + + 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. + + + + Optional. If enabled, the Don't Fragment bit will be copied from the + inner IP headers (those of the encapsulated traffic) to the outer + (tunnel) headers. Default is disabled; set to true to + enable. + + + + Optional. If enabled, the Don't Fragment bit will be set by default on + tunnel headers if the df_inherit option is not set, or if + the encapsulated packet is not IP. Default is enabled; set to + false to disable. + + + + 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. 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. + + + +

+ Only gre interfaces support these options. +

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

+ Only gre and ipsec_gre interfaces support + these options. +

+ + +

+ Optional. Compute GRE checksums on outgoing packets. Default is + disabled, set to true to enable. Checksums present on + incoming packets will be validated regardless of this setting. +

+ +

+ GRE checksums impose a significant performance penalty because they + cover the entire packet. The encapsulated L3, L4, and L7 packet + contents typically have their own checksums, so this additional + checksum only adds value for the GRE and encapsulated L2 headers. +

+ +

+ This option is supported for ipsec_gre, but not useful + because GRE checksums are weaker than, and redundant with, IPsec + payload authentication. +

+ + + + +

+ Only ipsec_gre interfaces support these options. +

+ + + Required for certificate authentication. A string containing the + peer's certificate in PEM format. Additionally the host's + certificate must be specified with the certificate + option. + + + + Required for certificate authentication. The name of a PEM file + containing a certificate that will be presented to the peer during + authentication. + + + + Optional for certificate authentication. The name of a PEM file + containing the private key associated with certificate. + If certificate contains the private key, this option may + be omitted. + + + + Required for pre-shared key authentication. Specifies a pre-shared + key for authentication that must be identical on both sides of the + tunnel. + + + + + +

+ Only patch interfaces support these options. +

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

+ Status information about interfaces attached to bridges, updated every + 5 seconds. Not all interfaces have all of these properties; virtual + interfaces don't have a link speed, for example. Non-applicable + columns will have empty values. +

+ +

+ The administrative state of the physical network link. +

+ + + +

+ The observed state of the physical network link. This is ordinarily + the link's carrier status. If the interface's is + a bond configured for miimon monitoring, it is instead the network + link's miimon status. +

+ + + +

+ The number of times Open vSwitch has observed the + of this change. +

+ + + +

+ The negotiated speed of the physical network link. + Valid values are positive integers greater than 0. +

+ + + +

+ The duplex mode of the physical network link. +

+ + + +

+ The MTU (maximum transmission unit); i.e. the largest + amount of data that can fit into a single Ethernet frame. + The standard Ethernet MTU is 1500 bytes. Some physical media + and many kinds of virtual interfaces can be configured with + higher MTUs. +

+

+ This column will be empty for an interface that does not + have an MTU as, for example, some kinds of tunnels do not. +

+ + + + Boolean value indicating LACP status for this interface. If true, this + interface has current LACP information about its LACP partner. This + information may be used to monitor the health of interfaces in a LACP + enabled port. This column will be empty if LACP is not enabled. + + + + Key-value pairs that report port status. Supported status values are + -dependent; some interfaces may not have a valid + , for example. + + + + The name of the device driver controlling the network adapter. + + + + The version string of the device driver controlling the network + adapter. + + + + The version string of the network adapter's firmware, if available. + + + + The source IP address used for an IPv4 tunnel end-point, such as + gre or capwap. + + + + Egress interface for tunnels. Currently only relevant for GRE and + CAPWAP tunnels. On Linux systems, this column will show the name of + the interface which is responsible for routing traffic destined for the + configured . This could be an + internal interface such as a bridge port. + + + + Whether carrier is detected on . + + + + +

+ Key-value pairs that report interface statistics. The current + implementation updates these counters periodically. Future + implementations may update them when an interface is created, when they + are queried (e.g. using an OVSDB 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. +

+

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

+ + + Number of received packets. + + + Number of received bytes. + + + Number of transmitted packets. + + + Number of transmitted bytes. + + + + + Number of packets dropped by RX. + + + Number of frame alignment errors. + + + Number of packets with RX overrun. + + + Number of CRC errors. + + + Total number of receive errors, greater than or equal to the sum of + the above. + + + + + Number of packets dropped by TX. + + + Number of collisions. + + + Total number of transmit errors, greater than or equal to the sum of + the above. + + @@ -1068,9 +1632,9 @@

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.

+ default burst size if set to 0 is 1000 kb. This value + has no effect if + is 0.

Specifying a larger burst size lets the algorithm be more forgiving, which is important for protocols like TCP that react severely to @@ -1082,131 +1646,404 @@ - + +

+ 802.1ag Connectivity Fault Management (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. +

+ +

+ According to the 802.1ag specification, each Maintenance Point should + be configured out-of-band with a list of Remote Maintenance Points it + should have connectivity to. Open vSwitch differs from the + specification in this area. It simply assumes the link is faulted if + no Remote Maintenance Points are reachable, and considers it not + faulted otherwise. +

+ + + A Maintenance Point ID (MPID) uniquely identifies each endpoint within + a Maintenance Association. The MPID is used to identify this endpoint + to other Maintenance Points in the MA. Each end of a link being + monitored should have a different MPID. Must be configured to enable + CFM on this . + + + +

+ Indicates a connectivity fault triggered by an inability to receive + heartbeats from any remote endpoint. When a fault is triggered on + s participating in bonds, they will be + disabled. +

+

+ Faults can be triggered for several reasons. Most importantly they + are triggered when no CCMs are received for a period of 3.5 times the + transmission interval. Faults are also triggered when any CCMs + indicate that a Remote Maintenance Point is not receiving CCMs but + able to send them. Finally, a fault is triggered if a CCM is + received which indicates unexpected configuration. Notably, this + case arises when a CCM is received which advertises the local MPID. +

+ + + + Indicates a CFM fault was triggered due to a lack of CCMs received on + the . + + + + Indicates a CFM fault was triggered due to the reception of a CCM with + the RDI bit flagged. Endpoints set the RDI bit in their CCMs when they + are not receiving CCMs themselves. This typically indicates a + unidirectional connectivity failure. + + + + Indicates a CFM fault was triggered due to the reception of a CCM with + a MAID other than the one Open vSwitch uses. CFM broadcasts are tagged + with an identification number in addition to the MPID called the MAID. + Open vSwitch only supports receiving CCM broadcasts tagged with the + MAID it uses internally. + + + + Indicates a CFM fault was triggered due to the reception of a CCM + advertising the same MPID configured in the + column of this . This may indicate a loop in + the network. + + + + Indicates a CFM fault was triggered because the CFM module received + CCMs from more remote endpoints than it can keep track of. + + + + Indicates a CFM fault was manually triggered by an administrator using + an ovs-appctl command. + + + + When CFM is properly configured, Open vSwitch will occasionally + receive CCM broadcasts. These broadcasts contain the MPID of the + sending Maintenance Point. The list of MPIDs from which this + is receiving broadcasts from is regularly + collected and written to this column. + + + + The interval, in milliseconds, between transmissions of CFM heartbeats. + Three missed heartbeat receptions indicate a connectivity fault. + Defaults to 1000. + + + + When true, the CFM module operates in extended mode. This + causes it to use a nonstandard destination address to avoid conflicting + with compliant implementations which may be running concurrently on the + network. Furthermore, extended mode increases the accuracy of the + cfm_interval configuration parameter by breaking wire + compatibility with 802.1ag compliant implementations. Defaults to + false. + + + When down, the CFM module marks all CCMs it generates as + operationally down without triggering a fault. This allows remote + maintenance points to choose not to forward traffic to the + on which this CFM module is running. + Currently, in Open vSwitch, the opdown bit of CCMs affects + s participating in bonds, and the bundle + OpenFlow action. This setting is ignored when CFM is not in extended + mode. Defaults to up. + + + + When set, the CFM module will apply a VLAN tag to all CCMs it generates + with the given value. + + + + When set, the CFM module will apply a VLAN tag to all CCMs it generates + with the given PCP value. The VLAN ID of the tag is governed by the + value of . If + is unset, a VLAN ID of + zero is used. + + + + + + + Used in stable bond mode to make slave + selection decisions. Allocating values consistently across interfaces + participating in a bond will guarantee consistent slave selection + decisions across ovs-vswitchd instances when using + stable bonding mode. + + + + The LACP port ID of this . Port IDs are + used in LACP negotiations to identify individual ports + participating in a bond. + + + + The LACP port priority of this . In LACP + negotiations s with numerically lower + priorities are preferred for aggregation. + + + + The LACP aggregation key of this . s with different aggregation keys may not be active + within a given at the same time. + + + + +

+ These 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 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. + + + + A system-unique identifier for the interface. On XenServer, this will + commonly be the same as . + + + + The virtual interface associated with this interface. + + + + The virtual network to which this interface is attached. + + + + The VM to which this interface belongs. On XenServer, this will be the + same as . + + + + The VM to which this interface belongs. + + + + +

+ The ``VLAN splinters'' feature increases Open vSwitch compatibility + with buggy network drivers in old versions of Linux that do not + properly support VLANs when VLAN devices are not used, at some cost + in memory and performance. +

+ +

+ When VLAN splinters are enabled on a particular interface, Open vSwitch + creates a VLAN device for each in-use VLAN. For sending traffic tagged + with a VLAN on the interface, it substitutes the VLAN device. Traffic + received on the VLAN device is treated as if it had been received on + the interface on the particular VLAN. +

+ +

+ VLAN splinters consider a VLAN to be in use if: +

+ +
    +
  • + The VLAN is the value in any record. +
    • + +
  • + The VLAN is listed within the + column of the record of an interface on which + VLAN splinters are enabled. + + An empty does not influence the + in-use VLANs: creating 4,096 VLAN devices is impractical because it + will exceed the current 1,024 port per datapath limit. +
    • + +
  • + An OpenFlow flow within any bridge matches the VLAN. +
    • +
+ +

+ The same set of in-use VLANs applies to every interface on which VLAN + splinters are enabled. That is, the set is not chosen separately for + each interface but selected once as the union of all in-use VLANs based + on the rules above. +

+ +

+ It does not make sense to enable VLAN splinters on an interface for an + access port, or on an interface that is not a physical port. +

+ +

+ VLAN splinters are deprecated. When broken device drivers are no + longer in widespread use, we will delete this feature. +

+ + +

+ Set to true to enable VLAN splinters on this interface. + Defaults to false. +

- - Connectivity monitor configuration for this interface. - +

+ VLAN splinters increase kernel and userspace memory overhead, so do + not use them unless they are needed. +

- - 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. + VLAN splinters do not support 802.1p priority tags. Received + priorities will appear to be 0, regardless of their actual values, + and priorities on transmitted packets will also be cleared to 0.

-

The currently defined key-value pairs for XenServer are:

-
-
xs-vif-uuid
-
The virtual interface associated with this interface.
-
xs-network-uuid
-
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. - + + The overall purpose of these columns is described under Common + Columns at the beginning of this document. - -

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

Configuration for a particular OpenFlow table.

+ + + The table's name. Set this column to change the name that controllers + will receive when they request table statistics, e.g. ovs-ofctl + dump-tables. The name does not affect switch behavior. + + + + If set, limits the number of flows that may be added to the table. Open + vSwitch may limit the number of flows in a table for other reasons, + e.g. due to hardware limitations or for resource availability or + performance reasons. + + + +

+ Controls the switch's behavior when an OpenFlow flow table modification + request would add flows in excess of . The + supported values are: +

+ +
+
refuse
+
+ Refuse to add the flow or flows. This is also the default policy + when is unset. +
+ +
evict
+
+ Delete the flow that will expire soonest. See + for details. +
+
+ + + +

+ When is evict, this + controls how flows are chosen for eviction when the flow table would + otherwise exceed flows. Its value is a set + of NXM fields or sub-fields, each of which takes one of the forms + field[] or + field[start..end], + e.g. NXM_OF_IN_PORT[]. Please see + nicira-ext.h for a complete list of NXM field names. +

+ +

+ When a flow must be evicted due to overflow, the flow to evict is + chosen through an approximation of the following algorithm: +

+ +
    +
  1. + Divide the flows in the table into groups based on the values of the + specified fields or subfields, so that all of the flows in a given + group have the same values for those fields. If a flow does not + specify a given field, that field's value is treated as 0. +
    2. + +
  2. + Consider the flows in the largest group, that is, the group that + contains the greatest number of flows. If two or more groups all + have the same largest number of flows, consider the flows in all of + those groups. +
    3. + +
  3. + Among the flows under consideration, choose the flow that expires + soonest for eviction. +
    4. +
+ +

+ The eviction process only considers flows that have an idle timeout or + a hard timeout. That is, eviction never deletes permanent flows. + (Permanent flows do count against . +

+ +

+ Open vSwitch ignores any invalid or unknown field specifications. +

+ +

+ When is not evict, this + column has no effect. +

+ +
+

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

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

+

The type of QoS to implement. The currently defined types are + listed below:

linux-htb
@@ -1228,202 +2065,146 @@

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.

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

- -

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

+ Queue 0 is the ``default queue.'' It is used by OpenFlow output + actions when no specific queue has been set. When no configuration for + queue 0 is present, it is automatically configured as if a record with empty + and columns had been + specified. + (Before version 1.6, Open vSwitch would leave queue 0 unconfigured in + this case. With some queuing disciplines, this dropped all packets + destined for the default queue.) +

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

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

+ + + 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. + + + + + The overall purpose of these columns is described under Common + Columns at the beginning of this document. + + + +

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. + Service (QoS) features. May be referenced by column in table.

+ + + If set, Open vSwitch will mark all traffic egressing this + with the given DSCP bits. Traffic egressing the + default is only marked if it was explicitly selected + as the at the time the packet was output. If unset, + the DSCP bits of traffic egressing this will remain + unchanged. -
- -

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

+ + linux-htb may use queue_ids less than 61440. + It has the following key-value pairs defined. +

- - 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. + + Minimum guaranteed bandwidth, in bit/s. - - 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. + + 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. - - A Maintenance Domain name pairs with a Maintenance Association name to - uniquely identify a MA. Defaults to ovs if unset. + + 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. - - The transmission interval of CCMs in milliseconds. Three missed CCMs - indicate a connectivity fault. Defaults to 1000ms. + + 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. Defaults to 0 if unspecified. - - - 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. - + +

+ + linux-hfsc may use queue_ids less than 61440. + It has the following key-value pairs defined. +

- - 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. + + Minimum guaranteed bandwidth, in bit/s. - - Indicates a Connectivity Fault caused by a configuration error, a down - remote MP, or unexpected connectivity to a remote MAID or remote MP. + + 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. -
- - -

- 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. - - + + The overall purpose of these columns is described under Common + Columns at the beginning of this document. - - - Indicates a connectivity fault. - + +
- +

A port mirror within a .

A port mirror configures a bridge to send selected frames to special - ``mirrored'' ports, in addition to their normal destinations. Mirroring - traffic may also be referred to as SPAN or RSPAN, depending on the - mechanism used for delivery.

+ ``mirrored'' ports, in addition to their normal destinations. Mirroring + traffic may also be referred to as SPAN or RSPAN, depending on how + the mirrored traffic is sent.

Arbitrary identifier for the . +

+ To be selected for mirroring, a given packet must enter or leave the + bridge through a selected port and it must also be in one of the + selected VLANs. +

+ If true, every packet arriving or departing on any port is selected for mirroring. @@ -1444,63 +2225,115 @@ +

+ These columns are mutually exclusive. Exactly one of them must be + nonempty. +

+ -

Output port for selected packets, if nonempty. Mutually exclusive - with .

+

Output port for selected packets, if nonempty.

Specifying a port for mirror output reserves that port exclusively - for mirroring. No frames other than those selected for mirroring - will be forwarded to the port, and any frames received on the port - will be discarded.

-

This type of mirroring is sometimes called SPAN.

+ for mirroring. No frames other than those selected for mirroring + via this column + will be forwarded to the port, and any frames received on the port + will be discarded.

+

+ The output port may be any kind of port supported by Open vSwitch. + It may be, for example, a physical port (sometimes called SPAN) or a + GRE tunnel. +

-

Output VLAN for selected packets, if nonempty. Mutually exclusive - with .

+

Output VLAN for selected packets, if nonempty.

The frames will be sent out all ports that trunk - , as well as any ports with implicit VLAN - . When a mirrored frame is sent out a - trunk port, the frame's VLAN tag will be set to - , replacing any existing tag; when it is - sent out an implicit VLAN port, the frame will not be tagged. This - type of mirroring is sometimes called RSPAN.

+ , as well as any ports with implicit VLAN + . When a mirrored frame is sent out a + trunk port, the frame's VLAN tag will be set to + , replacing any existing tag; when it is + sent out an implicit VLAN port, the frame will not be tagged. This + type of mirroring is sometimes called RSPAN.

+

+ The following destination MAC addresses will not be mirrored to a + VLAN to avoid confusing switches that interpret the protocols that + they represent: +

+
+
01:80:c2:00:00:00
+
IEEE 802.1D Spanning Tree Protocol (STP).
+ +
01:80:c2:00:00:01
+
IEEE Pause frame.
+ +
01:80:c2:00:00:0x
+
Other reserved protocols.
+ +
01:00:0c:cc:cc:cc
+
+ Cisco Discovery Protocol (CDP), VLAN Trunking Protocol (VTP), + Dynamic Trunking Protocol (DTP), Port Aggregation Protocol (PAgP), + and others. +
+ +
01:00:0c:cc:cc:cd
+
Cisco Shared Spanning Tree Protocol PVSTP+.
+ +
01:00:0c:cd:cd:cd
+
Cisco STP Uplink Fast.
+ +
01:00:0c:00:00:00
+
Cisco Inter Switch Link.
+

Please note: Mirroring to a VLAN can disrupt a network that - contains unmanaged switches. Consider an unmanaged physical switch - with two ports: port 1, connected to an end host, and port 2, - connected to an Open vSwitch configured to mirror received packets - into VLAN 123 on port 2. Suppose that the end host sends a packet on - port 1 that the physical switch forwards to port 2. The Open vSwitch - forwards this packet to its destination and then reflects it back on - port 2 in VLAN 123. This reflected packet causes the unmanaged - physical switch to replace the MAC learning table entry, which - correctly pointed to port 1, with one that incorrectly points to port - 2. Afterward, the physical switch will direct packets destined for - the end host to the Open vSwitch on port 2, instead of to the end - host on port 1, disrupting connectivity. If mirroring to a VLAN is - desired in this scenario, then the physical switch must be replaced - by one that learns Ethernet addresses on a per-VLAN basis. In - addition, learning should be disabled on the VLAN containing mirrored - traffic. If this is not done then intermediate switches will learn - the MAC address of each end host from the mirrored traffic. If - packets being sent to that end host are also mirrored, then they will - be dropped since the switch will attempt to send them out the input - port. Disabling learning for the VLAN will cause the switch to - correctly send the packet out all ports configured for that VLAN. If - Open vSwitch is being used as an intermediate switch, learning can be - disabled by adding the mirrored VLAN to - in the appropriate table or tables.

+ contains unmanaged switches. Consider an unmanaged physical switch + with two ports: port 1, connected to an end host, and port 2, + connected to an Open vSwitch configured to mirror received packets + into VLAN 123 on port 2. Suppose that the end host sends a packet on + port 1 that the physical switch forwards to port 2. The Open vSwitch + forwards this packet to its destination and then reflects it back on + port 2 in VLAN 123. This reflected packet causes the unmanaged + physical switch to replace the MAC learning table entry, which + correctly pointed to port 1, with one that incorrectly points to port + 2. Afterward, the physical switch will direct packets destined for + the end host to the Open vSwitch on port 2, instead of to the end + host on port 1, disrupting connectivity. If mirroring to a VLAN is + desired in this scenario, then the physical switch must be replaced + by one that learns Ethernet addresses on a per-VLAN basis. In + addition, learning should be disabled on the VLAN containing mirrored + traffic. If this is not done then intermediate switches will learn + the MAC address of each end host from the mirrored traffic. If + packets being sent to that end host are also mirrored, then they will + be dropped since the switch will attempt to send them out the input + port. Disabling learning for the VLAN will cause the switch to + correctly send the packet out all ports configured for that VLAN. If + Open vSwitch is being used as an intermediate switch, learning can be + disabled by adding the mirrored VLAN to + in the appropriate table or tables.

+

+ Mirroring to a GRE tunnel has fewer caveats than mirroring to a + VLAN and should generally be preferred. +

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

+ Key-value pairs that report mirror statistics. +

+ + Number of packets transmitted through this mirror. + + + Number of bytes transmitted through this mirror. + + + The overall purpose of these columns is described under Common + Columns at the beginning of this document. + + +
@@ -1581,29 +2414,12 @@ 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.

+ part of Open vSwitch.

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

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 given ip, which must be expressed as an IP address + (not a DNS name).

The following connection methods are currently supported for service @@ -1624,7 +2440,7 @@ configuration when this form is used.

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

+ part of Open vSwitch.

ptcp:[port][:ip]
@@ -1635,8 +2451,8 @@

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

+ values must be unique. Duplicate + values yield unspecified results.

@@ -1647,26 +2463,23 @@
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.
+ 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. + 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.

+

If not specified, the default is implementation-specific.

 @@ -1683,71 +2496,73 @@ 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. + Default is implementation-specific. A value of 0 disables + inactivity probes. - - -

The maximum rate at which packets in unknown flows will be - forwarded to the OpenFlow controller, in packets per second. This - feature prevents a single bridge from overwhelming the controller. - If not specified, the default is implementation-specific.

-

In addition, when a high rate triggers rate-limiting, Open - vSwitch queues controller packets for each port and transmits - them to the controller at the configured rate. The number of - queued packets is limited by - the value. The packet - queue is shared fairly among the ports on a bridge.

Open - vSwitch maintains two such packet rate-limiters per bridge. - One of these applies to packets sent up to the controller - because they do not correspond to any flow. The other applies - to packets sent up to the controller by request through flow - actions. When both rate-limiters are filled with packets, the - actual rate that packets are sent to the controller is up to - twice the specified rate.

- + +

+ OpenFlow switches send certain messages to controllers spontanenously, + that is, not in response to any request from the controller. These + messages are called ``asynchronous messages.'' These columns allow + asynchronous messages to be limited or disabled to ensure the best use + of network resources. +

- - 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 OpenFlow protocol enables asynchronous messages at time of + connection establishment, which means that a controller can receive + asynchronous messages, potentially many of them, even if it turns them + off immediately after connecting. Set this column to + false to change Open vSwitch behavior to disable, by + default, all asynchronous messages. The controller can use the + NXT_SET_ASYNC_CONFIG Nicira extension to OpenFlow to turn + on any messages that it does want to receive, if any. + - -

These values are considered only when - is discover.

+ +

+ The maximum rate at which the switch will forward packets to the + OpenFlow controller, in packets per second. This feature prevents a + single bridge from overwhelming the controller. If not specified, + the default is implementation-specific. +

- - 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 - if it begins with ^. If not specified, the default - is implementation-specific. +

+ In addition, when a high rate triggers rate-limiting, Open vSwitch + queues controller packets for each port and transmits them to the + controller at the configured rate. The value limits the number of queued + packets. Ports on a bridge share the packet queue fairly. +

+ +

+ Open vSwitch maintains two such packet rate-limiters per bridge: one + for packets sent up to the controller because they do not correspond + to any flow, and the other for packets sent up to the controller by + request through flow actions. When both rate-limiters are filled with + packets, the actual rate that packets are sent to the controller is + up to twice the specified rate. +

- - 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 - specifies one or more DNS servers. + + 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 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.

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

The IP address to configure on the local port, @@ -1770,15 +2585,87 @@ - - - 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. + + + true if currently connected to this controller, + false otherwise. + + + +

The level of authority this controller has on the associated + bridge. Possible values are:

+
+
other
+
Allows the controller access to all OpenFlow features.
+
master
+
Equivalent to other, except that there may be at + most one master controller at a time. When a controller configures + itself as master, any existing master is demoted to + the slaverole.
+
slave
+
Allows the controller read-only access to OpenFlow features. + Attempts to modify the flow table will be rejected with an + error. Slave controllers do not receive OFPT_PACKET_IN or + OFPT_FLOW_REMOVED messages, but they do receive OFPT_PORT_STATUS + messages.
+
+ + + + A human-readable description of the last error on the connection + to the controller; i.e. strerror(errno). This key + will exist only if an error has occurred. + + + +

+ The state of the connection to the controller: +

+
+
VOID
+
Connection is disabled.
+ +
BACKOFF
+
Attempting to reconnect at an increasing period.
+ +
CONNECTING
+
Attempting to connect.
+ +
ACTIVE
+
Connected, remote host responsive.
+ +
IDLE
+
Connection is idle. Waiting for response to keep-alive.
+
+

+ These values may change in the future. They are provided only for + human consumption. +

+ + + + The amount of time since this controller last successfully connected to + the switch (in seconds). Value is empty if controller has never + successfully connected. + + + + The amount of time since this controller last disconnected from + the switch (in seconds). Value is empty if controller has never + disconnected. + + + The overall purpose of these columns is described under Common + Columns at the beginning of this document. + + +
@@ -1906,18 +2793,103 @@ 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. + A value of 0 disables inactivity probes. - - - 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. + + + true if currently connected to this manager, + false otherwise. + + + + A human-readable description of the last error on the connection + to the manager; i.e. strerror(errno). This key + will exist only if an error has occurred. + + + +

+ The state of the connection to the manager: +

+
+
VOID
+
Connection is disabled.
+ +
BACKOFF
+
Attempting to reconnect at an increasing period.
+ +
CONNECTING
+
Attempting to connect.
+ +
ACTIVE
+
Connected, remote host responsive.
+ +
IDLE
+
Connection is idle. Waiting for response to keep-alive.
+
+

+ These values may change in the future. They are provided only for + human consumption. +

+ + + + The amount of time since this manager last successfully connected + to the database (in seconds). Value is empty if manager has never + successfully connected. + + + + The amount of time since this manager last disconnected from the + database (in seconds). Value is empty if manager has never + disconnected. + + + + Space-separated list of the names of OVSDB locks that the connection + holds. Omitted if the connection does not hold any locks. + + + + Space-separated list of the names of OVSDB locks that the connection is + currently waiting to acquire. Omitted if the connection is not waiting + for any locks. + + + + Space-separated list of the names of OVSDB locks that the connection + has had stolen by another OVSDB client. Omitted if no locks have been + stolen from this connection. + + + +

+ When specifies a connection method that + listens for inbound connections (e.g. ptcp: or + pssl:) and more than one connection is actually active, + the value is the number of active connections. Otherwise, this + key-value pair is omitted. +

+

+ When multiple connections are active, status columns and key-value + pairs (other than this one) report the status of one arbitrarily + chosen connection. +

+ + + The overall purpose of these columns is described under Common + Columns at the beginning of this document. + + +
@@ -1950,23 +2922,22 @@

If this column's value is false, the ingress and egress - interface fields of NetFlow flow records are derived from OpenFlow port - numbers. When it is true, the 7 most significant bits of - these fields will be replaced by the least significant 7 bits of the - engine id. This is useful because many NetFlow collectors do not - expect multiple switches to be sending messages from the same host, so - they do not store the engine information which could be used to - disambiguate the traffic.

+ interface fields of NetFlow flow records are derived from OpenFlow port + numbers. When it is true, the 7 most significant bits of + these fields will be replaced by the least significant 7 bits of the + engine id. This is useful because many NetFlow collectors do not + expect multiple switches to be sending messages from the same host, so + they do not store the engine information which could be used to + 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. - + + The overall purpose of these columns is described under Common + Columns at the beginning of this document. + + +
@@ -1996,29 +2967,30 @@ it will immediately drop the connection and reconnect, and from then on all SSL connections must be authenticated by a certificate signed by the CA certificate thus obtained. This option exposes the - SSL connection to a man-in-the-middle attack obtaining the initial - CA certificate. It may still be useful for bootstrapping. + 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. - + + The overall purpose of these columns is described under Common + Columns at the beginning of this document. + + +

An sFlow(R) target. sFlow is a protocol for remote monitoring - of switches.

+ of switches.

Name of the network device whose IP address should be reported as the - ``agent address'' to collectors. If not specified, the IP address + ``agent address'' to collectors. If not specified, the agent device is + figured from the first target address and the routing table. If the + routing table does not contain a route to the target, the IP address defaults to the in the collector's . If an agent IP address cannot be - determined either way, sFlow is disabled. + determined any of these ways, sFlow is disabled. @@ -2042,54 +3014,12 @@ 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 overall purpose of these columns is described under Common + Columns at the beginning of this document. -

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