X-Git-Url: http://git.onelab.eu/?a=blobdiff_plain;f=vswitchd%2Fvswitch.xml;h=a248d9fbfc90a96b26684a4f08c72b07e9b6c75a;hb=12eb035b810ff9d537d6ff9f1eb8ad5564c1f644;hp=77906882f6b5f907dda364e01538b1f61823c264;hpb=6b4186af06c450aeaec3a2f677efeb2d10a023fe;p=sliver-openvswitch.git
diff --git a/vswitchd/vswitch.xml b/vswitchd/vswitch.xml
index 77906882f..a3518130f 100644
--- a/vswitchd/vswitch.xml
+++ b/vswitchd/vswitch.xml
@@ -1,15 +1,55 @@
A database with this schema holds the configuration for one Open
- vSwitch daemon. The root of the configuration for the daemon is
- the table, which must have exactly one
+
+ A database with this schema holds the configuration for one Open
+ vSwitch daemon. The top-level configuration for the daemon is the
+ table, which must have exactly one
record. Records in other tables are significant only when they
- can be reached directly or indirectly from the
- table.
+ Most tables contain two special columns, named other_config
+ and external_ids
. These columns have the same form and
+ purpose each place that they appear, so we describe them here to save space
+ later.
+
other_config
: map of string-string pairs+ Key-value pairs for configuring rarely used features. Supported keys, + along with the forms taken by their values, are documented individually + for each table. +
+
+ A few tables do not have other_config
columns because no
+ key-value pairs have yet been defined for them.
+
external_ids
: map of string-string pairs+ VLAN IDs of VLANs on which MAC address learning should be disabled, + so that packets are flooded instead of being sent to specific ports + that are believed to contain packets' destination MACs. This should + ordinarily be used to disable MAC learning on VLANs used for + mirroring (RSPAN VLANs). It may also be useful for debugging. +
+
+ SLB bonding (see the column in
+ the table) is incompatible with
+ flood_vlans
. Consider using another bonding mode or
+ a different type of mirror instead.
+
+ OpenFlow controller set. If unset, then no OpenFlow controllers + will be used. +
+ ++ If there are primary controllers, removing all of them clears the + flow table. If there are no primary controllers, adding one also + clears the flow table. Other changes to the set of controllers, such + as adding or removing a service controller, adding another primary + controller to supplement an existing primary controller, or removing + only one of two primary controllers, have no effect on the flow + table. +
+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
secure
If this value is unset, the default is implementation-specific.
+ 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
secure
+ The default is standalone
if the value is unset, but
+ future versions of Open vSwitch may change the default.
+
+ The standalone
mode can create forwarding loops on a
+ bridge that has more than one uplink port unless STP is enabled. To
+ avoid loops on such a bridge, configure secure
mode or
+ enable STP (see ).
+
When more than one controller is configured, - is considered only when none of the - configured controllers can be contacted.
+ is considered only when none of the + configured controllers can be contacted. ++ Changing when no primary controllers are + configured clears the flow table. +
other-config
- instead.)
+ Reports the OpenFlow datapath ID in use. Exactly 16 hex digits.
+ (Setting this column has no useful effect. Set instead.)
+ switch3 in room 3120
.
+ true
, disable in-band control on the bridge
+ regardless of controller and manager settings.
+ + List of OpenFlow protocols that may be used when negotiating + a connection with a controller. OpenFlow 1.0, 1.1, 1.2, and + 1.3 are enabled by default if this column is empty. +
+ +
+ The current implementation of OpenFlow 1.4 support is not safe:
+ ovs-vswitchd
will abort when certain unimplemented
+ features are tested. Thus, for now it is suitable only for
+ experimental use. For this reason, OpenFlow 1.4 is supported only
+ if, in addition to specifying OpenFlow14
in this field,
+ ovs-vswitchd
is invoked with the
+ --enable-of14
option. (When support becomes safe, this
+ option will be removed.)
+
forwarding
, in seconds. By default, the
+ forwarding delay is 15 seconds.
netdev
.
- bridge-id
xs-network-uuids
.xs-network-uuids
xe network-list
.xe network-list
.
+ true
to enable.
+
+ The following destination MAC addresss will not be forwarded when this
+ option is enabled.
datapath-id
disable-in-band
true
, disable in-band control on
- the bridge regardless of controller and manager settings.hwaddr
in-band-queue
01:80:c2:00:00:00
01:80:c2:00:00:01
01:80:c2:00:00:0x
00:e0:2b:00:00:00
00:e0:2b:00:00:04
and 00:e0:2b:00:00:06
+ 01:00:0c:cc:cc:cc
01:00:0c:cc:cc:cd
01:00:0c:cd:cd:cd
01:00:0c:00:00:00
01:00:0c:cc:cc:cx
+ The maximum number of seconds to retain a MAC learning entry for + which no packets have been seen. The default is currently 300 + seconds (5 minutes). The value, if specified, is forced into a + reasonable range, currently 15 to 3600 seconds. +
+ ++ A short MAC aging time allows a network to more quickly detect that a + host is no longer connected to a switch port. However, it also makes + it more likely that packets will be flooded unnecessarily, when they + are addressed to a connected host that rarely transmits packets. To + reduce the incidence of unnecessary flooding, use a MAC aging time + longer than the maximum interval at which a host will ordinarily + transmit packets. +
++ The maximum number of MAC addresses to learn. The default is + currently 2048. The value, if specified, is forced into a reasonable + range, currently 10 to 1,000,000. +
++ Status information about bridges. +
+
+ The bridge-id (in hex) used in spanning tree advertisements.
+ Configuring the bridge-id is described in the
+ stp-system-id
and stp-priority
keys
+ of the other_config
section earlier.
+
+ The designated root (in hex) for this spanning tree. +
++ The path cost of reaching the designated bridge. A lower + number is better. +
+Common
+ Columns
at the beginning of this document.
+
+ Ethernet 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.
OpenFlow port number for this interface. Unlike most columns, this - column's value should be set only by Open vSwitch itself. Other - clients should set this column to an empty set (the default) when - creating an .
-Open vSwitch populates this column when the port number becomes - known. If the interface is successfully added, - will be set to a number between 1 and 65535 - (generally either in the range 1 to 65279, inclusive, or 65534, the - port number for the OpenFlow ``local port''). If the interface - cannot be added then Open vSwitch sets this column - to -1.
-+ When a client adds a new interface, Open vSwitch chooses an OpenFlow + port number for the new port. If the client that adds the port fills + in , then Open vSwitch tries to use its + value as the OpenFlow port number. Otherwise, or if the requested + port number is already in use or cannot be used for another reason, + Open vSwitch automatically assigns a free port number. Regardless of + how the port number was obtained, Open vSwitch then reports in the port number actually assigned. +
+ ++ Open vSwitch limits the port numbers that it automatically assigns to + the range 1 through 32,767, inclusive. Controllers therefore have + free use of ports 32,768 and up. +
+ ++ OpenFlow port number for this interface. Open vSwitch sets this + column's value, so other clients should treat it as read-only. +
+
+ The OpenFlow ``local'' port (OFPP_LOCAL
) is 65,534.
+ The other valid port numbers are in the range 1 to 65,279,
+ inclusive. Value -1 indicates an error adding the interface.
+
+ Requested OpenFlow port number for this interface. +
+ ++ A client should ideally set this column's value in the same + database transaction that it uses to create the interface. Open + vSwitch version 2.1 and later will honor a later request for a + specific port number, althuogh it might confuse some controllers: + OpenFlow does not have a way to announce a port number change, so + Open vSwitch represents it over OpenFlow as a port deletion + followed immediately by a port addition. +
+ ++ If is set or changed to some other + port's automatically assigned port number, Open vSwitch chooses a + new port number for the latter port. +
++ The interface type, one of: +
+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.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.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.pmtud
false
to disable.header_cache
false
to disable.gre64
patch
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
.
+
+ Open vSwitch uses UDP destination port 4789. The source port used for + VXLAN traffic varies on a per-flow basis and is in the ephemeral port + range. +
+lisp
- A pair of virtual devices that act as a patch cable. The column must have the following key-value pair: + A layer 3 tunnel over the experimental, UDP-based Locator/ID + Separation Protocol (RFC 6830).
-peer
peer
option must specify
- this 's name. That is, the two patch
- interfaces must have reversed and
- peer
values.
- + Only IPv4 and IPv6 packets are supported by the protocol, and + they are sent and received without an Ethernet header. Traffic + to/from LISP ports is expected to be configured explicitly, and + the ports are not intended to participate in learning based + switching. As such, they are always excluded from packet + flooding. +
+patch
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.
+
- Key-value pairs that report port status. Supported status
- values are type
-dependent.
The only currently defined key-value pair is:
-source_ip
gre
or capwap
. Not
- supported by all implementations.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.
+ + 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. +
+gre
.
+
+ Key-value pairs that report interface statistics. The current
+ implementation updates these counters periodically. The update period
+ is controlled by in the Open_vSwitch
table.
+ Future implementations may update them when an interface is created,
+ when they are queried (e.g. using an OVSDB select
+ operation), and just before an interface is deleted due to virtual
+ interface hot-unplug or VM shutdown, and perhaps at other times, but
+ not on any regular periodic basis.
+
+ These are the same statistics reported by OpenFlow in its struct
+ ofp_port_stats
structure. If an interface does not support a
+ given statistic, then that pair is omitted.
+
These settings control ingress policing for packets received on this
@@ -1042,9 +1909,9 @@
Maximum burst size for data received on this interface, in kb. The
- default burst size if set to 0
is 1000 kb. This value
- has no effect if
- is 0
.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 @@ -1056,139 +1923,751 @@
+ BFD, defined in RFC 5880 and RFC 5881, allows point-to-point + detection of connectivity failures by occasional transmission of + BFD control messages. Open vSwitch implements BFD to serve + as a more popular and standards compliant alternative to CFM. +
-+ BFD operates by regularly transmitting BFD control messages at a rate + negotiated independently in each direction. Each endpoint specifies + the rate at which it expects to receive control messages, and the rate + at which it is willing to transmit them. Open vSwitch uses a detection + multiplier of three, meaning that an endpoint signals a connectivity + fault if three consecutive BFD control messages fail to arrive. In the + case of a unidirectional connectivity issue, the system not receiving + BFD control messages signals the problem to its peer in the messages it + transmits. +
+ ++ The Open vSwitch implementation of BFD aims to comply faithfully + with RFC 5880 requirements. Open vSwitch does not implement the + optional Authentication or ``Echo Mode'' features. +
+ ++ A controller sets up key-value pairs in the + column to enable and configure BFD. +
+ +1000
.
+ 100
.
+ true
, traffic received on the
+ is used to indicate the capability of packet
+ I/O. BFD control packets are still transmitted and received. At
+ least one BFD control packet must be received every 100 * amount of time. Otherwise, even if
+ traffic are received, the
+ will be false
.
+ 00:23:20:00:00:01
.
+ 169.254.1.0
.
+ 169.254.1.1
.
+ + The switch sets key-value pairs in the + column to report the status of BFD on this interface. When BFD is + not enabled, with , the switch clears + all key-value pairs from . +
+ +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.
+
+ A Maintenance Point ID (MPID) uniquely identifies each endpoint + within a Maintenance Association. The MPID is used to identify this + endpoint to other Maintenance Points in the MA. Each end of a link + being monitored should have a different MPID. Must be configured to + enable CFM on this . +
++ According to the 802.1ag specification, MPIDs can only range between + [1, 8191]. However, extended mode (see ) supports eight byte MPIDs. +
attached-mac
MAC
- field in the VIF record for this interface.iface-id
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.
+ 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.
The currently defined key-value pairs for XenServer are:
-xs-vif-uuid
xs-network-uuid
xs-vm-uuid
+ 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. +
+remote_ip
. This could be an internal interface
- such as a bridge port.
+ ovs-appctl
command.
+ When in extended mode, indicates the operational state of the
+ remote endpoint as either up
or down
. See
+ .
+
- Key-value pairs that report interface statistics. The current
- implementation updates these counters periodically. In the future,
- we plan to, instead, update them when an interface is created, when
- they are queried (e.g. using an OVSDB select
operation),
- and just before an interface is deleted due to virtual interface
- hot-unplug or VM shutdown, and perhaps at other times, but not on any
- regular periodic basis.
- 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.
rx_packets
rx_bytes
tx_packets
tx_bytes
rx_dropped
rx_frame_err
rx_over_err
rx_crc_err
rx_errors
tx_dropped
collisions
tx_errors
+ 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. And extended
+ mode allows eight byte MPIDs. Defaults to false
.
+
+ When true
, and
+ is true, the CFM
+ module operates in demand mode. When in demand mode, traffic
+ received on the is used to indicate
+ liveness. CCMs are still transmitted and received. At least one
+ CCM must be received every 100 * amount of time. Otherwise, even if traffic
+ are received, the CFM module will raise the connectivity fault.
+
+ Demand mode has a couple of caveats: +
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.
+
+