+
+ 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.
+
-
- Connectivity monitor configuration for this interface.
+
+ 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 .
-
- Key-value pairs for use by external frameworks that integrate
- with Open vSwitch, rather than by Open vSwitch itself. System
- integrators should either use the Open vSwitch development
- mailing list to coordinate on common key-value definitions, or
- choose key names that are likely to be unique. The currently
- defined common key-value pairs are:
-
- attached-mac
- -
- The MAC address programmed into the ``virtual hardware'' for this
- interface, in the form
- xx:xx:xx:xx:xx:xx.
- For Citrix XenServer, this is the value of the
MAC
- field in the VIF record for this interface.
- iface-id
- - A system-unique identifier for the interface. On XenServer,
- this will commonly be the same as
xs-vif-uuid
.
-
+
+
+ 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.
+
+
+
+
+ Indicates a CFM fault was triggered due to a lack of CCMs received on
+ the .
+
+
+
+ Indicates a CFM fault was triggered due to the reception of a CCM with
+ the RDI bit flagged. Endpoints set the RDI bit in their CCMs when they
+ are not receiving CCMs themselves. This typically indicates a
+ unidirectional connectivity failure.
+
+
+
+ Indicates a CFM fault was triggered due to the reception of a CCM with
+ a MAID other than the one Open vSwitch uses. CFM broadcasts are tagged
+ with an identification number in addition to the MPID called the MAID.
+ Open vSwitch only supports receiving CCM broadcasts tagged with the
+ MAID it uses internally.
+
+
+
+ Indicates a CFM fault was triggered due to the reception of a CCM
+ advertising the same MPID configured in the
+ column of this . This may indicate a loop in
+ the network.
+
+
+
+ Indicates a CFM fault was triggered because the CFM module received
+ CCMs from more remote endpoints than it can keep track of.
+
+
+
+ Indicates a CFM fault was manually triggered by an administrator using
+ an ovs-appctl
command.
+
+
+
+ Indicates a CFM fault was triggered due to the reception of a CCM
+ frame having an invalid interval.
+
+
+
+ When in extended mode, indicates the operational state of the
+ remote endpoint as either up
or down
. See
+ .
+
+
+
+
+
+ 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.
+
+
+
+
+ When CFM is properly configured, Open vSwitch will occasionally
+ receive CCM broadcasts. These broadcasts contain the MPID of the
+ sending Maintenance Point. The list of MPIDs from which this
+ is receiving broadcasts from is regularly
+ collected and written to this column.
+
+
+
+
+ The interval, in milliseconds, between transmissions of CFM
+ heartbeats. Three missed heartbeat receptions indicate a
+ connectivity fault.
+
+
+
+ In standard operation only intervals of 3, 10, 100, 1,000, 10,000,
+ 60,000, or 600,000 ms are supported. Other values will be rounded
+ down to the nearest value on the list. Extended mode (see ) supports any interval up
+ to 65,535 ms. In either mode, the default is 1000 ms.
+
+
+ We do not recommend using intervals less than 100 ms.
+
+
+
+ When true
, the CFM module operates in extended mode. This
+ causes it to use a nonstandard destination address to avoid conflicting
+ with compliant implementations which may be running concurrently on the
+ network. Furthermore, extended mode increases the accuracy of the
+ cfm_interval
configuration parameter by breaking wire
+ compatibility with 802.1ag compliant implementations. 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. May be the string random
in which
+ case each CCM will be tagged with a different randomly generated VLAN.
+
+
+
+ When set, the CFM module will apply a VLAN tag to all CCMs it generates
+ with the given PCP value, the VLAN ID of the tag is governed by the
+ value of . If
+ is unset, a VLAN ID of
+ zero is used.
+
+
+
+
+
+
+ These key-value pairs specifically apply to an interface that
+ represents a virtual Ethernet interface connected to a virtual
+ machine. These key-value pairs should not be present for other types
+ of interfaces. Keys whose names end in -uuid
have
+ values that uniquely identify the entity in question. For a Citrix
+ XenServer hypervisor, these values are UUIDs in RFC 4122 format.
+ Other hypervisors may use other formats.
+
+
+
+ The MAC address programmed into the ``virtual hardware'' for this
+ interface, in the form
+ xx:xx:xx:xx:xx:xx.
+ For Citrix XenServer, this is the value of the MAC
field
+ in the VIF record for this interface.
+
+
+
+ A system-unique identifier for the interface. On XenServer, this will
+ commonly be the same as .
+
+
+
+
+ Hypervisors may sometimes have more than one interface associated
+ with a given , only one of
+ which is actually in use at a given time. For example, in some
+ circumstances XenServer has both a ``tap'' and a ``vif'' interface
+ for a single , but only
+ uses one of them at a time. A hypervisor that behaves this way must
+ mark the currently in use interface active
and the
+ others inactive
. A hypervisor that never has more than
+ one interface for a given
+ may mark that interface active
or omit entirely.
+
+
+
+ During VM migration, a given might transiently be marked active
on
+ two different hypervisors. That is, active
means that
+ this is the active
+ instance within a single hypervisor, not in a broader scope.
+
+
+
+
+ The virtual interface associated with this interface.
+
+
+
+ The virtual network to which this interface is attached.
+
+
+
+ The VM to which this interface belongs. On XenServer, this will be the
+ same as .
+
+
+
+ The VM to which this interface belongs.
+
+
+
+
+
+ The ``VLAN splinters'' feature increases Open vSwitch compatibility
+ with buggy network drivers in old versions of Linux that do not
+ properly support VLANs when VLAN devices are not used, at some cost
+ in memory and performance.
+
+
+
+ When VLAN splinters are enabled on a particular interface, Open vSwitch
+ creates a VLAN device for each in-use VLAN. For sending traffic tagged
+ with a VLAN on the interface, it substitutes the VLAN device. Traffic
+ received on the VLAN device is treated as if it had been received on
+ the interface on the particular VLAN.
+
+
+
+ VLAN splinters consider a VLAN to be in use if:
+
+
+
+ -
+ The VLAN is the
value in any record.
+
+
+ -
+ The VLAN is listed within the
+ column of the record of an interface on which
+ VLAN splinters are enabled.
+
+ An empty does not influence the
+ in-use VLANs: creating 4,096 VLAN devices is impractical because it
+ will exceed the current 1,024 port per datapath limit.
+
+
+ -
+ An OpenFlow flow within any bridge matches the VLAN.
+
+
+
+
+ The same set of in-use VLANs applies to every interface on which VLAN
+ splinters are enabled. That is, the set is not chosen separately for
+ each interface but selected once as the union of all in-use VLANs based
+ on the rules above.
+
+
+
+ It does not make sense to enable VLAN splinters on an interface for an
+ access port, or on an interface that is not a physical port.
+
+
+
+ VLAN splinters are deprecated. When broken device drivers are no
+ longer in widespread use, we will delete this feature.
+
+
+
- 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.
+ Set to true
to enable VLAN splinters on this interface.
+ Defaults to false
.
- The currently defined key-value pairs for XenServer are:
-
- xs-vif-uuid
- - The virtual interface associated with this interface.
- xs-network-uuid
- - The virtual network to which this interface is attached.
- xs-vm-uuid
- - The VM to which this interface belongs.
-
-
-
-
- Key-value pairs for rarely used interface features.
-
- lacp-port-priority
- - The LACP port priority of this
. In
- LACP negotiations s with numerically lower
- priorities are preferred for aggregation. Must be a number between
- 1 and 65535.
-
-
-
- Key-value pairs that report interface statistics. The current
- implementation updates these counters periodically. In the future,
- we plan to, instead, update them when an interface is created, when
- they are queried (e.g. using an OVSDB select
operation),
- and just before an interface is deleted due to virtual interface
- hot-unplug or VM shutdown, and perhaps at other times, but not on any
- regular periodic basis.
+ VLAN splinters increase kernel and userspace memory overhead, so do
+ not use them unless they are needed.
+
+
- The currently defined key-value pairs are listed below. These are
- the same statistics reported by OpenFlow in its struct
- ofp_port_stats
structure. If an interface does not support a
- given statistic, then that pair is omitted.
-
- -
- Successful transmit and receive counters:
-
- rx_packets
- - Number of received packets.
- rx_bytes
- - Number of received bytes.
- tx_packets
- - Number of transmitted packets.
- tx_bytes
- - Number of transmitted bytes.
-
-
- -
- Receive errors:
-
- rx_dropped
- - Number of packets dropped by RX.
- rx_frame_err
- - Number of frame alignment errors.
- rx_over_err
- - Number of packets with RX overrun.
- rx_crc_err
- - Number of CRC errors.
- rx_errors
- -
- Total number of receive errors, greater than or equal
- to the sum of the above.
-
-
-
- -
- Transmit errors:
-
- tx_dropped
- - Number of packets dropped by TX.
- collisions
- - Number of collisions.
- tx_errors
- -
- Total number of transmit errors, greater
- than or equal to the sum of the above.
-
-
-
-
+ 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.
+
+
+