+
+ 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.
+
+
+
+
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 +819,305 @@
- 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).
+
+
+
+ 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.
+
+
- 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.
+ 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.
- These columns apply only to bonded ports. Their values are
- otherwise ignored.
+
+ The following types of bonding will work with any kind of upstream
+ switch. On the upstream switch, do not configure the interfaces as a
+ bond:
+
-
- The type of bonding used for a bonded port. Currently supported
- values are slb
and active-backup
. Defaults
- to SLB if unset.
-
+
+ balance-slb
+ -
+ Balances flows among slaves based on source MAC address and output
+ VLAN, with periodic rebalancing as traffic patterns change.
+
-
- 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.
-
+ active-backup
+ -
+ Assigns all flows to one slave, failing over to a backup slave when
+ the active slave is disabled. This is the only bonding mode in which
+ interfaces may be plugged into different upstream switches.
+
+
-
- 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.
-
+
+ The following modes require the upstream switch to support 802.3ad with
+ successful LACP negotiation. If LACP negotiation fails and
+ other-config:lacp-fallback-ab is true, then active-backup
+ mode is used:
+
+
+
+ balance-tcp
+ -
+ Balances flows among slaves based on L2, L3, and L4 protocol
+ information such as destination MAC address, IP address, and TCP
+ port.
+
+
+
+ These columns apply only to bonded ports. Their values are
+ otherwise ignored.
+
+
+ The type of bonding used for a bonded port. Defaults to
+ active-backup
if unset.
+
+
+
+
+ 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
.
+
+
+
+
+ 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 the link 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 the link 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, unless other-config:lacp-fallback-ab is set to true.
+ 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 .
+ 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.
+
+
+
+
+
+ Determines the behavior of openvswitch bond in LACP mode. If
+ the partner switch does not support LACP, setting this option
+ to true
allows openvswitch to fallback to
+ active-backup. If the option is set to false
, the
+ bond will be disabled. In both the cases, once the partner switch
+ is configured to LACP mode, the bond will use LACP.
+
+
+
+
+
+
+ These settings control behavior when a bond is in
+ balance-slb
or balance-tcp
mode.
+
+
+
+ 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 (link failure 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 +1126,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,41 +1177,83 @@
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).
-
+
+
+ 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. The update period
+ is controlled by in the Open_vSwitch
table.
+
+
+
+ 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.
+
+
+
+
@@ -613,389 +1267,586 @@
on a host.
+
+ A positive interface index as defined for SNMP MIB-II in RFCs 1213 and
+ 2863, if the interface has one, otherwise 0. The ifindex is useful for
+ seamless integration with protocols such as SNMP and sFlow.
+
+
+
+ The MAC address in use by this interface.
+
+
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.
-
- 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 .
- 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.
-
+
+
+ When a client adds a new interface, Open vSwitch chooses an OpenFlow
+ port number for the new port. If the client that adds the port fills
+ in , then Open vSwitch tries to use its
+ value as the OpenFlow port number. Otherwise, or if the requested
+ port number is already in use or cannot be used for another reason,
+ Open vSwitch automatically assigns a free port number. Regardless of
+ how the port number was obtained, Open vSwitch then reports in the port number actually assigned.
+
+
+
+ Open vSwitch limits the port numbers that it automatically assigns to
+ the range 1 through 32,767, inclusive. Controllers therefore have
+ free use of ports 32,768 and up.
+
+
+
+
+ OpenFlow port number for this interface. Open vSwitch sets this
+ column's value, so other clients should treat it as read-only.
+
+
+ The OpenFlow ``local'' port (OFPP_LOCAL
) is 65,534.
+ The other valid port numbers are in the range 1 to 65,279,
+ inclusive. Value -1 indicates an error adding the interface.
+
+
+
+
+
+ Requested OpenFlow port number for this interface.
+
+
+
+ A client should ideally set this column's value in the same
+ database transaction that it uses to create the interface. Open
+ vSwitch version 2.1 and later will honor a later request for a
+ specific port number, althuogh it might confuse some controllers:
+ OpenFlow does not have a way to announce a port number change, so
+ Open vSwitch represents it over OpenFlow as a port deletion
+ followed immediately by a port addition.
+
+
+
+ If is set or changed to some other
+ port's automatically assigned port number, Open vSwitch chooses a
+ new port number for the latter port.
+
+
+
- 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.
+
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.
+
+
+ gre64
+ -
+ It is same as GRE, but it allows 64 bit key. To store higher 32-bits
+ of key, it uses GRE protocol sequence number field. This is non
+ standard use of GRE protocol since OVS does not increment
+ sequence number for every packet at time of encap as expected by
+ standard GRE implementation. See
+ for information on configuring GRE tunnels.
- 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.
-
+
+ ipsec_gre64
+ -
+ Same as IPSEC_GRE except 64 bit key.
- patch
+
+ vxlan
-
+
+ An Ethernet tunnel over the experimental, UDP-based VXLAN
+ protocol described at
+ http://tools.ietf.org/html/draft-mahalingam-dutt-dcops-vxlan-03
.
+
+
+ Open vSwitch uses UDP destination port 4789. The source port used for
+ VXLAN traffic varies on a per-flow basis and is in the ephemeral port
+ range.
+
+
+
+ lisp
+ -
+
+ A layer 3 tunnel over the experimental, UDP-based Locator/ID
+ Separation Protocol (RFC 6830).
+
- A pair of virtual devices that act as a patch cable. The column must have the following key-value pair:
+ Only IPv4 and IPv6 packets are supported by the protocol, and
+ they are sent and received without an Ethernet header. Traffic
+ to/from LISP ports is expected to be configured explicitly, and
+ the ports are not intended to participate in learning based
+ switching. As such, they are always excluded from packet
+ flooding.
-
- 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.
-
-
+
+ patch
+ -
+ A pair of virtual devices that act as a patch cable.
+
+
+ null
+ - An ignored interface. Deprecated and slated for removal in
+ February 2013.
+
+
+
+
+ These options apply to interfaces with of
+ gre
, ipsec_gre
, gre64
,
+ ipsec_gre64
, vxlan
, and lisp
.
+
+
+
+ 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.
+
-
- Configuration options whose interpretation varies based on
- .
+
+ Required. The remote tunnel endpoint, one of:
+
+
+ -
+ An IPv4 address (not a DNS name), e.g.
192.168.0.123
.
+ Only unicast endpoints are supported.
+
+ -
+ The word
flow
. The tunnel accepts packets from any
+ remote tunnel endpoint. To process only packets from a specific
+ remote tunnel endpoint, the flow entries may match on the
+ tun_src
field. When sending packets to a
+ remote_ip=flow
tunnel, the flow actions must
+ explicitly set the tun_dst
field to the IP address of
+ the desired remote tunnel endpoint, e.g. with a
+ set_field
action.
+
+
+
+
+ The remote tunnel endpoint for any packet received from a tunnel
+ is available in the tun_src
field for matching in the
+ flow table.
+
-
+
- Key-value pairs that report port status. Supported status
- values are type
-dependent.
+ Optional. The tunnel destination IP that received packets must
+ match. Default is to match all addresses. If specified, may be one
+ of:
- 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.
-
+
+
+
+
+ The tunnel destination IP address for any packet received from a
+ tunnel is available in the tun_dst
field for matching in
+ the flow table.
+
+
+
+
+ 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 24-bit (for VXLAN and LISP), 32-bit (for GRE) or 64-bit
+ (for GRE64) 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.
+
+
+
+
+
+
+
+
+ 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 24-bit (for VXLAN and LISP), 32-bit (for GRE) or 64-bit
+ (for GRE64) 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. ToS is interpreted as DSCP and ECN bits, ECN part must be
+ zero. 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 set on tunnel
+ outer headers to allow path MTU discovery. 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
.
+
+
+
+ Egress interface for tunnels. Currently only relevant for GRE 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. The update period
+ is controlled by in the Open_vSwitch
table.
+ 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.
+
+
+
+
These settings control ingress policing for packets received on this
@@ -1058,9 +1909,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
@@ -1072,131 +1923,751 @@
-
+
+
+ BFD, defined in RFC 5880 and RFC 5881, allows point-to-point
+ detection of connectivity failures by occasional transmission of
+ BFD control messages. Open vSwitch implements BFD to serve
+ as a more popular and standards compliant alternative to CFM.
+
-
- Connectivity monitor configuration for this interface.
+
+ BFD operates by regularly transmitting BFD control messages at a rate
+ negotiated independently in each direction. Each endpoint specifies
+ the rate at which it expects to receive control messages, and the rate
+ at which it is willing to transmit them. Open vSwitch uses a detection
+ multiplier of three, meaning that an endpoint signals a connectivity
+ fault if three consecutive BFD control messages fail to arrive. In the
+ case of a unidirectional connectivity issue, the system not receiving
+ BFD control messages signals the problem to its peer in the messages it
+ transmits.
+
+
+
+ The Open vSwitch implementation of BFD aims to comply faithfully
+ with RFC 5880 requirements. Open vSwitch does not implement the
+ optional Authentication or ``Echo Mode'' features.
+
+
+
+
+ A controller sets up key-value pairs in the
+ column to enable and configure BFD.
+
+
+
+ True to enable BFD on this .
+
+
+
+ The shortest interval, in milliseconds, at which this BFD session
+ offers to receive BFD control messages. The remote endpoint may
+ choose to send messages at a slower rate. Defaults to
+ 1000
.
+
+
+
+ The shortest interval, in milliseconds, at which this BFD session is
+ willing to transmit BFD control messages. Messages will actually be
+ transmitted at a slower rate if the remote endpoint is not willing to
+ receive as quickly as specified. Defaults to 100
.
+
+
+
+ An alternate receive interval, in milliseconds, that must be greater
+ than or equal to . The
+ implementation switches from to when there is no obvious incoming
+ data traffic at the interface, to reduce the CPU and bandwidth cost
+ of monitoring an idle interface. This feature may be disabled by
+ setting a value of 0. This feature is reset whenever or
+ changes.
+
+
+
+ When true
, traffic received on the
+ is used to indicate the capability of packet
+ I/O. BFD control packets are still transmitted and received. At
+ least one BFD control packet must be received every 100 * amount of time. Otherwise, even if
+ traffic are received, the
+ will be false
.
+
+
+
+ Set to true to notify the remote endpoint that traffic should not be
+ forwarded to this system for some reason other than a connectivty
+ failure on the interface being monitored. The typical underlying
+ reason is ``concatenated path down,'' that is, that connectivity
+ beyond the local system is down. Defaults to false.
+
+
+
+ Set to true to make BFD accept only control messages with a tunnel
+ key of zero. By default, BFD accepts control messages with any
+ tunnel key.
+
+
+
+ Set to an Ethernet address in the form
+ xx:xx:xx:xx:xx:xx
+ to set the MAC used as destination for transmitted BFD packets and
+ expected as destination for received BFD packets. The default is
+ 00:23:20:00:00:01
.
+
+
+
+ Set to an IPv4 address to set the IP address used as source for
+ transmitted BFD packets. The default is 169.254.1.0
.
+
+
+
+ Set to an IPv4 address to set the IP address used as destination
+ for transmitted BFD packets. The default is 169.254.1.1
.
+
+
+
+
+
+ The switch sets key-value pairs in the
+ column to report the status of BFD on this interface. When BFD is
+ not enabled, with , the switch clears
+ all key-value pairs from .
+
+
+
+ Reports the state of the BFD session. The BFD session is fully
+ healthy and negotiated if UP
.
+
+
+
+ Reports whether the BFD session believes this may be used to forward traffic. Typically this
+ means the local session is signaling UP
, and the remote
+ system isn't signaling a problem such as concatenated path down.
+
+
+
+ In case of a problem, set to a short message that reports what the
+ local BFD session thinks is wrong.
+
+
+
+ Reports the state of the remote endpoint's BFD session.
+
+
+
+ In case of a problem, set to a short message that reports what the
+ remote endpoint's BFD session thinks is wrong.
+
+
+
+ Counts the number of
+ flaps since start. A flap is considered as a change of the
+ value.
+
+
+
+
+
+
+ 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.
+
+
+
+ When operating over tunnels which have no in_key
, or an
+ in_key
of flow
. CFM will only accept CCMs
+ with a tunnel key of zero.
+
+
+
+
+ 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 .
+
+
+ According to the 802.1ag specification, MPIDs can only range between
+ [1, 8191]. However, extended mode (see ) supports eight byte MPIDs.
+
-
- 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
.
-
+
+ Counts the number of cfm fault flapps since boot. A flap is
+ considered to be a change of the value.
+
+
+
- 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.
+ 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.
- 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.
+
+ 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.
+
+
+
+ Indicates a CFM fault was triggered due to the reception of a CCM
+ frame having an invalid interval.
+
+
+
+ When in extended mode, indicates the operational state of the
+ remote endpoint as either up
or down
. See
+ .
+
+
+
+
- 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.
+ Indicates the health of the interface as a percentage of CCM frames
+ received over 21 s.
+ The health of an interface is undefined if it is communicating with
+ more than one . It reduces if
+ healthy heartbeats are not received at the expected rate, and
+ gradually improves as healthy heartbeats are received at the desired
+ rate. Every 21 s, the
+ health of the interface is refreshed.
+
- 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.
-
-
-
-
+ As mentioned above, the faults can be triggered for several reasons.
+ The link health will deteriorate even if heartbeats are received but
+ they are reported to be unhealthy. An unhealthy heartbeat in this
+ context is a heartbeat for which either some fault is set or is out
+ of sequence. The interface health can be 100 only on receiving
+ healthy heartbeats at the desired rate.
+
+
+
+
+ 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.
+
+
+
+ In standard operation only intervals of 3, 10, 100, 1,000, 10,000,
+ 60,000, or 600,000 ms are supported. Other values will be rounded
+ down to the nearest value on the list. Extended mode (see ) supports any interval up
+ to 65,535 ms. In either mode, the default is 1000 ms.
+
+
+ We do not recommend using intervals less than 100 ms.
+
+
+
+ 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. And extended
+ mode allows eight byte MPIDs. Defaults to false
.
+
+
+
+
+ When true
, and
+ is true, the CFM
+ module operates in demand mode. When in demand mode, traffic
+ received on the is used to indicate
+ liveness. CCMs are still transmitted and received. At least one
+ CCM must be received every 100 * amount of time. Otherwise, even if traffic
+ are received, the CFM module will raise the connectivity fault.
+
+
+
+ Demand mode has a couple of caveats:
+
+ -
+ To ensure that ovs-vswitchd has enough time to pull statistics
+ from the datapath, the fault detection interval is set to
+ 3.5 * MAX(
, 500)
+ ms.
+
+
+ -
+ To avoid ambiguity, demand mode disables itself when there are
+ multiple remote maintenance points.
+
+
+ -
+ If the
is heavily congested, CCMs
+ containing the
+ status may be dropped causing changes in the operational state to
+ be delayed. Similarly, if CCMs containing the RDI bit are not
+ received, unidirectional link failures may not be detected.
+
+
+
+
+
+
+ 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. May be the string random
in which
+ case each CCM will be tagged with a different randomly generated VLAN.
+
+
+
+ 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.
+
+
+
+
+
+
+ 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 .
+
+
+
+ Hypervisors may sometimes have more than one interface associated
+ with a given , only one of
+ which is actually in use at a given time. For example, in some
+ circumstances XenServer has both a ``tap'' and a ``vif'' interface
+ for a single , but only
+ uses one of them at a time. A hypervisor that behaves this way must
+ mark the currently in use interface active
and the
+ others inactive
. A hypervisor that never has more than
+ one interface for a given
+ may mark that interface active
or omit entirely.
+
+
+
+ During VM migration, a given might transiently be marked active
on
+ two different hypervisors. That is, active
means that
+ this is the active
+ instance within a single hypervisor, not in a broader scope.
+ There is one exception: some hypervisors support ``migration'' from a
+ given hypervisor to itself (most often for test purposes). During
+ such a ``migration,'' two instances of a single might both be briefly marked
+ active
on a single hypervisor.
+
+
+
+
+ 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
.
+
+
+
+ VLAN splinters increase kernel and userspace memory overhead, so do
+ not use them unless they are needed.
+
+
+
+ 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 overall purpose of these columns is described under Common
+ Columns
at the beginning of this document.
+
+
+
+
+
+
+
+ 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:
+
+
+
+ -
+ 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.
+
+
+ -
+ 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.
+
+
+ -
+ Among the flows under consideration, choose the flow that expires
+ soonest for eviction.
+
+
+
+
+ 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.
+
+
+
+
+
+ This string set specifies which fields should be used for
+ address prefix tracking. Prefix tracking allows the
+ classifier to skip rules with longer than necessary prefixes,
+ resulting in better wildcarding for datapath flows.
+
+
+ Prefix tracking may be beneficial when a flow table contains
+ matches on IP address fields with different prefix lengths.
+ For example, when a flow table contains IP address matches on
+ both full addresses and proper prefixes, the full address
+ matches will typically cause the datapath flow to un-wildcard
+ the whole address field (depending on flow entry priorities).
+ In this case each packet with a different address gets handed
+ to the userspace for flow processing and generates its own
+ datapath flow. With prefix tracking enabled for the address
+ field in question packets with addresses matching shorter
+ prefixes would generate datapath flows where the irrelevant
+ address bits are wildcarded, allowing the same datapath flow
+ to handle all the packets within the prefix in question. In
+ this case many userspace upcalls can be avoided and the
+ overall performance can be better.
+
+
+ This is a performance optimization only, so packets will
+ receive the same treatment with or without prefix tracking.
+
+
+ The supported fields are: tun_id
,
+ tun_src
, tun_dst
,
+ nw_src
, nw_dst
(or aliases
+ ip_src
and ip_dst
),
+ ipv6_src
, and ipv6_dst
. (Using this
+ feature for tun_id
would only make sense if the
+ tunnel IDs have prefix structure similar to IP addresses.)
+
+
+ For example, prefixes=ip_dst,ip_src
instructs the
+ flow classifier to track the IP destination and source
+ addresses used by the rules in this specific flow table. To
+ set the prefix fields, the flow table record needs to exist:
+
+
+ ovs-vsctl set Bridge br0 flow_tables:0=@N1 -- --id=@N1 create Flow_Table name=table0
+ -
+ Creates a flow table record for the OpenFlow table number 0.
+
+
+ ovs-vsctl set Flow_Table table0 prefixes=ip_dst,ip_src
+ -
+ Enables prefix tracking for IP source and destination
+ address fields.
+
+
+
+
+ There is a maximum number of fields that can be enabled for any
+ one flow table. Currently this limit is 3.
+
+
+
+
+ The overall purpose of these columns is described under Common
+ Columns
at the beginning of this document.
+
+
+
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.
@@ -1434,62 +2849,92 @@
+
+ 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.
+
+ See the documentation for
+ in the
+ table for a list of destination MAC
+ addresses which will not be mirrored to a VLAN to avoid confusing
+ switches that interpret the protocols that they represent.
+
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. The update period
+ is controlled by in the Open_vSwitch
table.
+
+
+ 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.
+
+
@@ -1565,34 +3010,32 @@
ssl:ip
[:port
]
-
-
The specified SSL port (default: 6633) on the host at
- the given ip, which must be expressed as an IP address
- (not a DNS name). The
- column in the table must point to a
- valid SSL configuration when this form is used.
+ The specified SSL port on the host at the
+ given ip, which must be expressed as an IP
+ address (not a DNS name). The column in the
+ table must point to a valid SSL configuration when this form
+ is used.
+ If port is not specified, it currently
+ defaults to 6633. In the future, the default will change to
+ 6653, which is the IANA-defined value.
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 specified TCP port on the host at the given
+ ip, which must be expressed as an IP address (not a
+ DNS name), where ip can be IPv4 or IPv6 address. If
+ ip is an IPv6 address, wrap it in square brackets,
+ e.g. tcp:[::1]:6632
.
+
+
+ If port is not specified, it currently defaults to
+ 6633. In the future, the default will change to 6653, which is
+ the IANA-defined value.
+
@@ -1603,30 +3046,52 @@
pssl:
[port][:ip
]
- Listens for SSL connections on the specified TCP port
- (default: 6633). If ip, which must be expressed as an
- IP address (not a DNS name), is specified, then connections are
- restricted to the specified local IP address.
+ Listens for SSL connections on the specified TCP port.
+ If ip, which must be expressed as an IP address (not a
+ DNS name), is specified, then connections are restricted to the
+ specified local IP address (either IPv4 or IPv6). If
+ ip is an IPv6 address, wrap it in square brackets,
+ e.g. pssl:6632:[::1]
.
- The column in the table must point to a valid SSL
- configuration when this form is used.
+ If port is not specified, it currently defaults to
+ 6633. If ip is not specified then it listens only on
+ IPv4 (but not IPv6) addresses. The
+
+ column in the table must point to a
+ valid SSL configuration when this form is used.
+
+
+ If port is not specified, it currently defaults to
+ 6633. In the future, the default will change to 6653, which is
+ the IANA-defined value.
+
+
+ SSL support is an optional feature that is not always built as
+ part of Open vSwitch.
- SSL support is an optional feature that is not always built as
- part of Open vSwitch.
ptcp:
[port][:ip
]
- Listens for connections on the specified TCP port
- (default: 6633). If ip, which must be expressed as an
- IP address (not a DNS name), is specified, then connections are
- restricted to the specified local IP address.
+
+ Listens for connections on the specified TCP port. If
+ ip, which must be expressed as an IP address (not a
+ DNS name), is specified, then connections are restricted to the
+ specified local IP address (either IPv4 or IPv6). If
+ ip is an IPv6 address, wrap it in square brackets,
+ e.g. ptcp:6632:[::1]
. If ip is not
+ specified then it listens only on IPv4 addresses.
+
+
+ If port is not specified, it currently defaults to
+ 6633. In the future, the default will change to 6653, which is
+ the IANA-defined value.
+
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.
@@ -1637,26 +3102,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.
@@ -1673,71 +3135,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,
@@ -1760,15 +3224,109 @@
-
-
- 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 slave
role.
+ 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.
+
+
+
+
+
+ Additional configuration for a connection between the controller
+ and the Open vSwitch.
+
+
+
+ The Differentiated Service Code Point (DSCP) is specified using 6 bits
+ in the Type of Service (TOS) field in the IP header. DSCP provides a
+ mechanism to classify the network traffic and provide Quality of
+ Service (QoS) on IP networks.
+
+ The DSCP value specified here is used when establishing the connection
+ between the controller and the Open vSwitch. If no value is specified,
+ a default value of 48 is chosen. Valid DSCP values must be in the
+ range 0 to 63.
+
+
+
+ The overall purpose of these columns is described under Common
+ Columns
at the beginning of this document.
+
+
+
+
@@ -1800,37 +3358,60 @@
ssl:ip
[:port
]
- The specified SSL port (default: 6632) on the host at
- the given ip, which must be expressed as an IP address
- (not a DNS name). The
- column in the table must point to a
- valid SSL configuration when this form is used.
+ The specified SSL port on the host at the given
+ ip, which must be expressed as an IP address
+ (not a DNS name). The column in the
+ table must point to a valid SSL configuration when this
+ form is used.
- SSL support is an optional feature that is not always built as
- part of Open vSwitch.
+ If port is not specified, it currently defaults
+ to 6632. In the future, the default will change to 6640,
+ which is the IANA-defined value.
+
+
+ SSL support is an optional feature that is not always
+ built as part of Open vSwitch.
tcp:ip
[:port
]
- The specified TCP port (default: 6632) on the host at
- the given ip, which must be expressed as an IP address
- (not a DNS name).
+
+ The specified TCP port on the host at the given
+ ip, which must be expressed as an IP address (not a
+ DNS name), where ip can be IPv4 or IPv6 address. If
+ ip is an IPv6 address, wrap it in square brackets,
+ e.g. tcp:[::1]:6632
.
+
+
+ If port is not specified, it currently defaults
+ to 6632. In the future, the default will change to 6640,
+ which is the IANA-defined value.
+
pssl:
[port][:ip
]
- Listens for SSL connections on the specified TCP port
- (default: 6632). If ip, which must be expressed as an
- IP address (not a DNS name), is specified, then connections are
- restricted to the specified local IP address.
-
-
+ Listens for SSL connections on the specified TCP port.
+ Specify 0 for port to have the kernel automatically
+ choose an available port. If ip, which must be
+ expressed as an IP address (not a DNS name), is specified, then
+ connections are restricted to the specified local IP address
+ (either IPv4 or IPv6 address). If ip is an IPv6
+ address, wrap in square brackets,
+ e.g. pssl:6632:[::1]
. If ip is not
+ specified then it listens only on IPv4 (but not IPv6) addresses.
The column in the table must point to a valid SSL
configuration when this form is used.
+
+ If port is not specified, it currently defaults
+ to 6632. In the future, the default will change to 6640,
+ which is the IANA-defined value.
+
SSL support is an optional feature that is not always built as
part of Open vSwitch.
@@ -1838,10 +3419,22 @@
ptcp:
[port][:ip
]
- Listens for connections on the specified TCP port
- (default: 6632). If ip, which must be expressed as an
- IP address (not a DNS name), is specified, then connections are
- restricted to the specified local IP address.
+
+ Listens for connections on the specified TCP port.
+ Specify 0 for port to have the kernel automatically
+ choose an available port. If ip, which must be
+ expressed as an IP address (not a DNS name), is specified, then
+ connections are restricted to the specified local IP address
+ (either IPv4 or IPv6 address). If ip is an IPv6
+ address, wrap it in square brackets,
+ e.g. ptcp:6632:[::1]
. If ip is not
+ specified then it listens only on IPv4 addresses.
+
+
+ If port is not specified, it currently defaults
+ to 6632. In the future, the default will change to 6640,
+ which is the IANA-defined value.
+
When multiple managers are configured, the
@@ -1896,18 +3489,132 @@
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.
+
+
+
+
+ When is ptcp:
or
+ pssl:
, this is the TCP port on which the OVSDB server is
+ listening. (This is is particularly useful when specifies a port of 0, allowing the kernel to
+ choose any available port.)
+
+
+
+
+
+ Additional configuration for a connection between the manager
+ and the Open vSwitch Database.
+
+
+
+ The Differentiated Service Code Point (DSCP) is specified using 6 bits
+ in the Type of Service (TOS) field in the IP header. DSCP provides a
+ mechanism to classify the network traffic and provide Quality of
+ Service (QoS) on IP networks.
+
+ The DSCP value specified here is used when establishing the connection
+ between the manager and the Open vSwitch. If no value is specified, a
+ default value of 48 is chosen. Valid DSCP values must be in the range
+ 0 to 63.
+
+
+ The overall purpose of these columns is described under Common
+ Columns
at the beginning of this document.
+
+
+
+