+
+ 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 it transmits.
+
+
+
+ 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.
+
+
+
+ When true
BFD is enabled on this
+ , otherwise it's disabled. Defaults to
+ false
.
+
+
+
+ The fastest rate, in milliseconds, at which this BFD session is
+ willing to receive BFD control messages. The actual rate may be
+ slower if the remote endpoint isn't willing to transmit as quickly as
+ specified. Defaults to 1000
.
+
+
+
+ The fastest rate, in milliseconds, at which this BFD session is
+ willing to transmit BFD control messages. The actual rate may be
+ slower if the remote endpoint isn't willing to receive as quickly as
+ specified. Defaults to 100
.
+
+
+
+ decay_min_rx
is used to set the min_rx
,
+ when there is no obvious incoming data traffic at the interface.
+ It cannot be set less than the min_rx
. The decay feature
+ is disabled by setting the decay_min_rx
to 0. And the
+ feature is reset everytime itself or min_rx
is
+ reconfigured.
+
+
+
+ When forwarding_if_rx
is true the interface will be
+ considered capable of packet I/O as long as there is packet
+ received at interface. This is important in that when link becomes
+ temporarily conjested, consecutive BFD control packets can be lost.
+ And the forwarding_if_rx
can prevent link failover by
+ detecting non-control packets received at interface.
+
+
+
+ Concatenated path down may be used when the local system should not
+ have traffic forwarded to it for some reason other than a connectivty
+ failure on the interface being monitored. When a controller thinks
+ this may be the case, it may set cpath_down
to
+ true
which may cause the remote BFD session not to
+ forward traffic to this . Defaults to
+ false
.
+
+
+
+ When set to true, Check Tunnel Key will make BFD only accept control
+ messages with an in_key
of zero. Defaults to
+ false
.
+
+
+
+ An Ethernet address in the form
+ xx:xx:xx:xx:xx:xx
+ to set the destination mac address of the bfd packet. If this
+ field is set, it is assumed that all the bfd packets destined to this
+ interface also has the same destination mac address. If not set, a
+ default value of 00:23:20:00:00:01
is used.
+
+
+
+ State of the BFD session. The BFD session is fully healthy and
+ negotiated if UP
.
+
+
+
+ True if the BFD session believes this may be
+ used to forward traffic. Typically this means the local session is
+ signaling UP
, and the remote system isn't signaling a
+ problem such as concatenated path down.
+
+
+
+ A short message indicating what the BFD session thinks is wrong in
+ case of a problem.
+
+
+
+ State of the remote endpoint's BFD session.
+
+
+
+ A short message indicating what the remote endpoint's BFD session
+ thinks is wrong in case of a problem.
+
+
+
+
+
+ 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 .
+
+
+
+
+ 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 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:
+
+ -
+ To ensure that ovs-vswitchd has enough time to pull statistics
+ from the datapath, the minimum
+
is 500ms.
+
+
+ -
+ To avoid ambiguity, demand mode disables itself when there are
+ multiple remote maintenance points.
+
+
+ -
+ If the
is heavily congested, CCMs
+ containing the
+ status may be dropped causing changes in the operational state to
+ be delayed. Similarly, if CCMs containing the RDI bit are not
+ received, unidirectional link failures may not be detected.
+
+
+
+
+
+
+ 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.
+ 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 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.
+
+
+
+
+ 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.
+
+
+
+
+