X-Git-Url: http://git.onelab.eu/?a=blobdiff_plain;f=vswitchd%2Fvswitch.xml;h=b9628494298286cdd26dac6f856ba37be077562f;hb=28b114322856db3870fb2825fc5dbfc8d16f3a7f;hp=1db89dc5be9dbc6936af263659c7d6226fb7f0c9;hpb=66409d1bccbdddd8833f74876a1e7ef250034d4e;p=sliver-openvswitch.git diff --git a/vswitchd/vswitch.xml b/vswitchd/vswitch.xml index 1db89dc5b..b96284942 100644 --- a/vswitchd/vswitch.xml +++ b/vswitchd/vswitch.xml @@ -9,9 +9,44 @@ table="Open_vSwitch"/> 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. + ``root set'' tables.
+
+ Most tables contain two special columns, named other_config
+ and external_ids
. These columns have the same form and
+ purpose each place that they appear, so we describe them here to save space
+ later.
+
other_config
: map of string-string pairs+ Key-value pairs for configuring rarely used features. Supported keys, + along with the forms taken by their values, are documented individually + for each table. +
+
+ A few tables do not have other_config
columns because no
+ key-value pairs have yet been defined for them.
+
external_ids
: map of string-string pairsEthernet address to set for this interface. If unset then the - default MAC address is used:
+ default MAC address is used:Some interfaces may not have a software-controllable MAC address.
@@ -725,380 +1212,353 @@OpenFlow port number for this interface. Unlike most columns, this - column's value should be set only by Open vSwitch itself. Other - clients should set this column to an empty set (the default) when - creating an .
+ column's value should be set only by Open vSwitch itself. Other + clients should set this column to an empty set (the default) when + creating an .Open vSwitch populates this column when the port number becomes - known. If the interface is successfully added, - will be set to a number between 1 and 65535 - (generally either in the range 1 to 65279, inclusive, or 65534, the - port number for the OpenFlow ``local port''). If the interface - cannot be added then Open vSwitch sets this column - to -1.
+ known. If the interface is successfully added, + will be set to a number between 1 and 65535 + (generally either in the range 1 to 65279, inclusive, or 65534, the + port number for the OpenFlow ``local port''). If the interface + cannot be added then Open vSwitch sets this column + to -1. +When is not set, Open vSwitch picks + an appropriate value for this column and then tries to keep the value + constant across restarts.
+Requested OpenFlow port number for this interface. The port + number must be between 1 and 65279, inclusive. Some datapaths + cannot satisfy all requests for particular port numbers. When + this column is empty or the request cannot be fulfilled, the + system will choose a free port. The + column reports the assigned OpenFlow port number.
+The port number must be requested in the same transaction + that creates the port.
+ The interface type, one of: +
+system
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
.system
.
+
internal
tap
gre
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
local_ip
in_key
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
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
in_key
and
- out_key
at the same time.tos
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
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
true
to enable.df_inherit
true
to enable.df_default
df_inherit
option
- is not set, or if the encapsulated packet is not IP. Default
- is enabled; set to false
to disable.pmtud
false
to disable.header_cache
false
to disable.ipsec_gre
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
local_ip
peer_cert
certificate
option.certificate
private_key
certificate
. If certificate
- contains the private key, this option may be omitted.psk
in_key
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
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
in_key
and
- out_key
at the same time.tos
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
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
true
to enable.df_inherit
true
to enable.df_default
df_inherit
option
- is not set, or if the encapsulated packet is not IP. Default
- is enabled; set to false
to disable.pmtud
false
to disable.capwap
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
local_ip
tos
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
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.df_inherit
true
to enable.df_default
df_inherit
option
- is not set, or if the encapsulated packet is not IP. Default
- is enabled; set to false
to disable.pmtud
false
to disable.header_cache
false
to disable.gre64
ipsec_gre64
vxlan
+ An Ethernet tunnel over the experimental, UDP-based VXLAN
+ protocol described at
+ http://tools.ietf.org/html/draft-mahalingam-dutt-dcops-vxlan-03
.
+ VXLAN is currently supported only with the Linux kernel datapath
+ with kernel version 2.6.26 or later.
+
+ 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
patch
- A pair of virtual devices that act as a patch cable. The column must have the following key-value pair: -
- + A pair of virtual devices that act as a patch cable.null
+ 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. +
+ +Required. The remote tunnel endpoint, one of:
+ +192.168.0.123
.
+ Only unicast endpoints are supported.
+ 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.
+
+ Optional. The tunnel destination IP that received packets must + match. Default is to match all addresses. If specified, may be one + of: +
+ +192.168.12.3
.
+ flow
. The tunnel accepts packets sent to any
+ of the local IP addresses of the system running OVS. To process
+ only packets sent to a specific IP address, the flow entries may
+ match on the tun_dst
field. When sending packets to a
+ local_ip=flow
tunnel, the flow actions may
+ explicitly set the tun_src
field to the desired IP
+ address, e.g. with a set_field
action. However, while
+ routing the tunneled packet out, the local system may override the
+ specified address with the local IP address configured for the
+ outgoing system interface.
+
+
+ This option is valid only for tunnels also configured with the
+ remote_ip=flow
option.
+
+ 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.
+ 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.
+ 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.
+ in_key
and
+ out_key
at the same time.
+ 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.
+ 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.
+ 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.
+
certificate
+ option.
+ certificate
.
+ If certificate
contains the private key, this option may
+ be omitted.
+
+ Only patch
interfaces support these options.
+
peer
option must specify this 's
+ name. That is, the two patch interfaces must have reversed and peer
values.
+ The number of times Open vSwitch has observed the + of this change. +
+The negotiated speed of the physical network link. @@ -1151,50 +1618,113 @@
- 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:
-driver_name
driver_version
firmware_version
source_ip
gre
or capwap
.tunnel_egress_iface
remote_ip
.
- This could be an internal interface such as a bridge port.tunnel_egress_iface_carrier
down
- and up
.gre
.
+
+ 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.
+
These settings control ingress policing for packets received on this
@@ -1257,9 +1787,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
.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 @@ -1271,154 +1801,606 @@
+ BFD, defined in RFC 5880 and RFC 5881, allows point to point + detection of connectivity failures by occasional transmission of + BFD control messages. It is implemented in Open vSwitch to serve + as a more popular and standards compliant alternative to CFM. +
+ ++ 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's willing to transmit them. Open vSwitch + uses a detection multiplier of three, meaning that an endpoint + which fails to receive BFD control messages for a period of three + times the expected reception rate, will signal a connectivity + fault. In the case of a unidirectional connectivity issue, the + system not receiving BFD control messages will signal the problem + to its peer in the messages is transmists. +
+ ++ The Open vSwitch implementation of BFD aims to comply faithfully + with the requirements put forth in RFC 5880. Currently, the only + known omission is ``Demand Mode'', which we hope to include in + future. Open vSwitch does not implement the optional + Authentication or ``Echo Mode'' features. +
+ +true
BFD is enabled on this
+ , otherwise it's disabled. Defaults to
+ false
.
+ 1000
.
+ 100
.
+ cpath_down
to
+ true
which may cause the remote BFD session not to
+ forward traffic to this . Defaults to
+ false
.
+ UP
.
+ UP
, and the remote system isn't signaling a
+ problem such as concatenated path down.
+ + 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.
+
+ 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. +
+ovs-appctl
command.
+ When in extended mode, indicates the operational state of the
+ remote endpoint as either up
or down
. See
+ .
+
+ 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. +
++ 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. +
++ 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.
+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 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, but if the
+ is receiving traffic, their absence does not
+ cause a connectivity fault.
+
+ Demand mode has a couple of caveats: +
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
.
+ random
in which
+ case each CCM will be tagged with a different randomly generated VLAN.
+
+ 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.
+
MAC
field
+ in the VIF record for this interface.
+
+ 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 ``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 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. +
+Common
+ Columns
at the beginning of this document.
+
+
+
+ linux-hfsc
may use queue_id
s less than 61440.
+ It has the following key-value pairs defined.
+
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.
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.
Common
+ Columns
at the beginning of this document.
+
+