+
+ These options apply to interfaces with of
+ gre
, ipsec_gre
, and capwap
.
+
-
- 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.
+
+ Each tunnel must be uniquely identified by the combination of , , , and . If two ports are defined that are the same except one
+ has an optional identifier and the other does not, the more specific
+ one is matched first. is
+ considered more specific than if
+ a port defines one and another port defines the other.
+
+
+
+
+ Required. The tunnel endpoint. Unicast and multicast endpoints are
+ both supported.
+
+
+
+ When a multicast endpoint is specified, a routing table lookup occurs
+ only when the tunnel is created. Following a routing change, delete
+ and then re-create the tunnel to force a new routing table lookup.
+
-
-
- An OpenFlow controller.
+
+ Optional. If enabled, the Don't Fragment bit will be set by default on
+ tunnel headers if the df_inherit
option is not set, or if
+ the encapsulated packet is not IP. Default is enabled; set to
+ false
to disable.
+
-
+
+ Optional. Enable tunnel path MTU discovery. If enabled ``ICMP
+ Destination Unreachable - Fragmentation Needed'' messages will be
+ generated for IPv4 packets with the DF bit set and IPv6 packets above
+ the minimum MTU if the packet size exceeds the path MTU minus the size
+ of the tunnel headers. Note that this option causes behavior that is
+ typically reserved for routers and therefore is not entirely in
+ compliance with the IEEE 802.1D specification for bridges. Default is
+ enabled; set to false
to disable.
+
+
+
+
+ Only gre
interfaces support these options.
+
+
+
+ Enable caching of tunnel headers and the output path. This can lead
+ to a significant performance increase without changing behavior. In
+ general it should not be necessary to adjust this setting. However,
+ the caching can bypass certain components of the IP stack (such as
+ iptables
) and it may be useful to disable it if these
+ features are required or as a debugging measure. Default is enabled,
+ set to false
to disable.
+
+
+
+
+
+ Only gre
and ipsec_gre
interfaces support
+ these options.
+
+
+
+
+ Optional. Compute GRE checksums on outgoing packets. Default is
+ disabled, set to true
to enable. Checksums present on
+ incoming packets will be validated regardless of this setting.
+
+
+
+ GRE checksums impose a significant performance penalty because they
+ cover the entire packet. The encapsulated L3, L4, and L7 packet
+ contents typically have their own checksums, so this additional
+ checksum only adds value for the GRE and encapsulated L2 headers.
+
+
+
+ This option is supported for ipsec_gre
, but not useful
+ because GRE checksums are weaker than, and redundant with, IPsec
+ payload authentication.
+
+
+
+
+
+
+ Only ipsec_gre
interfaces support these options.
+
+
+
+ Required for certificate authentication. A string containing the
+ peer's certificate in PEM format. Additionally the host's
+ certificate must be specified with the certificate
+ option.
+
+
+
+ Required for certificate authentication. The name of a PEM file
+ containing a certificate that will be presented to the peer during
+ authentication.
+
+
+
+ Optional for certificate authentication. The name of a PEM file
+ containing the private key associated with certificate
.
+ If certificate
contains the private key, this option may
+ be omitted.
+
+
+
+ Required for pre-shared key authentication. Specifies a pre-shared
+ key for authentication that must be identical on both sides of the
+ tunnel.
+
+
+
+
+
+
+ Only patch
interfaces support these options.
+
+
+
+ The of the for the other
+ side of the patch. The named 's own
+ peer
option must specify this 's
+ name. That is, the two patch interfaces must have reversed and peer
values.
+
+
+
+
+
+ Status information about interfaces attached to bridges, updated every
+ 5 seconds. Not all interfaces have all of these properties; virtual
+ interfaces don't have a link speed, for example. Non-applicable
+ columns will have empty values.
+
+
+
+ The administrative state of the physical network link.
+
+
+
+
+
+ The observed state of the physical network link. This is ordinarily
+ the link's carrier status. If the interface's is
+ a bond configured for miimon monitoring, it is instead the network
+ link's miimon status.
+
+
+
+
+
+ The number of times Open vSwitch has observed the
+ of this change.
+
+
+
+
+
+ The negotiated speed of the physical network link.
+ Valid values are positive integers greater than 0.
+
+
+
+
+
+ The duplex mode of the physical network link.
+
+
+
+
+
+ The MTU (maximum transmission unit); i.e. the largest
+ amount of data that can fit into a single Ethernet frame.
+ The standard Ethernet MTU is 1500 bytes. Some physical media
+ and many kinds of virtual interfaces can be configured with
+ higher MTUs.
+
+
+ This column will be empty for an interface that does not
+ have an MTU as, for example, some kinds of tunnels do not.
+
+
+
+
+ Boolean value indicating LACP status for this interface. If true, this
+ interface has current LACP information about its LACP partner. This
+ information may be used to monitor the health of interfaces in a LACP
+ enabled port. This column will be empty if LACP is not enabled.
+
+
+
+ Key-value pairs that report port status. Supported status values are
+ -dependent; some interfaces may not have a valid
+ , for example.
+
+
+
+ The name of the device driver controlling the network adapter.
+
+
+
+ The version string of the device driver controlling the network
+ adapter.
+
+
+
+ The version string of the network adapter's firmware, if available.
+
+
+
+ The source IP address used for an IPv4 tunnel end-point, such as
+ gre
or capwap
.
+
+
+
+ Egress interface for tunnels. Currently only relevant for GRE and
+ CAPWAP tunnels. On Linux systems, this column will show the name of
+ the interface which is responsible for routing traffic destined for the
+ configured . This could be an
+ internal interface such as a bridge port.
+
+
+
+ Whether carrier is detected on .
+
+
+
+
+
+ Key-value pairs that report interface statistics. The current
+ implementation updates these counters periodically. Future
+ implementations may update them when an interface is created, when they
+ are queried (e.g. using an OVSDB select
operation), and
+ just before an interface is deleted due to virtual interface hot-unplug
+ or VM shutdown, and perhaps at other times, but not on any regular
+ periodic basis.
+
+
+ These are the same statistics reported by OpenFlow in its struct
+ ofp_port_stats
structure. If an interface does not support a
+ given statistic, then that pair is omitted.
+
+
+
+ Number of received packets.
+
+
+ Number of received bytes.
+
+
+ Number of transmitted packets.
+
+
+ Number of transmitted bytes.
+
+
+
+
+ Number of packets dropped by RX.
+
+
+ Number of frame alignment errors.
+
+
+ Number of packets with RX overrun.
+
+
+ Number of CRC errors.
+
+
+ Total number of receive errors, greater than or equal to the sum of
+ the above.
+
+
+
+
+ Number of packets dropped by TX.
+
+
+ Number of collisions.
+
+
+ Total number of transmit errors, greater than or equal to the sum of
+ the above.
+
+
+
+
+
+
+ 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.
+
+
+
+
+
+
+ 802.1ag Connectivity Fault Management (CFM) allows a group of
+ Maintenance Points (MPs) called a Maintenance Association (MA) to
+ detect connectivity problems with each other. MPs within a MA should
+ have complete and exclusive interconnectivity. This is verified by
+ occasionally broadcasting Continuity Check Messages (CCMs) at a
+ configurable transmission interval.
+
+
+
+ According to the 802.1ag specification, each Maintenance Point should
+ be configured out-of-band with a list of Remote Maintenance Points it
+ should have connectivity to. Open vSwitch differs from the
+ specification in this area. It simply assumes the link is faulted if
+ no Remote Maintenance Points are reachable, and considers it not
+ faulted otherwise.
+
+
+
+ A Maintenance Point ID (MPID) uniquely identifies each endpoint within
+ a Maintenance Association. The MPID is used to identify this endpoint
+ to other Maintenance Points in the MA. Each end of a link being
+ monitored should have a different MPID. Must be configured to enable
+ CFM on this .
+
+
+
+
+ Indicates a connectivity fault triggered by an inability to receive
+ heartbeats from any remote endpoint. When a fault is triggered on
+ s participating in bonds, they will be
+ disabled.
+
+
+ Faults can be triggered for several reasons. Most importantly they
+ are triggered when no CCMs are received for a period of 3.5 times the
+ transmission interval. Faults are also triggered when any CCMs
+ indicate that a Remote Maintenance Point is not receiving CCMs but
+ able to send them. Finally, a fault is triggered if a CCM is
+ received which indicates unexpected configuration. Notably, this
+ case arises when a CCM is received which advertises the local MPID.
+
+
+
+
+ When CFM is properly configured, Open vSwitch will occasionally
+ receive CCM broadcasts. These broadcasts contain the MPID of the
+ sending Maintenance Point. The list of MPIDs from which this
+ is receiving broadcasts from is regularly
+ collected and written to this column.
+
+
+
+ The interval, in milliseconds, between transmissions of CFM heartbeats.
+ Three missed heartbeat receptions indicate a connectivity fault.
+ Defaults to 1000.
+
+
+
+ When true
, the CFM module operates in extended mode. This
+ causes it to use a nonstandard destination address to avoid conflicting
+ with compliant implementations which may be running concurrently on the
+ network. Furthermore, extended mode increases the accuracy of the
+ cfm_interval
configuration parameter by breaking wire
+ compatibility with 802.1ag compliant implementations. Defaults to
+ false
.
+
+
+ When down
, the CFM module marks all CCMs it generates as
+ operationally down without triggering a fault. This allows remote
+ maintenance points to choose not to forward traffic to the
+ on which this CFM module is running.
+ Currently, in Open vSwitch, the opdown bit of CCMs affects
+ s participating in bonds, and the bundle
+ OpenFlow action. This setting is ignored when CFM is not in extended
+ mode. Defaults to up
.
+
+
+
+ When set, the CFM module will apply a VLAN tag to all CCMs it generates
+ with the given value.
+
+
+
+
+
+
+ Used in stable
bond mode to make slave
+ selection decisions. Allocating values consistently across interfaces
+ participating in a bond will guarantee consistent slave selection
+ decisions across ovs-vswitchd
instances when using
+ stable
bonding mode.
+
+
+
+ The LACP port ID of this . Port IDs are
+ used in LACP negotiations to identify individual ports
+ participating in a bond.
+
+
+
+ The LACP port priority of this . In LACP
+ negotiations s with numerically lower
+ priorities are preferred for aggregation.
+
+
+
+ The LACP aggregation key of this . s with different aggregation keys may not be active
+ within a given at the same time.
+
+
+
+
+
+ These key-value pairs specifically apply to an interface that
+ represents a virtual Ethernet interface connected to a virtual
+ machine. These key-value pairs should not be present for other types
+ of interfaces. Keys whose names end in -uuid
have
+ values that uniquely identify the entity in question. For a Citrix
+ XenServer hypervisor, these values are UUIDs in RFC 4122 format.
+ Other hypervisors may use other formats.
+
+
+
+ The MAC address programmed into the ``virtual hardware'' for this
+ interface, in the form
+ xx:xx:xx:xx:xx:xx.
+ For Citrix XenServer, this is the value of the MAC
field
+ in the VIF record for this interface.
+
+
+
+ A system-unique identifier for the interface. On XenServer, this will
+ commonly be the same as .
+
+
+
+ The virtual interface associated with this interface.
+
+
+
+ The virtual network to which this interface is attached.
+
+
+
+ The VM to which this interface belongs.
+
+
+
+
+
+ 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.
+
+
+
+
+
+ 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 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.
+
+
+
+ Ports on which departing packets are selected for mirroring.
+
+
+
+ Ports on which arriving packets are selected for mirroring.
+
+
+
+ VLANs on which packets are selected for mirroring. An empty set
+ selects packets on all VLANs.
+
+
+
+
+
+ These columns are mutually exclusive. Exactly one of them must be
+ nonempty.
+
+
+
+ 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
+ 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.
+ 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.
+
+ The following destination MAC addresses will not be mirrored to a
+ VLAN to avoid confusing switches that interpret the protocols that
+ they represent:
+
+
+ 01:80:c2:00:00:00
+ - IEEE 802.1D Spanning Tree Protocol (STP).
+
+ 01:80:c2:00:00:01
+ - IEEE Pause frame.
+
+ 01:80:c2:00:00:0x
+ - Other reserved protocols.
+
+ 01:00:0c:cc:cc:cc
+ -
+ Cisco Discovery Protocol (CDP), VLAN Trunking Protocol (VTP),
+ Dynamic Trunking Protocol (DTP), Port Aggregation Protocol (PAgP),
+ and others.
+
+
+ 01:00:0c:cc:cc:cd
+ - Cisco Shared Spanning Tree Protocol PVSTP+.
+
+ 01:00:0c:cd:cd:cd
+ - Cisco STP Uplink Fast.
+
+ 01:00:0c:00:00:00
+ - Cisco Inter Switch Link.
+
+ Please note: Mirroring to a VLAN can disrupt a network that
+ contains unmanaged switches. Consider an unmanaged physical switch
+ with two ports: port 1, connected to an end host, and port 2,
+ connected to an Open vSwitch configured to mirror received packets
+ into VLAN 123 on port 2. Suppose that the end host sends a packet on
+ port 1 that the physical switch forwards to port 2. The Open vSwitch
+ forwards this packet to its destination and then reflects it back on
+ port 2 in VLAN 123. This reflected packet causes the unmanaged
+ physical switch to replace the MAC learning table entry, which
+ correctly pointed to port 1, with one that incorrectly points to port
+ 2. Afterward, the physical switch will direct packets destined for
+ the end host to the Open vSwitch on port 2, instead of to the end
+ host on port 1, disrupting connectivity. If mirroring to a VLAN is
+ desired in this scenario, then the physical switch must be replaced
+ by one that learns Ethernet addresses on a per-VLAN basis. In
+ addition, learning should be disabled on the VLAN containing mirrored
+ traffic. If this is not done then intermediate switches will learn
+ the MAC address of each end host from the mirrored traffic. If
+ packets being sent to that end host are also mirrored, then they will
+ be dropped since the switch will attempt to send them out the input
+ port. Disabling learning for the VLAN will cause the switch to
+ correctly send the packet out all ports configured for that VLAN. If
+ Open vSwitch is being used as an intermediate switch, learning can be
+ disabled by adding the mirrored VLAN to
+ in the appropriate table or tables.
+
+ Mirroring to a GRE tunnel has fewer caveats than mirroring to a
+ VLAN and should generally be preferred.
+
+
+
+
+
+
+ Key-value pairs that report mirror statistics.
+
+
+ Number of packets transmitted through this mirror.
+
+
+ Number of bytes transmitted through this mirror.
+
+
+
+
+ The overall purpose of these columns is described under Common
+ Columns
at the beginning of this document.
+
+
+
+
+
+
+ An OpenFlow controller.
+
+
+ Open vSwitch supports two kinds of OpenFlow controllers:
+
+
+
+ - Primary controllers
+ -
+
+ This is the kind of controller envisioned by the OpenFlow 1.0
+ specification. Usually, a primary controller implements a network
+ policy by taking charge of the switch's flow table.
+
+
+
+ Open vSwitch initiates and maintains persistent connections to
+ primary controllers, retrying the connection each time it fails or
+ drops. The column in the
+ table applies to primary controllers.
+
+
+
+ Open vSwitch permits a bridge to have any number of primary
+ controllers. When multiple controllers are configured, Open
+ vSwitch connects to all of them simultaneously. Because
+ OpenFlow 1.0 does not specify how multiple controllers
+ coordinate in interacting with a single switch, more than
+ one primary controller should be specified only if the
+ controllers are themselves designed to coordinate with each
+ other. (The Nicira-defined NXT_ROLE
OpenFlow
+ vendor extension may be useful for this.)
+
+
+ - Service controllers
+ -
+
+ These kinds of OpenFlow controller connections are intended for
+ occasional support and maintenance use, e.g. with
+ ovs-ofctl
. Usually a service controller connects only
+ briefly to inspect or modify some of a switch's state.
+
+
+
+ Open vSwitch listens for incoming connections from service
+ controllers. The service controllers initiate and, if necessary,
+ maintain the connections from their end. The column in the table does
+ not apply to service controllers.
+
+
+
+ Open vSwitch supports configuring any number of service controllers.
+
+
+
+
+
+ The determines the type of controller.
+
+
+
- Connection method for controller.
- The following connection methods are currently
- supported:
+ Connection method for controller.
+
+ The following connection methods are currently supported for primary
+ controllers:
+
ssl:ip
[:port
]
-
The specified SSL port (default: 6633) on the host at
- the given ip, which must be expressed as an IP address
- (not a DNS name). The
- column in the must point to a valid
- SSL configuration when this form is used.
+ the given ip, which must be expressed as an IP address
+ (not a DNS name). The
+ column in the table must point to a
+ valid SSL configuration when this form is used.
SSL support is an optional feature that is not always built as
- part of Open vSwitch.
+ 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.
- none
- - Disables the controller.
+ the given ip, which must be expressed as an IP address
+ (not a DNS name).
+
+ The following connection methods are currently supported for service
+ controllers:
+
+
+ pssl:
[port][:ip
]
+ -
+
+ Listens for SSL connections on the specified TCP port
+ (default: 6633). If ip, which must be expressed as an
+ IP address (not a DNS name), is specified, then connections are
+ restricted to the specified local IP address.
+
+
+ The column in the table must point to a valid SSL
+ configuration when this form is used.
+
+ SSL support is an optional feature that is not always built as
+ part of Open vSwitch.
+
+ ptcp:
[port][:ip
]
+ -
+ Listens for connections on the specified TCP port
+ (default: 6633). If ip, which must be expressed as an
+ IP address (not a DNS name), is specified, then connections are
+ restricted to the specified local IP address.
+
+
+ When multiple controllers are configured for a single bridge, the
+ values must be unique. Duplicate
+ values yield unspecified results.
- Either in-band
or out-of-band
. If not
- specified, the default is implementation-specific.
+ If it is specified, this setting must be one of the following
+ strings that describes how Open vSwitch contacts this OpenFlow
+ controller over the network:
+
+
+ in-band
+ - In this mode, this controller's OpenFlow traffic travels over the
+ bridge associated with the controller. With this setting, Open
+ vSwitch allows traffic to and from the controller regardless of the
+ contents of the OpenFlow flow table. (Otherwise, Open vSwitch
+ would never be able to connect to the controller, because it did
+ not have a flow to enable it.) This is the most common connection
+ mode because it is not necessary to maintain two independent
+ networks.
+ out-of-band
+ - In this mode, OpenFlow traffic uses a control network separate
+ from the bridge associated with this controller, that is, the
+ bridge does not use any of its own network devices to communicate
+ with the controller. The control network must be configured
+ separately, before or after
ovs-vswitchd
is started.
+
+
+
+ If not specified, the default is implementation-specific.
@@ -538,103 +2328,374 @@
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 datapath to act like an
- ordinary MAC-learning switch. Open vSwitch will continue
- to retry connecting to the controller in the background
- and, when the connection succeeds, it will discontinue its
- standalone behavior.
- secure
- - Open vSwitch will not set up flows on its own when the
- controller connection fails. It will continue retry
- connecting to the controller forever.
-
-
- If this value is unset, the default is
- implementation-specific.
+ Default is implementation-specific. A value of 0 disables
+ inactivity probes.
-
- In conjunction with ,
- the maximum number of unused packet credits that the bridge will
- allow to accumulate, in packets. If not specified, the default
- is implementation-specific.
-
-
-
- The maximum rate at which packets in unknown flows will be
- forwarded to the OpenFlow controller, in packets per second. This
- 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.
-
-
-
-
-
- If 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.
+
+ 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.
-
- If is discover
,
- 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.
-
-
- If is not discover
, the IP
- address of the gateway to configure on the local port.
-
+
+ These values are considered only in in-band control mode (see
+ ).
+
+ When multiple controllers are configured on a single bridge, there
+ should be only one set of unique values in these columns. If different
+ values are set for these columns in different controllers, the effect
+ is unspecified.
- If is not discover
, the IP
- address to configure on the local port.
+ The IP address to configure on the local port,
+ e.g. 192.168.0.123
. If this value is unset, then
+ and are
+ ignored.
- If is not discover
, the IP
- netmask to configure on the local port.
+ The IP netmask to configure on the local port,
+ e.g. 255.255.255.0
. If is set
+ but this value is unset, then the default is chosen based on whether
+ the IP address is class A, B, or C.
+
+
+
+ The IP address of the gateway to configure on the local port, as a
+ string, e.g. 192.168.0.1
. Leave this column unset if
+ this network has no gateway.
+
+
+
+
+
+ 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.
+
+
+
+
+ The overall purpose of these columns is described under Common
+ Columns
at the beginning of this document.
+
+
+
+
+
+
+
+ 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.
+
+
+
+
+
+ true
if currently connected to this manager,
+ false
otherwise.
+
+
+
+ A human-readable description of the last error on the connection
+ to the manager; i.e. strerror(errno)
. This key
+ will exist only if an error has occurred.
+
+
+
+
+ The state of the connection to the manager:
+
+
+ VOID
+ - Connection is disabled.
+
+ BACKOFF
+ - Attempting to reconnect at an increasing period.
+
+ CONNECTING
+ - Attempting to connect.
+
+ ACTIVE
+ - Connected, remote host responsive.
+
+ IDLE
+ - Connection is idle. Waiting for response to keep-alive.
+
+
+ These values may change in the future. They are provided only for
+ human consumption.
+
+
+
+
+ The amount of time since this manager last successfully connected
+ to the database (in seconds). Value is empty if manager has never
+ successfully connected.
+
+
+
+ The amount of time since this manager last disconnected from the
+ database (in seconds). Value is empty if manager has never
+ disconnected.
+
+
+
+ Space-separated list of the names of OVSDB locks that the connection
+ holds. Omitted if the connection does not hold any locks.
+
+
+
+ Space-separated list of the names of OVSDB locks that the connection is
+ currently waiting to acquire. Omitted if the connection is not waiting
+ for any locks.
+
+
+
+ Space-separated list of the names of OVSDB locks that the connection
+ has had stolen by another OVSDB client. Omitted if no locks have been
+ stolen from this connection.
+
+
+
+ When specifies a connection method that
+ listens for inbound connections (e.g. ptcp:
or
+ pssl:
) and more than one connection is actually active,
+ the value is the number of active connections. Otherwise, this
+ key-value pair is omitted.
+
+
+ When multiple connections are active, status columns and key-value
+ pairs (other than this one) report the status of one arbitrarily
+ chosen connection.
+
+
+
+
+
+ The overall purpose of these columns is described under Common
+ Columns
at the beginning of this document.
+
+
@@ -668,15 +2729,22 @@
If this column's value is false
, the ingress and egress
- interface fields of NetFlow flow records are derived from OpenFlow port
- numbers. When it is true
, the 7 most significant bits of
- these fields will be replaced by the least significant 7 bits of the
- engine id. This is useful because many NetFlow collectors do not
- expect multiple switches to be sending messages from the same host, so
- they do not store the engine information which could be used to
- disambiguate the traffic.
+ interface fields of NetFlow flow records are derived from OpenFlow port
+ numbers. When it is true
, the 7 most significant bits of
+ these fields will be replaced by the least significant 7 bits of the
+ engine id. This is useful because many NetFlow collectors do not
+ expect multiple switches to be sending messages from the same host, so
+ they do not store the engine information which could be used to
+ disambiguate the traffic.
When this option is enabled, a maximum of 508 ports are supported.
+
+
+ Records in this table describe functionality supported by the hardware
+ and software platform on which this Open vSwitch is based. Clients
+ should not modify this table.
+
+ A record in this table is meaningful only if it is referenced by the
+ column in the
+ table. The key used to reference it, called
+ the record's ``category,'' determines the meanings of the
+ column. The following general forms of
+ categories are currently defined:
+
+
+ qos-type
+ - type is supported as the value for
+
in the table.
+
+
+
+
+ Key-value pairs that describe capabilities. The meaning of the pairs
+ depends on the category key that the column in the table
+ uses to reference this record, as described above.
+
+ The presence of a record for category qos-type
+ indicates that the switch supports type as the value of
+ the column in the
+ table. The following key-value pairs are defined to further describe
+ QoS capabilities:
+
+
+ n-queues
+ - Number of supported queues, as a positive integer. Keys in the
+
column for
+ records whose value
+ equals type must range between 0 and this value minus one,
+ inclusive.
+
+
+