The maximum
number of flows allowed in the datapath flow table. Internally OVS
will choose a flow limit which will likely be lower than this number,
- based on real time network conditions.
+ based on real time network conditions. Tweaking this value is
+ discouraged unless you know exactly what you're doing.
</p>
<p>
The default is 200000.
</p>
</column>
- <column name="other_config" key="n-dpdk-rxqs"
- type='{"type": "integer", "minInteger": 1}'>
+ <column name="other_config" key="max-idle"
+ type='{"type": "integer", "minInteger": 500}'>
+ <p>
+ The maximum time (in ms) that idle flows will remain cached in the
+ datapath. Internally OVS will check the validity and activity for
+ datapath flows regularly and may expire flows quicker than this
+ number, based on real time network conditions. Tweaking this
+ value is discouraged unless you know exactly what you're doing.
+ </p>
<p>
- Specifies the number of rx queues to be created for each dpdk
- interface. If not specified or specified to 0, one rx queue will
- be created for each dpdk interface by default.
+ The default is 10000.
</p>
</column>
</group>
+ <group title="Capabilities">
+ <p>
+ These columns report capabilities of the Open vSwitch instance.
+ </p>
+ <column name="datapath_types">
+ <p>
+ This column reports the different dpifs registered with the system.
+ These are the values that this instance supports in the <ref
+ column="datapath_type" table="Bridge"/> column of the <ref
+ table="Bridge"/> table.
+ </p>
+ </column>
+ <column name="iface_types">
+ <p>
+ This column reports the different netdevs registered with the system.
+ These are the values that this instance supports in the <ref
+ column="type" table="Interface"/> column of the <ref
+ table="Interface"/> table.
+ </p>
+ </column>
+ </group>
+
<group title="Database Configuration">
<p>
These columns primarily configure the Open vSwitch database
<group title="Core Features">
<column name="name">
- Bridge identifier. Should be alphanumeric and no more than about 8
- bytes long. Must be unique among the names of ports, interfaces, and
- bridges on a host.
+ <p>
+ Bridge identifier. Should be alphanumeric and no more than about 8
+ bytes long. Must be unique among the names of ports, interfaces, and
+ bridges on a host.
+ </p>
+
+ <p>
+ Forward and backward slashes are prohibited in bridge names.
+ </p>
</column>
<column name="ports">
</column>
<column name="auto_attach">
- Auto Attach configuration.
+ Auto Attach configuration.
</column>
</group>
</column>
<column name="protocols">
- <p>
- 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.
- </p>
+ 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.
+ </p>
- <p>
- OpenFlow 1.4 is not enabled by default because its implementation is
- missing features.
- </p>
+ OpenFlow 1.4 is not enabled by default because its implementation is
+ missing features.
+ </p>
<p>
OpenFlow 1.5 has the same risks as OpenFlow 1.4, but it is even more
<group title="Multicast Snooping Configuration">
Multicast snooping (RFC 4541) monitors the Internet Group Management
- Protocol (IGMP) traffic between hosts and multicast routers. The
- switch uses what IGMP snooping learns to forward multicast traffic
- only to interfaces that are connected to interested receivers.
- Currently it supports IGMPv1 and IGMPv2 protocols.
+ Protocol (IGMP) and Multicast Listener Discovery traffic between hosts
+ and multicast routers. The switch uses what IGMP and MLD snooping
+ learns to forward multicast traffic only to interfaces that are connected
+ to interested receivers. Currently it supports IGMPv1, IGMPv2, IGMPv3,
+ MLDv1 and MLDv2 protocols.
<column name="mcast_snooping_enable">
Enable multicast snooping on the bridge. For now, the default
<group title="Other Features">
<column name="datapath_type">
- Name of datapath provider. The kernel datapath has
- type <code>system</code>. The userspace datapath has
- type <code>netdev</code>.
+ Name of datapath provider. The kernel datapath has type
+ <code>system</code>. The userspace datapath has type
+ <code>netdev</code>. A manager may refer to the <ref
+ table="Open_vSwitch" column="datapath_types"/> column of the <ref
+ table="Open_vSwitch"/> table for a list of the types accepted by this
+ Open vSwitch instance.
</column>
<column name="external_ids" key="bridge-id">
<column name="other_config" key="forward-bpdu"
type='{"type": "boolean"}'>
- Option to allow forwarding of BPDU frames when NORMAL action is
- invoked. Frames with reserved Ethernet addresses (e.g. STP
- BPDU) will be forwarded when this option is enabled and the
- switch is not providing that functionality. If STP is enabled
- on the port, STP BPDUs will never be forwarded. If the Open
- vSwitch bridge is used to connect different Ethernet networks,
- and if Open vSwitch node does not run STP, then this option
- should be enabled. Default is disabled, set to
- <code>true</code> to enable.
-
- The following destination MAC addresss will not be forwarded when this
- option is enabled.
+
+ <p>
+ Controls forwarding of BPDUs and other network control frames when
+ NORMAL action is invoked. When this option is <code>false</code> or
+ unset, frames with reserved Ethernet addresses (see table below) will
+ not be forwarded. When this option is <code>true</code>, such frames
+ will not be treated specially.
+ </p>
+
+ <p>
+ The above general rule has the following exceptions:
+ </p>
+
+ <ul>
+ <li>
+ If STP is enabled on the bridge (see the <ref column="stp_enable"
+ table="Bridge"/> column in the <ref table="Bridge"/> table), the
+ bridge processes all received STP packets and never passes them to
+ OpenFlow or forwards them. This is true even if STP is disabled on
+ an individual port.
+ </li>
+
+ <li>
+ If LLDP is enabled on an interface (see the <ref column="lldp"
+ table="Interface"/> column in the <ref table="Interface"/> table),
+ the interface processes received LLDP packets and never passes them
+ to OpenFlow or forwards them.
+ </li>
+ </ul>
+
+ <p>
+ Set this option to <code>true</code> if the Open vSwitch bridge
+ connects different Ethernet networks and is not configured to
+ participate in STP.
+ </p>
+
+ <p>
+ This option affects packets with the following destination MAC
+ addresses:
+ </p>
+
<dl>
<dt><code>01:80:c2:00:00:00</code></dt>
<dd>IEEE 802.1D Spanning Tree Protocol (STP).</dd>
<dd>Extreme Discovery Protocol (EDP).</dd>
<dt>
- <code>00:e0:2b:00:00:04</code> and <code>00:e0:2b:00:00:06</code>
- </dt>
+ <code>00:e0:2b:00:00:04</code> and <code>00:e0:2b:00:00:06</code>
+ </dt>
<dd>Ethernet Automatic Protection Switching (EAPS).</dd>
<dt><code>01:00:0c:cc:cc:cc</code></dt>
<column name="external_ids"/>
</group>
</table>
-
- <table name="Port" table="Port or bond configuration.">
+
+
<table name="Port" table="Port or bond configuration.">
<p>A port within a <ref table="Bridge"/>.</p>
<p>Most commonly, a port has exactly one ``interface,'' pointed to by its
<ref column="interfaces"/> column. Such a port logically
</column>
<column name="other_config" key="lacp-time"
- type='{"type": "string", "enum": ["set", ["fast", "slow"]]}'>
+ type='{"type": "string", "enum": ["set", ["fast", "slow"]]}'>
<p>
The LACP timing which should be used on this <ref table="Port"/>.
By default <code>slow</code> is used. When configured to be
</column>
<column name="other_config" key="lacp-fallback-ab"
- type='{"type": "boolean"}'>
+ type='{"type": "boolean"}'>
<p>
Determines the behavior of openvswitch bond in LACP mode. If
the partner switch does not support LACP, setting this option
<code>fake-bridge-</code>,
e.g. <code>fake-bridge-xs-network-uuids</code>.
</column>
+
+ <column name="other_config" key="transient"
+ type='{"type": "boolean"}'>
+ <p>
+ If set to <code>true</code>, the port will be removed when
+ <code>ovs-ctl start --delete-transient-ports</code> is used.
+ </p>
+ </column>
</group>
<column name="bond_active_slave">
</column>
<group title="OpenFlow Port Number">
- <p>
- 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 <ref column="ofport_request"/>, 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 <ref
- column="ofport"/> the port number actually assigned.
- </p>
-
- <p>
- 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.
- </p>
-
- <column name="ofport">
- <p>
- OpenFlow port number for this interface. Open vSwitch sets this
- column's value, so other clients should treat it as read-only.
- </p>
- <p>
- The OpenFlow ``local'' port (<code>OFPP_LOCAL</code>) 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.
- </p>
- </column>
-
- <column name="ofport_request"
- type='{"type": "integer", "minInteger": 1, "maxInteger": 65279}'>
- <p>
- Requested OpenFlow port number for this interface.
- </p>
-
- <p>
- 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.
- </p>
-
- <p>
- If <ref column="ofport_request"/> is set or changed to some other
- port's automatically assigned port number, Open vSwitch chooses a
- new port number for the latter port.
- </p>
- </column>
+ 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 <ref column="ofport_request"/>, 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 <ref
+ column="ofport"/> the port number actually assigned.
+ </p>
+
+ 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.
+ </p>
+
+ <column name="ofport">
+ OpenFlow port number for this interface. Open vSwitch sets this
+ column's value, so other clients should treat it as read-only.
+ </p>
+ The OpenFlow ``local'' port (<code>OFPP_LOCAL</code>) 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.
+ </p>
+ </column>
+
+ <column name="ofport_request"
+ type='{"type": "integer", "minInteger": 1, "maxInteger": 65279}'>
+ Requested OpenFlow port number for this interface.
+ </p>
+
+ 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.
+ </p>
+
+ If <ref column="ofport_request"/> is set or changed to some other
+ port's automatically assigned port number, Open vSwitch chooses a
+ new port number for the latter port.
+ </p>
+ </column>
</group>
</group>
<group title="System-Specific Details">
<column name="type">
<p>
- The interface type, one of:
+ The interface type. The types supported by a particular instance of
+ Open vSwitch are listed in the <ref table="Open_vSwitch"
+ column="iface_types"/> column in the <ref table="Open_vSwitch"/>
+ table. The following types are defined:
</p>
<dl>
<dt><code>geneve</code></dt>
<dd>
- An Ethernet over Geneve (<code>http://tools.ietf.org/html/draft-gross-geneve-00</code>)
+ An Ethernet over Geneve (<code>http://tools.ietf.org/html/draft-ietf-nvo3-geneve-00</code>)
IPv4 tunnel.
- Geneve supports options as a means to transport additional metadata,
- however, currently only the 24-bit VNI is supported. This is planned
- to be extended in the future.
+ A description of how to match and set Geneve options can be found
+ in the <code>ovs-ofctl</code> manual page.
</dd>
<dt><code>gre</code></dt>
IPsec tunnel.
</dd>
- <dt><code>gre64</code></dt>
- <dd>
- It is same as GRE, but it allows 64 bit key. To store higher 32-bits
- of key, it uses GRE protocol sequence number field. This is non
- standard use of GRE protocol since OVS does not increment
- sequence number for every packet at time of encap as expected by
- standard GRE implementation. See <ref group="Tunnel Options"/>
- for information on configuring GRE tunnels.
- </dd>
-
- <dt><code>ipsec_gre64</code></dt>
- <dd>
- Same as IPSEC_GRE except 64 bit key.
- </dd>
-
<dt><code>vxlan</code></dt>
<dd>
- <p>
- An Ethernet tunnel over the UDP-based VXLAN protocol described in
- RFC 7348.
- </p>
- <p>
- 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.
- </p>
+ An Ethernet tunnel over the UDP-based VXLAN protocol described in
+ RFC 7348.
+ </p>
+ 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.
+ </p>
</dd>
<dt><code>lisp</code></dt>
</p>
</dd>
+ <dt><code>stt</code></dt>
+ <dd>
+ The Stateless TCP Tunnel (STT) is particularly useful when tunnel
+ endpoints are in end-systems, as it utilizes the capabilities of
+ standard network interface cards to improve performance. STT utilizes
+ a TCP-like header inside the IP header. It is stateless, i.e., there is
+ no TCP connection state of any kind associated with the tunnel. The
+ TCP-like header is used to leverage the capabilities of existing
+ network interface cards, but should not be interpreted as implying
+ any sort of connection state between endpoints.
+ Since the STT protocol does not engage in the usual TCP 3-way handshake,
+ so it will have difficulty traversing stateful firewalls.
+ The protocol is documented at
+ http://www.ietf.org/archive/id/draft-davie-stt-06.txt
+
+ All traffic uses a default destination port of 7471. STT is only
+ available in kernel datapath on kernel 3.5 or newer.
+ </dd>
+
<dt><code>patch</code></dt>
<dd>
A pair of virtual devices that act as a patch cable.
<dt><code>null</code></dt>
<dd>An ignored interface. Deprecated and slated for removal in
- February 2013.</dd>
+ February 2013.</dd>
</dl>
</column>
</group>
<p>
These options apply to interfaces with <ref column="type"/> of
<code>geneve</code>, <code>gre</code>, <code>ipsec_gre</code>,
- <code>gre64</code>, <code>ipsec_gre64</code>, <code>vxlan</code>,
- and <code>lisp</code>.
+ <code>vxlan</code>, <code>lisp</code> and <code>stt</code>.
</p>
<p>
</ul>
<p>
- The remote tunnel endpoint for any packet received from a tunnel
- is available in the <code>tun_src</code> field for matching in the
- flow table.
+ The remote tunnel endpoint for any packet received from a tunnel
+ is available in the <code>tun_src</code> field for matching in the
+ flow table.
</p>
</column>
</li>
<li>
A positive 24-bit (for Geneve, VXLAN, and LISP), 32-bit (for GRE)
- or 64-bit (for GRE64) number. The tunnel receives only packets
- with the specified key.
+ or 64-bit (for STT) number. The tunnel receives only
+ packets with the specified key.
</li>
<li>
The word <code>flow</code>. The tunnel accepts packets with any
</li>
<li>
A positive 24-bit (for Geneve, VXLAN and LISP), 32-bit (for GRE) or
- 64-bit (for GRE64) number. Packets sent through the tunnel will
- have the specified key.
+ 64-bit (for STT) number. Packets sent through the tunnel
+ will have the specified key.
</li>
<li>
The word <code>flow</code>. Packets sent through the tunnel will
<group title="Tunnel Options: vxlan only">
- <column name="options" key="exts">
- <p>Optional. Comma separated list of optional VXLAN extensions to
- enable. The following extensions are supported:</p>
+ <column name="options" key="exts">
+
<p>Optional. Comma separated list of optional VXLAN extensions to
+ enable. The following extensions are supported:</p>
- <ul>
- <li>
- <code>gbp</code>: VXLAN-GBP allows to transport the group policy
- context of a packet across the VXLAN tunnel to other network
- peers. See the field description of <code>tun_gbp_id</code> and
- <code>tun_gbp_flags</code> in ovs-ofctl(8) for additional
- information.
- (<code>https://tools.ietf.org/html/draft-smith-vxlan-group-policy</code>)
- </li>
- </ul>
- </column>
+ <li>
+ <code>gbp</code>: VXLAN-GBP allows to transport the group policy
+ context of a packet across the VXLAN tunnel to other network
+ peers. See the field description of <code>tun_gbp_id</code> and
+ <code>tun_gbp_flags</code> in ovs-ofctl(8) for additional
+ information.
+ (<code>https://tools.ietf.org/html/draft-smith-vxlan-group-policy</code>)
+ </li>
+ </ul>
+ </column>
- </group>
+ </group>
- <group title="Tunnel Options: gre and ipsec_gre only">
+ <group title="Tunnel Options: gre, ipsec_gre, geneve, and vxlan">
<p>
- Only <code>gre</code> and <code>ipsec_gre</code> interfaces support
- these options.
+ <code>gre</code>, <code>ipsec_gre</code>, <code>geneve</code>, and
+ <code>vxlan</code> interfaces support these options.
</p>
<column name="options" key="csum" type='{"type": "boolean"}'>
<p>
- Optional. Compute GRE checksums on outgoing packets. Default is
- disabled, set to <code>true</code> to enable. Checksums present on
- incoming packets will be validated regardless of this setting.
- </p>
-
- <p>
- 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.
+ Optional. Compute encapsulation header (either GRE or UDP)
+ checksums on outgoing packets. Default is disabled, set to
+ <code>true</code> to enable. Checksums present on incoming
+ packets will be validated regardless of this setting.
+ </p>
+
+ <p>
+ When using the upstream Linux kernel module, computation of
+ checksums for <code>geneve</code> and <code>vxlan</code> requires
+ Linux kernel version 4.0 or higher. <code>gre</code> supports
+ checksums for all versions of Open vSwitch that support GRE.
+ The out of tree kernel module distributed as part of OVS
+ can compute all tunnel checksums on any kernel version that it
+ is compatible with.
</p>
<p>
- This option is supported for <code>ipsec_gre</code>, but not useful
- because GRE checksums are weaker than, and redundant with, IPsec
- payload authentication.
+ This option is supported for <code>ipsec_gre</code>, but not useful
+ because GRE checksums are weaker than, and redundant with, IPsec
+ payload authentication.
</p>
</column>
</group>
</column>
</group>
+ <group title="PMD (Poll Mode Driver) Options">
+ <p>
+ Only PMD netdevs support these options.
+ </p>
+
+ <column name="options" key="n_rxqs"
+ type='{"type": "integer", "minInteger": 1}'>
+ <p>
+ Specifies the maximum number of rx queues to be created for PMD
+ netdev. If not specified or specified to 0, one rx queue will
+ be created by default.
+ </p>
+ </column>
+ </group>
+
<group title="Interface Status">
<p>
Status information about interfaces attached to bridges, updated every
<group title="Bidirectional Forwarding Detection (BFD)">
<p>
- 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.
</p>
<p>
- 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.
</p>
<p>
- 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.
</p>
<group title="BFD Configuration">
- <p>
- A controller sets up key-value pairs in the <ref column="bfd"/>
- column to enable and configure BFD.
- </p>
+ A controller sets up key-value pairs in the <ref column="bfd"/>
+ column to enable and configure BFD.
+ </p>
- <column name="bfd" key="enable" type='{"type": "boolean"}'>
+ <column name="bfd" key="enable" type='{"type": "boolean"}'>
True to enable BFD on this <ref table="Interface"/>. If not
specified, BFD will not be enabled by default.
- </column>
+ </column>
- <column name="bfd" key="min_rx"
- type='{"type": "integer", "minInteger": 1}'>
+ <column name="bfd" key="min_rx"
+ type='{"type": "integer", "minInteger": 1}'>
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
<code>1000</code>.
- </column>
+ </column>
- <column name="bfd" key="min_tx"
- type='{"type": "integer", "minInteger": 1}'>
+ <column name="bfd" key="min_tx"
+ type='{"type": "integer", "minInteger": 1}'>
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 <code>100</code>.
- </column>
-
- <column name="bfd" key="decay_min_rx" type='{"type": "integer"}'>
- An alternate receive interval, in milliseconds, that must be greater
- than or equal to <ref column="bfd" key="min_rx"/>. The
- implementation switches from <ref column="bfd" key="min_rx"/> to <ref
- column="bfd" key="decay_min_rx"/> 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 <ref
- column="bfd" key="decay_min_rx"/> or <ref column="bfd" key="min_rx"/>
- changes.
- </column>
-
- <column name="bfd" key="forwarding_if_rx" type='{"type": "boolean"}'>
+ </column>
+
+ <column name="bfd" key="decay_min_rx" type='{"type": "integer"}'>
+ An alternate receive interval, in milliseconds, that must be greater
+ than or equal to <ref column="bfd" key="min_rx"/>. The
+ implementation switches from <ref column="bfd" key="min_rx"/> to <ref
+ column="bfd" key="decay_min_rx"/> 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 <ref
+ column="bfd" key="decay_min_rx"/> or <ref column="bfd" key="min_rx"/>
+ changes.
+ </column>
+
+ <column name="bfd" key="forwarding_if_rx" type='{"type": "boolean"}'>
When <code>true</code>, traffic received on the
<ref table="Interface"/> is used to indicate the capability of packet
I/O. BFD control packets are still transmitted and received. At
column="bfd" key="min_rx"/> amount of time. Otherwise, even if
traffic are received, the <ref column="bfd" key="forwarding"/>
will be <code>false</code>.
- </column>
+ </column>
- <column name="bfd" key="cpath_down" type='{"type": "boolean"}'>
- 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.
- </column>
+ <column name="bfd" key="cpath_down" type='{"type": "boolean"}'>
+ 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.
+ </column>
- <column name="bfd" key="check_tnl_key" type='{"type": "boolean"}'>
+ <column name="bfd" key="check_tnl_key" type='{"type": "boolean"}'>
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.
- </column>
-
- <column name="bfd" key="bfd_local_src_mac">
- Set to an Ethernet address in the form
- <var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>
- to set the MAC used as source for transmitted BFD packets. The
- default is the mac address of the BFD enabled interface.
- </column>
-
- <column name="bfd" key="bfd_local_dst_mac">
- Set to an Ethernet address in the form
- <var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>
- to set the MAC used as destination for transmitted BFD packets. The
- default is <code>00:23:20:00:00:01</code>.
- </column>
-
- <column name="bfd" key="bfd_remote_dst_mac">
- Set to an Ethernet address in the form
- <var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>
- 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.
- </column>
-
- <column name="bfd" key="bfd_src_ip">
+ </column>
+
+ <column name="bfd" key="bfd_local_src_mac">
+ Set to an Ethernet address in the form
+ <var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>
+ to set the MAC used as source for transmitted BFD packets. The
+ default is the mac address of the BFD enabled interface.
+ </column>
+
+ <column name="bfd" key="bfd_local_dst_mac">
+ Set to an Ethernet address in the form
+ <var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>
+ to set the MAC used as destination for transmitted BFD packets. The
+ default is <code>00:23:20:00:00:01</code>.
+ </column>
+
+ <column name="bfd" key="bfd_remote_dst_mac">
+ Set to an Ethernet address in the form
+ <var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>
+ 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.
+ </column>
+
+ <column name="bfd" key="bfd_src_ip">
Set to an IPv4 address to set the IP address used as source for
transmitted BFD packets. The default is <code>169.254.1.1</code>.
- </column>
+ </column>
- <column name="bfd" key="bfd_dst_ip">
+ <column name="bfd" key="bfd_dst_ip">
Set to an IPv4 address to set the IP address used as destination
for transmitted BFD packets. The default is <code>169.254.1.0</code>.
- </column>
+ </column>
</group>
<group title="BFD Status">
- <p>
- The switch sets key-value pairs in the <ref column="bfd_status"/>
- column to report the status of BFD on this interface. When BFD is
- not enabled, with <ref column="bfd" key="enable"/>, the switch clears
- all key-value pairs from <ref column="bfd_status"/>.
- </p>
-
- <column name="bfd_status" key="state"
- type='{"type": "string",
- "enum": ["set", ["admin_down", "down", "init", "up"]]}'>
- Reports the state of the BFD session. The BFD session is fully
- healthy and negotiated if <code>UP</code>.
- </column>
-
- <column name="bfd_status" key="forwarding" type='{"type": "boolean"}'>
- Reports whether the BFD session believes this <ref
- table="Interface"/> may be used to forward traffic. Typically this
- means the local session is signaling <code>UP</code>, and the remote
- system isn't signaling a problem such as concatenated path down.
- </column>
-
- <column name="bfd_status" key="diagnostic">
- 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].
- </column>
-
- <column name="bfd_status" key="remote_state"
- type='{"type": "string",
- "enum": ["set", ["admin_down", "down", "init", "up"]]}'>
- Reports the state of the remote endpoint's BFD session.
- </column>
-
- <column name="bfd_status" key="remote_diagnostic">
- 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].
- </column>
+ The switch sets key-value pairs in the <ref column="bfd_status"/>
+ column to report the status of BFD on this interface. When BFD is
+ not enabled, with <ref column="bfd" key="enable"/>, the switch clears
+ all key-value pairs from <ref column="bfd_status"/>.
+ </p>
+
+ <column name="bfd_status" key="state"
+ type='{"type": "string",
+ "enum": ["set", ["admin_down", "down", "init", "up"]]}'>
+ Reports the state of the BFD session. The BFD session is fully
+ healthy and negotiated if <code>UP</code>.
+ </column>
+
+ <column name="bfd_status" key="forwarding" type='{"type": "boolean"}'>
+ Reports whether the BFD session believes this <ref
+ table="Interface"/> may be used to forward traffic. Typically this
+ means the local session is signaling <code>UP</code>, and the remote
+ system isn't signaling a problem such as concatenated path down.
+ </column>
+
+ <column name="bfd_status" key="diagnostic">
+ 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].
+ </column>
+
+ <column name="bfd_status" key="remote_state"
+ type='{"type": "string",
+ "enum": ["set", ["admin_down", "down", "init", "up"]]}'>
+ Reports the state of the remote endpoint's BFD session.
+ </column>
+
+ <column name="bfd_status" key="remote_diagnostic">
+ 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].
+ </column>
<column name="bfd_status" key="flap_count"
- type='{"type": "integer", "minInteger": 0}'>
+ type='{"type": "integer", "minInteger": 0}'>
Counts the number of <ref column="bfd_status" key="forwarding" />
flaps since start. A flap is considered as a change of the
<ref column="bfd_status" key="forwarding" /> value.
</p>
<p>
- When operating over tunnels which have no <code>in_key</code>, or an
- <code>in_key</code> of <code>flow</code>. CFM will only accept CCMs
- with a tunnel key of zero.
+ When operating over tunnels which have no <code>in_key</code>, or an
+ <code>in_key</code> of <code>flow</code>. CFM will only accept CCMs
+ with a tunnel key of zero.
</p>
<column name="cfm_mpid">
<column name="cfm_remote_opstate">
<p>When in extended mode, indicates the operational state of the
- remote endpoint as either <code>up</code> or <code>down</code>. See
- <ref column="other_config" key="cfm_opstate"/>.
+ remote endpoint as either <code>up</code> or <code>down</code>. See
+ <ref column="other_config" key="cfm_opstate"/>.
</p>
</column>
</p>
<p>
- Demand mode has a couple of caveats:
+ Demand mode has a couple of caveats:
<ul>
<li>
To ensure that ovs-vswitchd has enough time to pull statistics
</column>
<column name="other_config" key="cfm_ccm_vlan"
- type='{"type": "integer", "minInteger": 1, "maxInteger": 4095}'>
+ 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 <code>random</code> in which
case each CCM will be tagged with a different randomly generated VLAN.
</column>
<column name="other_config" key="cfm_ccm_pcp"
- type='{"type": "integer", "minInteger": 1, "maxInteger": 7}'>
+ 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 <ref column="other_config" key="cfm_ccm_vlan"/>. If
<group title="VLAN Splinters">
<p>
- 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.
</p>
<p>
- 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.
</p>
</p>
<p>
- 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.
</p>
<column name="other_config" key="enable-vlan-splinters"
<group title="Auto Attach Configuration">
<p>
- Auto Attach configuration for a particular interface.
+ Auto Attach configuration for a particular interface.
</p>
<column name="lldp" key="enable" type='{"type": "boolean"}'>
- True to enable LLDP on this <ref table="Interface"/>. If not
- specified, LLDP will be disabled by default.
+ True to enable LLDP on this <ref table="Interface"/>. If not
+ specified, LLDP will be disabled by default.
</column>
</group>
dump-tables</code>. The name does not affect switch behavior.
</column>
- <column name="flow_limit">
- 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.
- </column>
-
- <column name="overflow_policy">
+ <group title="Eviction Policy">
<p>
- Controls the switch's behavior when an OpenFlow flow table modification
- request would add flows in excess of <ref column="flow_limit"/>. The
- supported values are:
+ Open vSwitch supports limiting the number of flows that may be
+ installed in a flow table, via the <ref column="flow_limit"/> 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:
</p>
- <dl>
- <dt><code>refuse</code></dt>
- <dd>
- Refuse to add the flow or flows. This is also the default policy
- when <ref column="overflow_policy"/> is unset.
- </dd>
-
- <dt><code>evict</code></dt>
- <dd>
- Delete the flow that will expire soonest. See <ref column="groups"/>
- for details.
- </dd>
- </dl>
- </column>
+ <ul>
+ <li>
+ Set the <ref column="overflow_policy"/> column to <code>evict</code>.
+ </li>
- <column name="groups">
- <p>
- When <ref column="overflow_policy"/> is <code>evict</code>, this
- controls how flows are chosen for eviction when the flow table would
- otherwise exceed <ref column="flow_limit"/> flows. Its value is a set
- of NXM fields or sub-fields, each of which takes one of the forms
- <code><var>field</var>[]</code> or
- <code><var>field</var>[<var>start</var>..<var>end</var>]</code>,
- e.g. <code>NXM_OF_IN_PORT[]</code>. Please see
- <code>nicira-ext.h</code> for a complete list of NXM field names.
- </p>
+ <li>
+ Send an OpenFlow 1.4+ ``table mod request'' to enable eviction for
+ the flow table (e.g. <code>ovs-ofctl -O OpenFlow14 mod-table br0 0
+ evict</code> to enable eviction on flow table 0 of bridge
+ <code>br0</code>).
+ </li>
+ </ul>
<p>
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:
</p>
<ol>
<li>
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 <ref column="groups"/> 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 <ref column="groups"/> is empty, then all
+ of the flows in the flow table are treated as a single group.
</li>
<li>
those groups.
</li>
+ <li>
+ 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.)
+ </li>
+
<li>
Among the flows under consideration, choose the flow that expires
soonest for eviction.
</ol>
<p>
- 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 <ref column="flow_limit"/>.)
</p>
- <p>
- Open vSwitch ignores any invalid or unknown field specifications.
- </p>
+ <column name="flow_limit">
+ 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.
+ </column>
- <p>
- When <ref column="overflow_policy"/> is not <code>evict</code>, this
- column has no effect.
- </p>
- </column>
+ <column name="overflow_policy">
+ <p>
+ Controls the switch's behavior when an OpenFlow flow table
+ modification request would add flows in excess of <ref
+ column="flow_limit"/>. The supported values are:
+ </p>
- <column name="prefixes">
- <p>
- 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.
- </p>
- <p>
- 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.
- </p>
- <p>
- This is a performance optimization only, so packets will
- receive the same treatment with or without prefix tracking.
- </p>
- <p>
- The supported fields are: <code>tun_id</code>,
- <code>tun_src</code>, <code>tun_dst</code>,
- <code>nw_src</code>, <code>nw_dst</code> (or aliases
- <code>ip_src</code> and <code>ip_dst</code>),
- <code>ipv6_src</code>, and <code>ipv6_dst</code>. (Using this
- feature for <code>tun_id</code> would only make sense if the
- tunnel IDs have prefix structure similar to IP addresses.)
- </p>
+ <dl>
+ <dt><code>refuse</code></dt>
+ <dd>
+ Refuse to add the flow or flows. This is also the default policy
+ when <ref column="overflow_policy"/> is unset.
+ </dd>
- <p>
- By default, the <code>prefixes=ip_dst,ip_src</code> 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.
- </p>
+ <dt><code>evict</code></dt>
+ <dd>
+ Delete a flow chosen according to the algorithm described above.
+ </dd>
+ </dl>
+ </column>
- <p>
- The keyword <code>none</code> is recognized as an explicit
- override of the default values, causing no prefix fields to be
- tracked.
- </p>
+ <column name="groups">
+ <p>
+ When <ref column="overflow_policy"/> is <code>evict</code>, this
+ controls how flows are chosen for eviction when the flow table would
+ otherwise exceed <ref column="flow_limit"/> flows. Its value is a
+ set of NXM fields or sub-fields, each of which takes one of the forms
+ <code><var>field</var>[]</code> or
+ <code><var>field</var>[<var>start</var>..<var>end</var>]</code>,
+ e.g. <code>NXM_OF_IN_PORT[]</code>. Please see
+ <code>nicira-ext.h</code> for a complete list of NXM field names.
+ </p>
- <p>
- To set the prefix fields, the flow table record needs to
- exist:
- </p>
+ <p>
+ Open vSwitch ignores any invalid or unknown field specifications.
+ </p>
- <dl>
- <dt><code>ovs-vsctl set Bridge br0 flow_tables:0=@N1 -- --id=@N1 create Flow_Table name=table0</code></dt>
- <dd>
- Creates a flow table record for the OpenFlow table number 0.
- </dd>
+ <p>
+ When eviction is not enabled, via <ref column="overflow_policy"/> or
+ an OpenFlow 1.4+ ``table mod,'' this column has no effect.
+ </p>
+ </column>
+ </group>
- <dt><code>ovs-vsctl set Flow_Table table0 prefixes=ip_dst,ip_src</code></dt>
- <dd>
- Enables prefix tracking for IP source and destination
- address fields.
- </dd>
- </dl>
+ <group title="Classifier Optimization">
+ <column name="prefixes">
+ <p>
+ 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.
+ </p>
+ <p>
+ 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.
+ </p>
+ <p>
+ This is a performance optimization only, so packets will
+ receive the same treatment with or without prefix tracking.
+ </p>
+ <p>
+ The supported fields are: <code>tun_id</code>,
+ <code>tun_src</code>, <code>tun_dst</code>,
+ <code>nw_src</code>, <code>nw_dst</code> (or aliases
+ <code>ip_src</code> and <code>ip_dst</code>),
+ <code>ipv6_src</code>, and <code>ipv6_dst</code>. (Using this
+ feature for <code>tun_id</code> would only make sense if the
+ tunnel IDs have prefix structure similar to IP addresses.)
+ </p>
- <p>
- There is a maximum number of fields that can be enabled for any
- one flow table. Currently this limit is 3.
- </p>
- </column>
+ <p>
+ By default, the <code>prefixes=ip_dst,ip_src</code> 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.
+ </p>
+
+ <p>
+ The keyword <code>none</code> is recognized as an explicit
+ override of the default values, causing no prefix fields to be
+ tracked.
+ </p>
+
+ <p>
+ To set the prefix fields, the flow table record needs to
+ exist:
+ </p>
+
+ <dl>
+ <dt><code>ovs-vsctl set Bridge br0 flow_tables:0=@N1 -- --id=@N1 create Flow_Table name=table0</code></dt>
+ <dd>
+ Creates a flow table record for the OpenFlow table number 0.
+ </dd>
+
+ <dt><code>ovs-vsctl set Flow_Table table0 prefixes=ip_dst,ip_src</code></dt>
+ <dd>
+ Enables prefix tracking for IP source and destination
+ address fields.
+ </dd>
+ </dl>
+
+ <p>
+ There is a maximum number of fields that can be enabled for any
+ one flow table. Currently this limit is 3.
+ </p>
+ </column>
+ </group>
<group title="Common Columns">
The overall purpose of these columns is described under <code>Common
information on how this classifier works.
</dd>
</dl>
+ <dl>
+ <dt><code>linux-sfq</code></dt>
+ <dd>
+ Linux ``Stochastic Fairness Queueing'' classifier. See
+ <code>tc-sfq</code>(8) (also at
+ <code>http://linux.die.net/man/8/tc-sfq</code>) for information on
+ how this classifier works.
+ </dd>
+ </dl>
+ <dl>
+ <dt><code>linux-codel</code></dt>
+ <dd>
+ Linux ``Controlled Delay'' classifier. See <code>tc-codel</code>(8)
+ (also at
+ <code>http://man7.org/linux/man-pages/man8/tc-codel.8.html</code>)
+ for information on how this classifier works.
+ </dd>
+ </dl>
+ <dl>
+ <dt><code>linux-fq_codel</code></dt>
+ <dd>
+ Linux ``Fair Queuing with Controlled Delay'' classifier. See
+ <code>tc-fq_codel</code>(8) (also at
+ <code>http://man7.org/linux/man-pages/man8/tc-fq_codel.8.html</code>)
+ for information on how this classifier works.
+ </dd>
+ </dl>
+ <dl>
+ <dt><code>egress-policer</code></dt>
+ <dd>
+ An egress policer algorithm. This implementation uses the DPDK
+ rte_meter library. The rte_meter library provides an implementation
+ which allows the metering and policing of traffic. The implementation
+ in OVS essentially creates a single token bucket used to police
+ traffic. It should be noted that when the rte_meter is configured as
+ part of QoS there will be a performance overhead as the rte_meter
+ itself will consume CPU cycles in order to police traffic. These CPU
+ cycles ordinarily are used for packet proccessing. As such the drop
+ in performance will be noticed in terms of overall aggregate traffic
+ throughput.
+ </dd>
+ </dl>
</column>
<column name="queues">
</column>
</group>
+ <group title="Configuration for egress-policer QoS">
+ <p>
+ <ref table="QoS"/> <ref table="QoS" column="type"/>
+ <code>egress-policer</code> provides egress policing for userspace
+ port types with DPDK.
+
+ It has the following key-value pairs defined.
+ </p>
+
+ <column name="other_config" key="cir" type='{"type": "integer"}'>
+ The Committed Information Rate (CIR) is measured in bytes of IP
+ packets per second, i.e. it includes the IP header, but not link
+ specific (e.g. Ethernet) headers. This represents the bytes per second
+ rate at which the token bucket will be updated. The cir value is
+ calculated by (pps x packet data size). For example assuming a user
+ wishes to limit a stream consisting of 64 byte packets to 1 million
+ packets per second the CIR would be set to to to 46000000. This value
+ can be broken into '1,000,000 x 46'. Where 1,000,000 is the policing
+ rate for the number of packets per second and 46 represents the size
+ of the packet data for a 64 byte ip packet.
+ </column>
+ <column name="other_config" key="cbs" type='{"type": "integer"}'>
+ The Committed Burst Size (CBS) is measured in bytes and represents a
+ token bucket. At a minimum this value should be be set to the expected
+ largest size packet in the traffic stream. In practice larger values
+ may be used to increase the size of the token bucket. If a packet can
+ be transmitted then the cbs will be decremented by the number of
+ bytes/tokens of the packet. If there are not enough tokens in the cbs
+ bucket the packet will be dropped.
+ </column>
+ </group>
+
<group title="Common Columns">
The overall purpose of these columns is described under <code>Common
Columns</code> at the beginning of this document.
traffic may also be referred to as SPAN or RSPAN, depending on how
the mirrored traffic is sent.</p>
+ <p>
+ When a packet enters an Open vSwitch bridge, it becomes eligible for
+ mirroring based on its ingress port and VLAN. As the packet travels
+ through the flow tables, each time it is output to a port, it becomes
+ eligible for mirroring based on the egress port and VLAN. In Open
+ vSwitch 2.5 and later, mirroring occurs just after a packet first becomes
+ eligible, using the packet as it exists at that point; in Open vSwitch
+ 2.4 and earlier, mirroring occurs only after a packet has traversed all
+ the flow tables, using the original packet as it entered the bridge.
+ This makes a difference only when the flow table modifies the packet: in
+ Open vSwitch 2.4, the modifications are never visible to mirrors, whereas
+ in Open vSwitch 2.5 and later modifications made before the first output
+ that makes it eligible for mirroring to a particular destination are
+ visible.
+ </p>
+
+ <p>
+ A packet that enters an Open vSwitch bridge is mirrored to a particular
+ destination only once, even if it is eligible for multiple reasons. For
+ example, a packet would be mirrored to a particular <ref
+ column="output_port"/> only once, even if it is selected for mirroring to
+ that port by <ref column="select_dst_port"/> and <ref
+ column="select_src_port"/> in the same or different <ref table="Mirror"/>
+ records.
+ </p>
+
<column name="name">
Arbitrary identifier for the <ref table="Mirror"/>.
</column>
</p>
<column name="other_config" key="dscp"
- type='{"type": "integer"}'>
+ 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
</group>
<group title="Status">
- <column name="is_connected">
+ <p>
+ Key-value pair of <ref column="is_connected"/> is always updated.
+ Other key-value pairs in the status columns may be updated depends
+ on the <ref column="target"/> type.
+ </p>
+
+ <p>
+ When <ref column="target"/> specifies a connection method that
+ listens for inbound connections (e.g. <code>ptcp:</code> or
+ <code>punix:</code>), both <ref column="n_connections"/> and
+ <ref column="is_connected"/> may also be updated while the
+ remaining key-value pairs are omitted.
+ </p>
+
+ <p>
+ On the other hand, when <ref column="target"/> specifies an
+ outbound connection, all key-value pairs may be updated, except
+ the above-mentioned two key-value pairs associated with inbound
+ connection targets. They are omitted.
+ </p>
+
+ <column name="is_connected">
<code>true</code> if currently connected to this manager,
<code>false</code> otherwise.
</column>
<column name="status" key="n_connections"
type='{"type": "integer", "minInteger": 2}'>
- <p>
- When <ref column="target"/> specifies a connection method that
- listens for inbound connections (e.g. <code>ptcp:</code> or
- <code>pssl:</code>) and more than one connection is actually active,
- the value is the number of active connections. Otherwise, this
- key-value pair is omitted.
- </p>
- <p>
- When multiple connections are active, status columns and key-value
- pairs (other than this one) report the status of one arbitrarily
- chosen connection.
- </p>
+ When <ref column="target"/> specifies a connection method that
+ listens for inbound connections (e.g. <code>ptcp:</code> or
+ <code>pssl:</code>) and more than one connection is actually active,
+ the value is the number of active connections. Otherwise, this
+ key-value pair is omitted.
</column>
<column name="status" key="bound_port" type='{"type": "integer"}'>
- When <ref column="target"/> is <code>ptcp:</code> or
- <code>pssl:</code>, this is the TCP port on which the OVSDB server is
- listening. (This is is particularly useful when <ref
- column="target"/> specifies a port of 0, allowing the kernel to
- choose any available port.)
+ When <ref column="target"/> is <code>ptcp:</code> or
+ <code>pssl:</code>, this is the TCP port on which the OVSDB server is
+ listening. (This is particularly useful when <ref
+ column="target"/> specifies a port of 0, allowing the kernel to
+ choose any available port.)
</column>
</group>
</p>
<column name="other_config" key="dscp"
- type='{"type": "integer"}'>
+ 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
<column name="active_timeout">
<p>
- The interval at which NetFlow records are sent for flows that
- are still active, in seconds. A value of <code>0</code>
- requests the default timeout (currently 600 seconds); a value
- of <code>-1</code> disables active timeouts.
+ The interval at which NetFlow records are sent for flows that
+ are still active, in seconds. A value of <code>0</code>
+ requests the default timeout (currently 600 seconds); a value
+ of <code>-1</code> disables active timeouts.
</p>
<p>
- 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.
</p>
</column>
<p>data type semantics: identifier.</p>
<p>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.</p>
</dd>
</table>
<table name="AutoAttach">
- <p>Auto Attach configuration within a bridge. The IETF Auto-Attach SPBM
- draft standard describes a compact method of using IEEE 802.1AB Link
- Layer Discovery Protocol (LLDP) together with a IEEE 802.1aq Shortest
- Path Bridging (SPB) network to automatically attach network devices
- to individual services in a SPB network. The intent here is to allow
- network applications and devices using OVS to be able to easily take
- advantage of features offered by industry standard SPB networks.</p>
-
- <p>Auto Attach (AA) uses LLDP to communicate between a directly connected
- Auto Attach Client (AAC) and Auto Attach Server (AAS). The LLDP protocol
- is extended to add two new Type-Length-Value tuples (TLVs). The first
- new TLV supports the ongoing discovery of directly connected AA
- correspondents. Auto Attach operates by regularly transmitting AA
- discovery TLVs between the AA client and AA server. By exchanging these
- discovery messages, both the AAC and AAS learn the system name and
- system description of their peer. In the OVS context, OVS operates as
- the AA client and the AA server resides on a switch at the edge of the
- SPB network.</p>
-
- <p>Once AA discovery has been completed the AAC then uses the
- second new TLV to deliver identifier mappings from the AAC to the AAS. A primary
- feature of Auto Attach is to facilitate the mapping of VLANs defined
- outside the SPB network onto service ids (ISIDs) defined within the SPM
- network. By doing so individual external VLANs can be mapped onto
- specific SPB network services. These VLAN id to ISID mappings can be
- configured and managed locally using new options added to the ovs-vsctl
- command.</p>
-
- <p>The Auto Attach OVS feature does not provide a full implementation of
- the LLDP protocol. Support for the mandatory TLVs as defined by the LLDP
- standard and support for the AA TLV extensions is provided. LLDP
- protocol support in OVS can be enabled or disabled on a port by port
- basis. LLDP support is disabled by default.</p>
+ <p>
+ Auto Attach configuration within a bridge. The IETF Auto-Attach SPBM
+ draft standard describes a compact method of using IEEE 802.1AB Link
+ Layer Discovery Protocol (LLDP) together with a IEEE 802.1aq Shortest
+ Path Bridging (SPB) network to automatically attach network devices
+ to individual services in a SPB network. The intent here is to allow
+ network applications and devices using OVS to be able to easily take
+ advantage of features offered by industry standard SPB networks.
+ </p>
+
+ <p>
+ Auto Attach (AA) uses LLDP to communicate between a directly connected
+ Auto Attach Client (AAC) and Auto Attach Server (AAS). The LLDP protocol
+ is extended to add two new Type-Length-Value tuples (TLVs). The first
+ new TLV supports the ongoing discovery of directly connected AA
+ correspondents. Auto Attach operates by regularly transmitting AA
+ discovery TLVs between the AA client and AA server. By exchanging these
+ discovery messages, both the AAC and AAS learn the system name and
+ system description of their peer. In the OVS context, OVS operates as
+ the AA client and the AA server resides on a switch at the edge of the
+ SPB network.
+ </p>
+
+ <p>
+ Once AA discovery has been completed the AAC then uses the second new TLV
+ to deliver identifier mappings from the AAC to the AAS. A primary feature
+ of Auto Attach is to facilitate the mapping of VLANs defined outside the
+ SPB network onto service ids (ISIDs) defined within the SPM network. By
+ doing so individual external VLANs can be mapped onto specific SPB
+ network services. These VLAN id to ISID mappings can be configured and
+ managed locally using new options added to the ovs-vsctl command.
+ </p>
+
+ <p>
+ The Auto Attach OVS feature does not provide a full implementation of
+ the LLDP protocol. Support for the mandatory TLVs as defined by the LLDP
+ standard and support for the AA TLV extensions is provided. LLDP
+ protocol support in OVS can be enabled or disabled on a port by port
+ basis. LLDP support is disabled by default.
+ </p>
<column name="system_name">
The system_name string is exported in LLDP messages. It should uniquely
</column>
<column name="mappings">
- A mapping from SPB network Individual Service Identifier (ISID) to VLAN id.
+ A mapping from SPB network Individual Service Identifier (ISID) to VLAN
+ id.
</column>
</table>
</database>
projects / cascardo / ovs.git / blobdiff