@@ -2117,7 +2121,7 @@
checksums on outgoing packets. Default is disabled, set to
true
to enable. Checksums present on incoming
packets will be validated regardless of this setting.
-
+
When using the upstream Linux kernel module, computation of
@@ -2130,9 +2134,9 @@
- This option is supported for ipsec_gre
, but not useful
- because GRE checksums are weaker than, and redundant with, IPsec
- payload authentication.
+ This option is supported for ipsec_gre
, but not useful
+ because GRE checksums are weaker than, and redundant with, IPsec
+ payload authentication.
@@ -2184,6 +2188,21 @@
+
Status information about interfaces attached to bridges, updated every
@@ -2427,70 +2446,70 @@
- 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, 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.
+ 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.
+ 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.
-
+
+ A controller sets up key-value pairs in the
+ column to enable and configure BFD.
+
-
+
True to enable BFD on this . If not
specified, BFD will not be enabled by default.
-
+
-
+
The shortest interval, in milliseconds, at which this BFD session
offers to receive BFD control messages. The remote endpoint may
choose to send messages at a slower rate. Defaults to
1000
.
-
+
-
+
The shortest interval, in milliseconds, at which this BFD session is
willing to transmit BFD control messages. Messages will actually be
transmitted at a slower rate if the remote endpoint is not willing to
receive as quickly as specified. Defaults to 100
.
-
-
-
- An alternate receive interval, in milliseconds, that must be greater
- than or equal to . The
- implementation switches from to when there is no obvious incoming
- data traffic at the interface, to reduce the CPU and bandwidth cost
- of monitoring an idle interface. This feature may be disabled by
- setting a value of 0. This feature is reset whenever or
- changes.
-
-
-
+
+
+
+ An alternate receive interval, in milliseconds, that must be greater
+ than or equal to . The
+ implementation switches from to when there is no obvious incoming
+ data traffic at the interface, to reduce the CPU and bandwidth cost
+ of monitoring an idle interface. This feature may be disabled by
+ setting a value of 0. This feature is reset whenever or
+ changes.
+
+
+
When true
, traffic received on the
is used to indicate the capability of packet
I/O. BFD control packets are still transmitted and received. At
@@ -2498,98 +2517,98 @@
column="bfd" key="min_rx"/> amount of time. Otherwise, even if
traffic are received, the
will be false
.
-
+
-
- Set to true to notify the remote endpoint that traffic should not be
- forwarded to this system for some reason other than a connectivty
- failure on the interface being monitored. The typical underlying
- reason is ``concatenated path down,'' that is, that connectivity
- beyond the local system is down. Defaults to false.
-
+
+ Set to true to notify the remote endpoint that traffic should not be
+ forwarded to this system for some reason other than a connectivty
+ failure on the interface being monitored. The typical underlying
+ reason is ``concatenated path down,'' that is, that connectivity
+ beyond the local system is down. Defaults to false.
+
-
+
Set to true to make BFD accept only control messages with a tunnel
key of zero. By default, BFD accepts control messages with any
tunnel key.
-
-
-
- Set to an Ethernet address in the form
- xx:xx:xx:xx:xx:xx
- to set the MAC used as source for transmitted BFD packets. The
- default is the mac address of the BFD enabled interface.
-
-
-
- Set to an Ethernet address in the form
- xx:xx:xx:xx:xx:xx
- to set the MAC used as destination for transmitted BFD packets. The
- default is 00:23:20:00:00:01
.
-
-
-
- Set to an Ethernet address in the form
- xx:xx:xx:xx:xx:xx
- to set the MAC used for checking the destination of received BFD packets.
- Packets with different destination MAC will not be considered as BFD packets.
- If not specified the destination MAC address of received BFD packets
- are not checked.
-
-
-
+
+
+
+ Set to an Ethernet address in the form
+ xx:xx:xx:xx:xx:xx
+ to set the MAC used as source for transmitted BFD packets. The
+ default is the mac address of the BFD enabled interface.
+
+
+
+ Set to an Ethernet address in the form
+ xx:xx:xx:xx:xx:xx
+ to set the MAC used as destination for transmitted BFD packets. The
+ default is 00:23:20:00:00:01
.
+
+
+
+ Set to an Ethernet address in the form
+ xx:xx:xx:xx:xx:xx
+ to set the MAC used for checking the destination of received BFD packets.
+ Packets with different destination MAC will not be considered as BFD packets.
+ If not specified the destination MAC address of received BFD packets
+ are not checked.
+
+
+
Set to an IPv4 address to set the IP address used as source for
transmitted BFD packets. The default is 169.254.1.1
.
-
+
-
+
Set to an IPv4 address to set the IP address used as destination
for transmitted BFD packets. The default is 169.254.1.0
.
-
+
-
- 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 .
-
-
-
- Reports the state of the BFD session. The BFD session is fully
- healthy and negotiated if UP
.
-
-
-
- Reports whether 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.
-
-
-
- In case of a problem, set to an error message that reports what the
- local BFD session thinks is wrong. The error messages are defined
- in section 4.1 of [RFC 5880].
-
-
-
- Reports the state of the remote endpoint's BFD session.
-
-
-
- In case of a problem, set to an error message that reports what the
- remote endpoint's BFD session thinks is wrong. The error messages
- are defined in section 4.1 of [RFC 5880].
-
+
+ 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 .
+
+
+
+ Reports the state of the BFD session. The BFD session is fully
+ healthy and negotiated if UP
.
+
+
+
+ Reports whether 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 diagnostic code specifying the local system's reason for the
+ last change in session state. The error messages are defined in
+ section 4.1 of [RFC 5880].
+
+
+
+ Reports the state of the remote endpoint's BFD session.
+
+
+
+ A diagnostic code specifying the remote system's reason for the
+ last change in session state. The error messages are defined in
+ section 4.1 of [RFC 5880].
+
+ type='{"type": "integer", "minInteger": 0}'>
Counts the number of
flaps since start. A flap is considered as a change of the
value.
@@ -2617,9 +2636,9 @@
- 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.
+ 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.
@@ -2704,8 +2723,8 @@
When in extended mode, indicates the operational state of the
- remote endpoint as either up
or down
. See
- .
+ remote endpoint as either up
or down
. See
+ .
@@ -2781,7 +2800,7 @@
- Demand mode has a couple of caveats:
+ Demand mode has a couple of caveats:
-
To ensure that ovs-vswitchd has enough time to pull statistics
@@ -2819,14 +2838,14 @@
+ type='{"type": "integer", "minInteger": 1, "maxInteger": 4095}'>
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.
+ type='{"type": "integer", "minInteger": 1, "maxInteger": 7}'>
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
@@ -2934,17 +2953,17 @@
- 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.
+ 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
+ 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.
@@ -2986,8 +3005,8 @@
- VLAN splinters are deprecated. When broken device drivers are no
- longer in widespread use, we will delete this feature.
+ VLAN splinters are deprecated. When broken device drivers are no
+ longer in widespread use, we will delete this feature.
- Auto Attach configuration for a particular interface.
+ Auto Attach configuration for a particular interface.
- True to enable LLDP on this . If not
- specified, LLDP will be disabled by default.
+ True to enable LLDP on this . If not
+ specified, LLDP will be disabled by default.
@@ -3039,58 +3058,42 @@
dump-tables. The name does not affect switch behavior.
-
- If set, limits the number of flows that may be added to the table. Open
- vSwitch may limit the number of flows in a table for other reasons,
- e.g. due to hardware limitations or for resource availability or
- performance reasons.
-
-
-
+
- Controls the switch's behavior when an OpenFlow flow table modification
- request would add flows in excess of . The
- supported values are:
+ Open vSwitch supports limiting the number of flows that may be
+ installed in a flow table, via the column.
+ When adding a flow would exceed this limit, by default Open vSwitch
+ reports an error, but there are two ways to configure Open vSwitch to
+ instead delete (``evict'') a flow to make room for the new one:
-
- refuse
- -
- Refuse to add the flow or flows. This is also the default policy
- when
is unset.
-
-
- evict
- -
- Delete the flow that will expire soonest. See
- for details.
-
-
-
+
+ -
+ Set the
column to evict
.
+
-
-
- When is evict
, this
- controls how flows are chosen for eviction when the flow table would
- otherwise exceed flows. Its value is a set
- of NXM fields or sub-fields, each of which takes one of the forms
- field[]
or
- field[start..end]
,
- e.g. NXM_OF_IN_PORT[]
. Please see
- nicira-ext.h
for a complete list of NXM field names.
-
+ -
+ Send an OpenFlow 1.4+ ``table mod request'' to enable eviction for
+ the flow table (e.g.
ovs-ofctl -O OpenFlow14 mod-table br0 0
+ evict
to enable eviction on flow table 0 of bridge
+ br0
).
+
+
When a flow must be evicted due to overflow, the flow to evict is
- chosen through an approximation of the following algorithm:
+ chosen through an approximation of the following algorithm. This
+ algorithm is used regardless of how eviction was enabled:
-
Divide the flows in the table into groups based on the values of the
- specified fields or subfields, so that all of the flows in a given
- group have the same values for those fields. If a flow does not
- specify a given field, that field's value is treated as 0.
+ fields or subfields specified in the
column,
+ so that all of the flows in a given group have the same values for
+ those fields. If a flow does not specify a given field, that field's
+ value is treated as 0. If is empty, then all
+ of the flows in the flow table are treated as a single group.
-
@@ -3100,6 +3103,14 @@
those groups.
+ -
+ If the flows under consideration have different importance values,
+ eliminate from consideration any flows except those with the lowest
+ importance. (``Importance,'' a 16-bit integer value attached to each
+ flow, was introduced in OpenFlow 1.4. Flows inserted with older
+ versions of OpenFlow always have an importance of 0.)
+
+
-
Among the flows under consideration, choose the flow that expires
soonest for eviction.
@@ -3107,95 +3118,138 @@
- The eviction process only considers flows that have an idle timeout or
- a hard timeout. That is, eviction never deletes permanent flows.
+ The eviction process only considers flows that have an idle timeout
+ or a hard timeout. That is, eviction never deletes permanent flows.
(Permanent flows do count against .)
-
- Open vSwitch ignores any invalid or unknown field specifications.
-
+
+ If set, limits the number of flows that may be added to the table.
+ Open vSwitch may limit the number of flows in a table for other
+ reasons, e.g. due to hardware limitations or for resource availability
+ or performance reasons.
+
-
- When is not evict
, this
- column has no effect.
-
-
+
+
+ Controls the switch's behavior when an OpenFlow flow table
+ modification request would add flows in excess of . The supported values are:
+
-
-
- This string set specifies which fields should be used for
- address prefix tracking. Prefix tracking allows the
- classifier to skip rules with longer than necessary prefixes,
- resulting in better wildcarding for datapath flows.
-
-
- Prefix tracking may be beneficial when a flow table contains
- matches on IP address fields with different prefix lengths.
- For example, when a flow table contains IP address matches on
- both full addresses and proper prefixes, the full address
- matches will typically cause the datapath flow to un-wildcard
- the whole address field (depending on flow entry priorities).
- In this case each packet with a different address gets handed
- to the userspace for flow processing and generates its own
- datapath flow. With prefix tracking enabled for the address
- field in question packets with addresses matching shorter
- prefixes would generate datapath flows where the irrelevant
- address bits are wildcarded, allowing the same datapath flow
- to handle all the packets within the prefix in question. In
- this case many userspace upcalls can be avoided and the
- overall performance can be better.
-
-
- This is a performance optimization only, so packets will
- receive the same treatment with or without prefix tracking.
-
-
- The supported fields are: tun_id
,
- tun_src
, tun_dst
,
- nw_src
, nw_dst
(or aliases
- ip_src
and ip_dst
),
- ipv6_src
, and ipv6_dst
. (Using this
- feature for tun_id
would only make sense if the
- tunnel IDs have prefix structure similar to IP addresses.)
-
+
+ refuse
+ -
+ Refuse to add the flow or flows. This is also the default policy
+ when
is unset.
+
-
- By default, the prefixes=ip_dst,ip_src
are used
- on each flow table. This instructs the flow classifier to
- track the IP destination and source addresses used by the
- rules in this specific flow table.
-
+ evict
+ -
+ Delete a flow chosen according to the algorithm described above.
+
+
+
-
- The keyword none
is recognized as an explicit
- override of the default values, causing no prefix fields to be
- tracked.
-
+
+
+ When is evict
, this
+ controls how flows are chosen for eviction when the flow table would
+ otherwise exceed flows. Its value is a
+ set of NXM fields or sub-fields, each of which takes one of the forms
+ field[]
or
+ field[start..end]
,
+ e.g. NXM_OF_IN_PORT[]
. Please see
+ nicira-ext.h
for a complete list of NXM field names.
+
-
- To set the prefix fields, the flow table record needs to
- exist:
-
+
+ Open vSwitch ignores any invalid or unknown field specifications.
+
-
- ovs-vsctl set Bridge br0 flow_tables:0=@N1 -- --id=@N1 create Flow_Table name=table0
- -
- Creates a flow table record for the OpenFlow table number 0.
-
+
+ When eviction is not enabled, via or
+ an OpenFlow 1.4+ ``table mod,'' this column has no effect.
+
+
+
-
+
+
+ This string set specifies which fields should be used for
+ address prefix tracking. Prefix tracking allows the
+ classifier to skip rules with longer than necessary prefixes,
+ resulting in better wildcarding for datapath flows.
+
+
+ Prefix tracking may be beneficial when a flow table contains
+ matches on IP address fields with different prefix lengths.
+ For example, when a flow table contains IP address matches on
+ both full addresses and proper prefixes, the full address
+ matches will typically cause the datapath flow to un-wildcard
+ the whole address field (depending on flow entry priorities).
+ In this case each packet with a different address gets handed
+ to the userspace for flow processing and generates its own
+ datapath flow. With prefix tracking enabled for the address
+ field in question packets with addresses matching shorter
+ prefixes would generate datapath flows where the irrelevant
+ address bits are wildcarded, allowing the same datapath flow
+ to handle all the packets within the prefix in question. In
+ this case many userspace upcalls can be avoided and the
+ overall performance can be better.
+
+
+ This is a performance optimization only, so packets will
+ receive the same treatment with or without prefix tracking.
+
+
+ The supported fields are: tun_id
,
+ tun_src
, tun_dst
,
+ nw_src
, nw_dst
(or aliases
+ ip_src
and ip_dst
),
+ ipv6_src
, and ipv6_dst
. (Using this
+ feature for tun_id
would only make sense if the
+ tunnel IDs have prefix structure similar to IP addresses.)
+
-
- There is a maximum number of fields that can be enabled for any
- one flow table. Currently this limit is 3.
-
-
+
+ By default, the prefixes=ip_dst,ip_src
are used
+ on each flow table. This instructs the flow classifier to
+ track the IP destination and source addresses used by the
+ rules in this specific flow table.
+
+
+
+ The keyword none
is recognized as an explicit
+ override of the default values, causing no prefix fields to be
+ tracked.
+
+
+
+ To set the prefix fields, the flow table record needs to
+ exist:
+
+
+
+ ovs-vsctl set Bridge br0 flow_tables:0=@N1 -- --id=@N1 create Flow_Table name=table0
+ -
+ Creates a flow table record for the OpenFlow table number 0.
+
+
+ ovs-vsctl set Flow_Table table0 prefixes=ip_dst,ip_src
+ -
+ Enables prefix tracking for IP source and destination
+ address fields.
+
+
+
+
+ There is a maximum number of fields that can be enabled for any
+ one flow table. Currently this limit is 3.
+
+
+
+ type='{"type": "integer"}'>
The Differentiated Service Code Point (DSCP) is specified using 6 bits
in the Type of Service (TOS) field in the IP header. DSCP provides a
mechanism to classify the network traffic and provide Quality of
@@ -4259,18 +4353,18 @@
- The interval at which NetFlow records are sent for flows that
- are still active, in seconds. A value of 0
- requests the default timeout (currently 600 seconds); a value
- of -1
disables active timeouts.
+ The interval at which NetFlow records are sent for flows that
+ are still active, in seconds. A value of 0
+ requests the default timeout (currently 600 seconds); a value
+ of -1
disables active timeouts.
- The NetFlow passive timeout, for flows that become inactive,
- is not configurable. It will vary depending on the Open
- vSwitch version, the forms and contents of the OpenFlow flow
- tables, CPU and memory usage, and network activity. A typical
- passive timeout is about a second.
+ The NetFlow passive timeout, for flows that become inactive,
+ is not configurable. It will vary depending on the Open
+ vSwitch version, the forms and contents of the OpenFlow flow
+ tables, CPU and memory usage, and network activity. A typical
+ passive timeout is about a second.
@@ -4490,7 +4584,7 @@
data type semantics: identifier.
description: Key which is used for identifying an individual
traffic flow within a VxLAN (24-bit VNI), GENEVE (24-bit VNI),
- GRE (32- or 64-bit key), or LISP (24-bit instance ID) tunnel. The
+ GRE (32-bit key), or LISP (24-bit instance ID) tunnel. The
key is encoded in this octetarray as a 3-, 4-, or 8-byte integer
ID in network byte order.
@@ -4597,39 +4691,46 @@