X-Git-Url: https://pintos-os.org/cgi-bin/gitweb.cgi?a=blobdiff_plain;f=vswitchd%2Fvswitch.xml;h=4cdc1b1ca38da4b38b94b63d5fe3e71681b74ba7;hb=9e97e8bbe37bfcc6c308be29df637b1776d1f76e;hp=0a3a6c237c22051982ba3a3d70333fb6d436cbe1;hpb=7894d33b258ed848d13172fdbbc60ee4db59aa3a;p=openvswitch
diff --git a/vswitchd/vswitch.xml b/vswitchd/vswitch.xml
index 0a3a6c23..4cdc1b1c 100644
--- a/vswitchd/vswitch.xml
+++ b/vswitchd/vswitch.xml
@@ -1,44 +1,46 @@
+
- A database with this schema holds the configuration for one Open
- vSwitch daemon. The root of the configuration for the daemon is
- the table, which must have exactly one
+
+ A database with this schema holds the configuration for one Open
+ vSwitch daemon. The top-level configuration for the daemon is the
+ table, which must have exactly one
record. Records in other tables are significant only when they
- can be reached directly or indirectly from the
- table.
+ can be reached directly or indirectly from the table. Records that are not reachable from
+ the table are automatically deleted
+ from the database, except for records in a few distinguished
+ ``root set'' tables noted below.
+
- A port that has more than one interface is a ``bonded port.''
- Bonding allows for load balancing and fail-over. Open vSwitch
- supports ``source load balancing'' (SLB) bonding, which
- assigns flows to slaves based on source MAC address, with
- periodic rebalancing as traffic patterns change. This form of
- bonding does not require 802.3ad or other special support from
- the upstream switch to which the slave devices are
- connected.
+ A port that has more than one interface is a ``bonded port.'' Bonding
+ allows for load balancing and fail-over. Some kinds of bonding will
+ work with any kind of upstream switch:
+
+
+ balance-slb
+ -
+ Balances flows among slaves based on source MAC address and output
+ VLAN, with periodic rebalancing as traffic patterns change.
+
+
+ active-backup
+ -
+ Assigns all flows to one slave, failing over to a backup slave when
+ the active slave is disabled.
+
+
+
+
+ The following modes require the upstream switch to support 802.3ad with
+ successful LACP negotiation. If LACP negotiation fails then
+ balance-slb
style flow hashing is used as a fallback:
+
+
+
+ balance-tcp
+ -
+ Balances flows among slaves based on L2, L3, and L4 protocol
+ information such as destination MAC address, IP address, and TCP
+ port.
+
+
+
+
+ stable
+ -
+
Attempts to always assign a given flow to the same slave
+ consistently. In an effort to maintain stability, no load
+ balancing is done. Uses a similar hashing strategy to
+ balance-tcp
, falling back to balance-slb
+ style hashing when LACP negotiations are unsuccessful.
+ Slave selection decisions are made based on LACP port ID when LACP
+ negotiations are successful, falling back to openflow port number
+ when unsuccessful. Thus, decisions are consistent across all
+ ovs-vswitchd instances with equivalent port IDs.
+
+
These columns apply only to bonded ports. Their values are
otherwise ignored.
+
+ The type of bonding used for a bonded port. Defaults to
+ balance-slb
if unset.
+
+
+
For a bonded port, the number of milliseconds for which carrier must
stay up on an interface before the interface is considered to be up.
@@ -269,13 +574,25 @@
name of the port. Use only for compatibility with legacy software that
requires this.
+
+
+ Configures LACP on this port. LACP allows directly connected
+ switchs to negotiate which links may be bonded. LACP may be enabled
+ on non-bonded ports for the benefit of any switchs 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 unset Open vSwitch will
+ choose a reasonable default.
+
+
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 65280, exclusive, or 65534, the
+ (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.
@@ -383,15 +750,115 @@
-
- Maximum burst size for data received on this interface, in kb. The
- default burst size if set to 0
is 1000 kb. This value
- has no effect if
- is 0
.
- The burst size should be at least the size of the interface's
- MTU.
+
+
+ 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.
+
-
- Maximum rate for data received on this interface, in kbps. Data
- received faster than this rate is dropped. Set to 0
to
- disable policing.
- The meaning of ``ingress'' is from Open vSwitch's perspective. If
- configured on a physical interface, then it limits the rate at which
- traffic is allowed into the system from the outside. If configured
- on a virtual interface that is connected to a virtual machine, then
- it limits the rate at which the guest is able to transmit.
+
+
+ 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.
+
-
-
-
- Key-value pairs that identify this interface's role in external
- systems. All of the currently defined key-value pairs specifically
- apply to an interface that represents a virtual Ethernet interface
- connected to a virtual machine. These key-value pairs should not be
- present for other types of interfaces. Keys whose names end
- in -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 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.
+
+
+
+
+
+ Key-value pairs that report port status. Supported status
+ values are type
-dependent; some interfaces may not have
+ a valid driver_name
, for example.
+
The currently defined key-value pairs are:
- vif-uuid
+ driver_name
+ - The name of the device driver controlling the network
+ adapter.
+
+
+ driver_version
+ - The version string of the device driver controlling the
+ network adapter.
+
+
+ firmware_version
+ - The version string of the network adapter's firmware, if
+ available.
+
+
+ source_ip
+ - The source IP address used for an IPv4 tunnel end-point,
+ such as
gre
or capwap
.
+
+
+ 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.
+
+
+ tunnel_egress_iface_carrier
+ - Whether a carrier is detected on
. Valid values are down
+ and up
.
+
+
+
+
+
+
+ These settings control ingress policing for packets received on this
+ interface. On a physical interface, this limits the rate at which
+ traffic is allowed into the system from the outside; on a virtual
+ interface (one connected to a virtual machine), this limits the rate at
+ which the VM is able to transmit.
+
+
+ Policing is a simple form of quality-of-service that simply drops
+ packets received in excess of the configured rate. Due to its
+ simplicity, policing is usually less accurate and less effective than
+ egress QoS (which is configured using the and tables).
+
+
+ Policing is currently implemented only on Linux. The Linux
+ implementation uses a simple ``token bucket'' approach:
+
+
+ -
+ The size of the bucket corresponds to
. Initially the bucket is full.
+
+ -
+ Whenever a packet is received, its size (converted to tokens) is
+ compared to the number of tokens currently in the bucket. If the
+ required number of tokens are available, they are removed and the
+ packet is forwarded. Otherwise, the packet is dropped.
+
+ -
+ Whenever it is not full, the bucket is refilled with tokens at the
+ rate specified by
.
+
+
+
+ Policing interacts badly with some network protocols, and especially
+ with fragmented IP packets. Suppose that there is enough network
+ activity to keep the bucket nearly empty all the time. Then this token
+ bucket algorithm will forward a single packet every so often, with the
+ period depending on packet size and on the configured rate. All of the
+ fragments of an IP packets are normally transmitted back-to-back, as a
+ group. In such a situation, therefore, only one of these fragments
+ will be forwarded and the rest will be dropped. IP does not provide
+ any way for the intended recipient to ask for only the remaining
+ fragments. In such a case there are two likely possibilities for what
+ will happen next: either all of the fragments will eventually be
+ retransmitted (as TCP will do), in which case the same problem will
+ recur, or the sender will not realize that its packet has been dropped
+ and data will simply be lost (as some UDP-based protocols will do).
+ Either way, it is possible that no forward progress will ever occur.
+
+
+
+ Maximum rate for data received on this interface, in kbps. Data
+ received faster than this rate is dropped. Set to 0
+ (the default) to disable policing.
+
+
+
+
+ Maximum burst size for data received on this interface, in kb. The
+ default burst size if set to 0
is 1000 kb. This value
+ has no effect if
+ is 0
.
+
+ Specifying a larger burst size lets the algorithm be more forgiving,
+ which is important for protocols like TCP that react severely to
+ dropped packets. The burst size should be at least the size of the
+ interface's MTU. Specifying a value that is numerically at least as
+ large as 10% of helps TCP come
+ closer to achieving the full rate.
+
+
+
+
+
+
+
+ Connectivity monitor configuration for this interface.
+
+
+
+ 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 for use by external frameworks that integrate
+ with Open vSwitch, rather than by Open vSwitch itself. System
+ integrators should either use the Open vSwitch development
+ mailing list to coordinate on common key-value definitions, or
+ choose key names that are likely to be unique. The currently
+ defined common key-value pairs are:
+
+ attached-mac
+ -
+ The MAC address programmed into the ``virtual hardware'' for this
+ interface, in the form
+ xx:xx:xx:xx:xx:xx.
+ For Citrix XenServer, this is the value of the
MAC
+ field in the VIF record for this interface.
+ iface-id
+ - A system-unique identifier for the interface. On XenServer,
+ this will commonly be the same as
xs-vif-uuid
.
+
+
+ Additionally the following key-value pairs specifically
+ apply to an interface that represents a virtual Ethernet interface
+ connected to a virtual machine. These key-value pairs should not be
+ present for other types of interfaces. Keys whose names end
+ in -uuid
have values that uniquely identify the entity
+ in question. For a Citrix XenServer hypervisor, these values are
+ UUIDs in RFC 4122 format. Other hypervisors may use other
+ formats.
+
+ The currently defined key-value pairs for XenServer are:
+
+ xs-vif-uuid
- The virtual interface associated with this interface.
- network-uuid
+ xs-network-uuid
- The virtual network to which this interface is attached.
- vm-uuid
+ xs-vm-uuid
- The VM to which this interface belongs.
- vif-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.
+
+
+ Key-value pairs for rarely used interface features.
+
+ lacp-port-id
+ - The LACP port ID of this
. Port IDs are
+ used in LACP negotiations to identify individual ports
+ participating in a bond. Must be a number between 1 and
+ 65535.
+ lacp-port-priority
+ - The LACP port priority of this
. In
+ LACP negotiations s with numerically lower
+ priorities are preferred for aggregation. Must be a number between
+ 1 and 65535.
+
+
+
+
+
+ Key-value pairs that report interface statistics. The current
+ implementation updates these counters periodically. In the future,
+ we plan to, instead, update them when an interface is created, when
+ they are queried (e.g. using an OVSDB select
operation),
+ and just before an interface is deleted due to virtual interface
+ hot-unplug or VM shutdown, and perhaps at other times, but not on any
+ regular periodic basis.
+
+ The currently defined key-value pairs are listed below. These are
+ the same statistics reported by OpenFlow in its struct
+ ofp_port_stats
structure. If an interface does not support a
+ given statistic, then that pair is omitted.
+
+ -
+ Successful transmit and receive counters:
+
+ rx_packets
+ - Number of received packets.
+ rx_bytes
+ - Number of received bytes.
+ tx_packets
+ - Number of transmitted packets.
+ tx_bytes
+ - Number of transmitted bytes.
+
+
+ -
+ Receive errors:
+
+ rx_dropped
+ - Number of packets dropped by RX.
+ rx_frame_err
+ - Number of frame alignment errors.
+ rx_over_err
+ - Number of packets with RX overrun.
+ rx_crc_err
+ - Number of CRC errors.
+ rx_errors
+ -
+ Total number of receive errors, greater than or equal
+ to the sum of the above.
+
+
+
+ -
+ Transmit errors:
+
+ tx_dropped
+ - Number of packets dropped by TX.
+ collisions
+ - Number of collisions.
+ tx_errors
+ -
+ Total number of transmit errors, greater
+ than or equal to the sum of the above.
+
+
+
+
+
@@ -543,7 +1370,20 @@
defined types are listed below:
linux-htb
- - Linux ``hierarchy token bucket'' classifier.
+ -
+ Linux ``hierarchy token bucket'' classifier. See tc-htb(8) (also at
+
http://linux.die.net/man/8/tc-htb
) and the HTB manual
+ (http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm
)
+ for information on how this classifier works and how to configure it.
+
+
+
+ linux-hfsc
+ -
+ Linux "Hierarchical Fair Service Curve" classifier.
+ See
http://linux-ip.net/articles/hfsc.en/
for
+ information on how this classifier works.
+
@@ -559,8 +1399,8 @@
Key-value pairs for configuring QoS features that depend on
.
- The linux-htb
class supports the following key-value
- pairs:
+ The linux-htb
and linux-hfsc
classes support
+ the following key-value pairs:
max-rate
- Maximum rate shared by all queued traffic, in bit/s.
@@ -570,6 +1410,14 @@
Mbps.
+
+
+ Key-value pairs for use by external frameworks that integrate with Open
+ vSwitch, rather than by Open vSwitch itself. System integrators should
+ either use the Open vSwitch development mailing list to coordinate on
+ common key-value definitions, or choose key names that are likely to be
+ unique. No common key-value pairs are currently defined.
+
@@ -585,13 +1433,14 @@
column="type"/> of min-rate
are:
min-rate
- - Minimum guaranteed bandwidth, in bit/s. Required.
+ - Minimum guaranteed bandwidth, in bit/s. Required. The
+ floor value is 1500 bytes/s (12,000 bit/s).
The key-value pairs defined for of linux-htb
are:
min-rate
- - Minimum guaranteed bandwidth, in bit/s. Required.
+ - Minimum guaranteed bandwidth, in bit/s.
max-rate
- Maximum allowed bandwidth, in bit/s. Optional. If specified, the
queue's rate will not be allowed to exceed the specified value, even
@@ -610,9 +1459,104 @@
a queue with a larger value receives any. Specific priority
values are unimportant; only relative ordering matters.
+ The key-value pairs defined for of linux-hfsc
are:
+
+ min-rate
+ - Minimum guaranteed bandwidth, in bit/s.
+ max-rate
+ - Maximum allowed bandwidth, in bit/s. Optional. If specified, the
+ queue's rate will not be allowed to exceed the specified value, even
+ if excess bandwidth is available. If unspecified, defaults to no
+ limit.
+
+
+
+
+ Key-value pairs for use by external frameworks that integrate with Open
+ vSwitch, rather than by Open vSwitch itself. System integrators should
+ either use the Open vSwitch development mailing list to coordinate on
+ common key-value definitions, or choose key names that are likely to be
+ unique. No common key-value pairs are currently defined.
+
+
+ A attaches to an to
+ implement 802.1ag Connectivity Fault Management (CFM). CFM allows a
+ group of Maintenance Points (MPs) called a Maintenance Association (MA)
+ to detect connectivity problems with each other. MPs within a MA should
+ have complete and exclusive interconnectivity. This is verified by
+ occasionally broadcasting Continuity Check Messages (CCMs) at a
+ configurable transmission interval. A is
+ responsible for collecting data about other MPs in its MA and
+ broadcasting CCMs.
+
+
+
+
+ A Maintenance Point ID (MPID) uniquely identifies each endpoint within
+ a Maintenance Association (see ). The MPID is
+ used to identify this to other endpoints in the
+ MA.
+
+
+
+ A set of which this
+ should have connectivity to. If this
+ does not have connectivity to any MPs in this
+ set, or has connectivity to any MPs not in this set, a fault is
+ signaled.
+
+
+
+ A Maintenance Association (MA) name pairs with a Maintenance Domain
+ (MD) name to uniquely identify a MA. A MA is a group of endpoints who
+ have complete and exclusive interconnectivity. Defaults to
+ ovs
if unset.
+
+
+
+ A Maintenance Domain name pairs with a Maintenance Association name to
+ uniquely identify a MA. Defaults to ovs
if unset.
+
+
+
+ The transmission interval of CCMs in milliseconds. Three missed CCMs
+ indicate a connectivity fault. Defaults to 1000ms.
+
+
+
+
+
+ Indicates a Connectivity Fault caused by a configuration error, a down
+ remote MP, or unexpected connectivity to a remote MAID or remote MP.
+
+
+
+
+
+
+ A represents a MP which a
+ has or should have connectivity to.
+
+
+
+
+ A Maintenance Point ID (MPID) uniquely identifies each endpoint within
+ a Maintenance Association. All MPs within a MA should have a unique
+ MPID.
+
+
+
+
+
+ Indicates a connectivity fault.
+
+
+
+
A port mirror within a .
A port mirror configures a bridge to send selected frames to special
@@ -625,6 +1569,12 @@
+
+ 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.
@@ -645,9 +1595,13 @@
+
+ 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
@@ -656,8 +1610,7 @@
- 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
@@ -692,31 +1645,95 @@
in the appropriate table or tables.
+
+
+
+ Key-value pairs for use by external frameworks that integrate with Open
+ vSwitch, rather than by Open vSwitch itself. System integrators should
+ either use the Open vSwitch development mailing list to coordinate on
+ common key-value definitions, or choose key names that are likely to be
+ unique. No common key-value pairs are currently defined.
+
+
An OpenFlow controller.
- Open vSwitch permits a bridge to have any number of OpenFlow
- controllers. When multiple controllers are configured, Open vSwitch
- connects to all of them simultaneously. OpenFlow 1.0 does not specify
- how multiple controllers coordinate in interacting with a single switch,
- so more than one controller should be specified only if the controllers
- are themselves designed to coordinate with each other.
+
+ Open vSwitch supports two kinds of OpenFlow controllers:
+
+
+
+ - Primary controllers
+ -
+
+ This is the kind of controller envisioned by the OpenFlow 1.0
+ specification. Usually, a primary controller implements a network
+ policy by taking charge of the switch's flow table.
+
+
+
+ Open vSwitch initiates and maintains persistent connections to
+ primary controllers, retrying the connection each time it fails or
+ drops. The column in the
+ table applies to primary controllers.
+
+
+
+ Open vSwitch permits a bridge to have any number of primary
+ controllers. When multiple controllers are configured, Open
+ vSwitch connects to all of them simultaneously. Because
+ OpenFlow 1.0 does not specify how multiple controllers
+ coordinate in interacting with a single switch, more than
+ one primary controller should be specified only if the
+ controllers are themselves designed to coordinate with each
+ other. (The Nicira-defined NXT_ROLE
OpenFlow
+ vendor extension may be useful for this.)
+
+
+ - Service controllers
+ -
+
+ These kinds of OpenFlow controller connections are intended for
+ occasional support and maintenance use, e.g. with
+ ovs-ofctl
. Usually a service controller connects only
+ briefly to inspect or modify some of a switch's state.
+
+
+
+ Open vSwitch listens for incoming connections from service
+ controllers. The service controllers initiate and, if necessary,
+ maintain the connections from their end. The column in the table does
+ not apply to service controllers.
+
+
+
+ Open vSwitch supports configuring any number of service controllers.
+
+
+
+
+
+ The determines the type of controller.
+
- Connection method for controller.
- The following connection methods are currently
- supported:
+ Connection method for controller.
+
+ The following connection methods are currently supported for primary
+ controllers:
+
ssl:ip
[:port
]
-
The specified SSL port (default: 6633) on the host at
- the given ip, which must be expressed as an IP address
- (not a DNS name). The
- column in the must point to a valid
- SSL configuration when this form is used.
+ the given ip, which must be expressed as an IP address
+ (not a DNS name). The
+ column in the table must point to a
+ valid SSL configuration when this form is used.
SSL support is an optional feature that is not always built as
part of Open vSwitch.
@@ -724,59 +1741,66 @@
- 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
+
+
+ The following connection methods are currently supported for service
+ controllers:
+
+
+ pssl:
[port][:ip
]
+ -
+
+ Listens for SSL connections on the specified TCP port
+ (default: 6633). If ip, which must be expressed as an
+ IP address (not a DNS name), is specified, then connections are
+ restricted to the specified local IP address.
+
+
+ The column in the table must point to a valid SSL
+ configuration when this form is used.
+
+ SSL support is an optional feature that is not always built as
+ part of Open vSwitch.
+
+ ptcp:
[port][:ip
]
-
-
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.
+ 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.
- none
- - Disables the controller.
- When multiple controllers are configured for a single bridge, the
- values must be unique. Duplicate
- values yield unspecified results.
+ When multiple controllers are configured for a single bridge, the
+ values must be unique. Duplicate
+ values yield unspecified results.
- If it is specified, this setting must be one of the following
- strings that describes how Open vSwitch contacts this OpenFlow
- controller over the network:
-
-
- in-band
- - In this mode, this controller's OpenFlow traffic travels over the
- bridge associated with the controller. With this setting, Open
- vSwitch allows traffic to and from the controller regardless of the
- contents of the OpenFlow flow table. (Otherwise, Open vSwitch
- would never be able to connect to the controller, because it did
- not have a flow to enable it.) This is the most common connection
- mode because it is not necessary to maintain two independent
- networks.
- out-of-band
- - In this mode, OpenFlow traffic uses a control network separate
- from the bridge associated with this controller, that is, the
- bridge does not use any of its own network devices to communicate
- with the controller. The control network must be configured
- separately, before or after
ovs-vswitchd
is started.
-
-
-
- If not specified, the default is implementation-specific. If
- is discover
, the connection mode
- is always treated as in-band
regardless of the actual
- setting.
+ If it is specified, this setting must be one of the following
+ strings that describes how Open vSwitch contacts this OpenFlow
+ controller over the network:
+
+
+ in-band
+ - In this mode, this controller's OpenFlow traffic travels over the
+ bridge associated with the controller. With this setting, Open
+ vSwitch allows traffic to and from the controller regardless of the
+ contents of the OpenFlow flow table. (Otherwise, Open vSwitch
+ would never be able to connect to the controller, because it did
+ not have a flow to enable it.) This is the most common connection
+ mode because it is not necessary to maintain two independent
+ networks.
+ out-of-band
+ - In this mode, OpenFlow traffic uses a control network separate
+ from the bridge associated with this controller, that is, the
+ bridge does not use any of its own network devices to communicate
+ with the controller. The control network must be configured
+ separately, before or after
ovs-vswitchd
is started.
+
+
+
+ If not specified, the default is implementation-specific.
@@ -793,44 +1817,8 @@
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.
-
-
-
- When a controller is configured, it is, ordinarily, responsible
- for setting up all flows on the switch. Thus, if the connection to
- the controller fails, no new network connections can be set up.
- If the connection to the controller stays down long enough,
- no packets can pass through the switch at all. This setting
- determines the switch's response to such a situation. It may be set
- to one of the following:
-
- standalone
- - If no message is received from the controller for three
- times the inactivity probe interval
- (see
), then Open vSwitch
- will take over responsibility for setting up flows. In
- this mode, Open vSwitch causes the bridge to act like an
- ordinary MAC-learning switch. Open vSwitch will continue
- to retry connecting to the controller in the background
- and, when the connection succeeds, it will discontinue its
- standalone behavior.
- secure
- - Open vSwitch will not set up flows on its own when the
- controller connection fails. It will continue retry
- connecting to the controller forever.
-
-
- If this value is unset, the default is implementation-specific.
- When more than one controller is configured,
- is considered only when none of the
- configured controllers can be contacted. At that point, the bridge
- enters secure mode if any of the controllers'
- is set to secure
. Otherwise,
- it enters standalone mode if at least one
- is set to standalone
. If none of the
- values are set, the default is
- implementation-defined.
+ Default is implementation-specific. A value of 0 disables
+ inactivity probes.
@@ -863,38 +1851,14 @@
-
- These values are considered only when
- is discover
.
-
-
- 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.
-
-
-
- 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.
-
-
-
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,
@@ -916,6 +1880,250 @@
this network has no gateway.
+
+
+
+ Key-value pairs for use by external frameworks that integrate with Open
+ vSwitch, rather than by Open vSwitch itself. System integrators should
+ either use the Open vSwitch development mailing list to coordinate on
+ common key-value definitions, or choose key names that are likely to be
+ unique. No common key-value pairs are currently defined.
+
+
+
+
+
+ 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.
+
+
+
+
+ Key-value pairs that report controller status.
+
+ last_error
+ - 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.
+ state
+ - The state of the connection to the controller. Possible values
+ are:
VOID
(connection is disabled),
+ BACKOFF
(attempting to reconnect at an increasing
+ period), CONNECTING
(attempting to connect),
+ ACTIVE
(connected, remote host responsive), and
+ IDLE
(remote host idle, sending keep-alive). These
+ values may change in the future. They are provided only for human
+ consumption.
+ sec_since_connect
+ - The amount of time since this controller last successfully
+ connected to the switch (in seconds). Value is empty if controller
+ has never successfully connected.
+ sec_since_disconnect
+ - The amount of time since this controller last disconnected from
+ the switch (in seconds). Value is empty if controller has never
+ disconnected.
+
+
+
+
+
+
+
+ Configuration for a database connection to an Open vSwitch database
+ (OVSDB) client.
+
+
+
+ This table primarily configures the Open vSwitch database
+ (ovsdb-server
), not the Open vSwitch switch
+ (ovs-vswitchd
). The switch does read the table to determine
+ what connections should be treated as in-band.
+
+
+
+ The Open vSwitch database server can initiate and maintain active
+ connections to remote clients. It can also listen for database
+ connections.
+
+
+
+
+ Connection method for managers.
+
+ The following connection methods are currently supported:
+
+
+ ssl:ip
[:port
]
+ -
+
+ The specified SSL port (default: 6632) on the host at
+ the given ip, which must be expressed as an IP address
+ (not a DNS name). The
+ column in the table must point to a
+ valid SSL configuration when this form is used.
+
+
+ SSL support is an optional feature that is not always built as
+ part of Open vSwitch.
+
+
+
+ tcp:ip
[:port
]
+ -
+ The specified TCP port (default: 6632) on the host at
+ the given ip, which must be expressed as an IP address
+ (not a DNS name).
+
+ pssl:
[port][:ip
]
+ -
+
+ Listens for SSL connections on the specified TCP port
+ (default: 6632). If ip, which must be expressed as an
+ IP address (not a DNS name), is specified, then connections are
+ restricted to the specified local IP address.
+
+
+ The column in the table must point to a valid SSL
+ configuration when this form is used.
+
+
+ SSL support is an optional feature that is not always built as
+ part of Open vSwitch.
+
+
+ ptcp:
[port][:ip
]
+ -
+ Listens for connections on the specified TCP port
+ (default: 6632). If ip, which must be expressed as an
+ IP address (not a DNS name), is specified, then connections are
+ restricted to the specified local IP address.
+
+
+ When multiple managers are configured, the
+ values must be unique. Duplicate values yield
+ unspecified results.
+
+
+
+
+ If it is specified, this setting must be one of the following strings
+ that describes how Open vSwitch contacts this OVSDB client over the
+ network:
+
+
+
+ in-band
+ -
+ In this mode, this connection's traffic travels over a bridge
+ managed by Open vSwitch. With this setting, Open vSwitch allows
+ traffic to and from the client regardless of the contents of the
+ OpenFlow flow table. (Otherwise, Open vSwitch would never be able
+ to connect to the client, because it did not have a flow to enable
+ it.) This is the most common connection mode because it is not
+ necessary to maintain two independent networks.
+
+ out-of-band
+ -
+ In this mode, the client's traffic uses a control network separate
+ from that managed by Open vSwitch, that is, Open vSwitch does not
+ use any of its own network devices to communicate with the client.
+ The control network must be configured separately, before or after
+
ovs-vswitchd
is started.
+
+
+
+
+ If not specified, the default is implementation-specific.
+
+
+
+
+
+
+ Maximum number of milliseconds to wait between connection attempts.
+ Default is implementation-specific.
+
+
+
+ Maximum number of milliseconds of idle time on connection to the client
+ before sending an inactivity probe message. If Open vSwitch does not
+ communicate with the client for the specified number of seconds, it
+ will send a probe. If a response is not received for the same
+ additional amount of time, Open vSwitch assumes the connection has been
+ broken and attempts to reconnect. Default is implementation-specific.
+ 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.
+
+
+
+ Key-value pairs that report manager status.
+
+ last_error
+ - 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.
+
+
+ state
+ - The state of the connection to the manager. Possible values
+ are:
VOID
(connection is disabled),
+ BACKOFF
(attempting to reconnect at an increasing
+ period), CONNECTING
(attempting to connect),
+ ACTIVE
(connected, remote host responsive), and
+ IDLE
(remote host idle, sending keep-alive). These
+ values may change in the future. They are provided only for human
+ consumption.
+
+
+ sec_since_connect
+ - The amount of time since this manager last successfully connected
+ to the database (in seconds). Value is empty if manager has never
+ successfully connected.
+
+
+ sec_since_disconnect
+ - The amount of time since this manager last disconnected from the
+ database (in seconds). Value is empty if manager has never
+ disconnected.
+
+
+
@@ -957,6 +2165,14 @@
disambiguate the traffic.
When this option is enabled, a maximum of 508 ports are supported.
+
+
+ Key-value pairs for use by external frameworks that integrate with Open
+ vSwitch, rather than by Open vSwitch itself. System integrators should
+ either use the Open vSwitch development mailing list to coordinate on
+ common key-value definitions, or choose key names that are likely to be
+ unique. No common key-value pairs are currently defined.
+
@@ -989,6 +2205,14 @@
SSL connection to a man-in-the-middle attack obtaining the initial
CA certificate. It may still be useful for bootstrapping.
+
+
+ Key-value pairs for use by external frameworks that integrate with Open
+ vSwitch, rather than by Open vSwitch itself. System integrators should
+ either use the Open vSwitch development mailing list to coordinate on
+ common key-value definitions, or choose key names that are likely to be
+ unique. No common key-value pairs are currently defined.
+
@@ -1023,6 +2247,14 @@
sFlow targets in the form
ip:port
.
+
+
+ Key-value pairs for use by external frameworks that integrate with Open
+ vSwitch, rather than by Open vSwitch itself. System integrators should
+ either use the Open vSwitch development mailing list to coordinate on
+ common key-value definitions, or choose key names that are likely to be
+ unique. No common key-value pairs are currently defined.
+