- <dt><code>patch</code></dt>
- <dd>A pair of virtual devices that act as a patch cable. A
- <code>peer</code> argument is required that indicates the name
- of the other side of the patch. Since a patch must work in
- pairs, a second patch interface must be declared with the
- <code>name</code> and <code>peer</code> arguments reversed.</dd>
- </dl>
- </column>
-
- <column name="options">
- Configuration options whose interpretation varies based on
- <ref column="type"/>.
- </column>
- </group>
-
- <group title="Ingress Policing">
- <column name="ingress_policing_burst">
- <p>Maximum burst size for data received on this interface, in kb. The
- default burst size if set to <code>0</code> is 1000 kb. This value
- has no effect if <ref column="ingress_policing_rate"/>
- is <code>0</code>.</p>
- <p>The burst size should be at least the size of the interface's
- MTU.</p>
- </column>
-
- <column name="ingress_policing_rate">
- <p>Maximum rate for data received on this interface, in kbps. Data
- received faster than this rate is dropped. Set to <code>0</code> to
- disable policing.</p>
- <p>The meaning of ``ingress'' is from Open vSwitch's perspective. If
- configured on a physical interface, then it limits the rate at which
- traffic is allowed into the system from the outside. If configured
- on a virtual interface that is connected to a virtual machine, then
- it limits the rate at which the guest is able to transmit.</p>
- </column>
- </group>
-
- <group title="Other Features">
- <column name="external_ids">
- <p>Key-value pairs that identify this interface's role in external
- systems. All of the currently defined 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 <code>-uuid</code> 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.</p>
- <p>The currently defined key-value pairs are:</p>
- <dl>
- <dt><code>vif-uuid</code></dt>
- <dd>The virtual interface associated with this interface.</dd>
- <dt><code>network-uuid</code></dt>
- <dd>The virtual network to which this interface is attached.</dd>
- <dt><code>vm-uuid</code></dt>
- <dd>The VM to which this interface belongs.</dd>
- <dt><code>vif-mac</code></dt>
- <dd>The MAC address programmed into the "virtual hardware" for this
- interface, in the
- form <var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>.
- For Citrix XenServer, this is the value of the <code>MAC</code>
- field in the VIF record for this interface.</dd>
- </dl>
- </column>
- </group>
- </table>
-
- <table name="Mirror" title="Port mirroring (SPAN/RSPAN).">
- <p>A port mirror within a <ref table="Bridge"/>.</p>
- <p>A port mirror configures a bridge to send selected frames to special
- ``mirrored'' ports, in addition to their normal destinations. Mirroring
- traffic may also be referred to as SPAN or RSPAN, depending on the
- mechanism used for delivery.</p>
-
- <column name="name">
- Arbitrary identifier for the <ref table="Mirror"/>.
- </column>
-
- <group title="Selecting Packets for Mirroring">
- <column name="select_all">
- If true, every packet arriving or departing on any port is
- selected for mirroring.
- </column>
-
- <column name="select_dst_port">
- Ports on which departing packets are selected for mirroring.
- </column>
-
- <column name="select_src_port">
- Ports on which arriving packets are selected for mirroring.
- </column>
-
- <column name="select_vlan">
- VLANs on which packets are selected for mirroring. An empty set
- selects packets on all VLANs.
- </column>
- </group>
-
- <group title="Mirroring Destination Configuration">
- <column name="output_port">
- <p>Output port for selected packets, if nonempty. Mutually exclusive
- with <ref column="output_vlan"/>.</p>
- <p>Specifying a port for mirror output reserves that port exclusively
- for mirroring. No frames other than those selected for mirroring
- will be forwarded to the port, and any frames received on the port
- will be discarded.</p>
- <p>This type of mirroring is sometimes called SPAN.</p>
- </column>
-
- <column name="output_vlan">
- <p>Output VLAN for selected packets, if nonempty. Mutually exclusive
- with <ref column="output_port"/>.</p>
- <p>The frames will be sent out all ports that trunk
- <ref column="output_vlan"/>, as well as any ports with implicit VLAN
- <ref column="output_vlan"/>. When a mirrored frame is sent out a
- trunk port, the frame's VLAN tag will be set to
- <ref column="output_vlan"/>, replacing any existing tag; when it is
- sent out an implicit VLAN port, the frame will not be tagged. This
- type of mirroring is sometimes called RSPAN.</p>
- <p><em>Please note:</em> Mirroring to a VLAN can disrupt a network that
- contains unmanaged switches. Consider an unmanaged physical switch
- with two ports: port 1, connected to an end host, and port 2,
- connected to an Open vSwitch configured to mirror received packets
- into VLAN 123 on port 2. Suppose that the end host sends a packet on
- port 1 that the physical switch forwards to port 2. The Open vSwitch
- forwards this packet to its destination and then reflects it back on
- port 2 in VLAN 123. This reflected packet causes the unmanaged
- physical switch to replace the MAC learning table entry, which
- correctly pointed to port 1, with one that incorrectly points to port
- 2. Afterward, the physical switch will direct packets destined for
- the end host to the Open vSwitch on port 2, instead of to the end
- host on port 1, disrupting connectivity. If mirroring to a VLAN is
- desired in this scenario, then the physical switch must be replaced
- by one that learns Ethernet addresses on a per-VLAN basis. In
- addition, learning should be disabled on the VLAN containing mirrored
- traffic. If this is not done then intermediate switches will learn
- the MAC address of each end host from the mirrored traffic. If
- packets being sent to that end host are also mirrored, then they will
- be dropped since the switch will attempt to send them out the input
- port. Disabling learning for the VLAN will cause the switch to
- correctly send the packet out all ports configured for that VLAN. If
- Open vSwitch is being used as an intermediate switch, learning can be
- disabled by adding the mirrored VLAN to <ref column="flood_vlans"/>
- in the appropriate <ref table="Bridge"/> table or tables.</p>
- </column>
- </group>
- </table>
-
- <table name="Controller" title="OpenFlow controller configuration.">
- <p>An OpenFlow controller.</p>
-
- <p>Open vSwitch permits a bridge to have any number of OpenFlow
- controllers. When multiple controllers are configured, Open vSwitch
- connects to all of them simultaneously. OpenFlow 1.0 does not specify
- how multiple controllers coordinate in interacting with a single switch,
- so more than one controller should be specified only if the controllers
- are themselves designed to coordinate with each other.</p>
-
- <group title="Core Features">
- <column name="target">
- <p>Connection method for controller.
- The following connection methods are currently
- supported:</p>
- <dl>
- <dt><code>ssl:<var>ip</var></code>[<code>:<var>port</var></code>]</dt>
- <dd>
- <p>The specified SSL <var>port</var> (default: 6633) on the host at
- the given <var>ip</var>, which must be expressed as an IP address
- (not a DNS name). The <ref table="Open_vSwitch" column="ssl"/>
- column in the <ref table="Open_vSwitch"/> must point to a valid
- SSL configuration when this form is used.</p>
- <p>SSL support is an optional feature that is not always built as
- part of Open vSwitch.</p>
- </dd>
- <dt><code>tcp:<var>ip</var></code>[<code>:<var>port</var></code>]</dt>
- <dd>The specified TCP <var>port</var> (default: 6633) on the host at
- the given <var>ip</var>, which must be expressed as an IP address
+ <dt><code>ipsec_gre</code></dt>
+ <dd>An Ethernet over RFC 2890 Generic Routing Encapsulation
+ over IPv4 IPsec tunnel. Each tunnel (including those of type
+ <code>gre</code>) must be uniquely identified by the
+ combination of <ref column="options" key="remote_ip"/> and
+ <ref column="options" key="local_ip"/>. Note that if two ports are
+ defined that are the same except one has an optional identifier and
+ the other does not, the more specific one is matched first.
+ An authentication method of <ref column="options" key="peer_cert"/>
+ or <ref column="options" key="psk"/> must be defined. The
+ following options may be specified in the <ref column="options"/>
+ column:
+ <dl>
+ <dt><code>remote_ip</code></dt>
+ <dd>Required. The tunnel endpoint.</dd>
+ </dl>
+ <dl>
+ <dt><code>local_ip</code></dt>
+ <dd>Optional. The destination IP that received packets must
+ match. Default is to match all addresses.</dd>
+ </dl>
+ <dl>
+ <dt><code>peer_cert</code></dt>
+ <dd>Required for certificate authentication. A string
+ containing the peer's certificate in PEM format.
+ Additionally the host's certificate must be specified
+ with the <code>certificate</code> option.</dd>
+ </dl>
+ <dl>
+ <dt><code>certificate</code></dt>
+ <dd>Required for certificate authentication. The name of a
+ PEM file containing a certificate that will be presented
+ to the peer during authentication.</dd>
+ </dl>
+ <dl>
+ <dt><code>private_key</code></dt>
+ <dd>Optional for certificate authentication. The name of
+ a PEM file containing the private key associated with
+ <code>certificate</code>. If <code>certificate</code>
+ contains the private key, this option may be omitted.</dd>
+ </dl>
+ <dl>
+ <dt><code>psk</code></dt>
+ <dd>Required for pre-shared key authentication. Specifies a
+ pre-shared key for authentication that must be identical on
+ both sides of the tunnel.</dd>
+ </dl>
+ <dl>
+ <dt><code>in_key</code></dt>
+ <dd>Optional. The GRE key that received packets must contain.
+ It may either be a 32-bit number (no key and a key of 0 are
+ treated as equivalent) or the word <code>flow</code>. If
+ <code>flow</code> is specified then any key will be accepted
+ and the key will be placed in the <code>tun_id</code> field
+ for matching in the flow table. The ovs-ofctl manual page
+ contains additional information about matching fields in
+ OpenFlow flows. Default is no key.</dd>
+ </dl>
+ <dl>
+ <dt><code>out_key</code></dt>
+ <dd>Optional. The GRE key to be set on outgoing packets. It may
+ either be a 32-bit number or the word <code>flow</code>. If
+ <code>flow</code> is specified then the key may be set using
+ the <code>set_tunnel</code> Nicira OpenFlow vendor extension (0
+ is used in the absence of an action). The ovs-ofctl manual
+ page contains additional information about the Nicira OpenFlow
+ vendor extensions. Default is no key.</dd>
+ </dl>
+ <dl>
+ <dt><code>key</code></dt>
+ <dd>Optional. Shorthand to set <code>in_key</code> and
+ <code>out_key</code> at the same time.</dd>
+ </dl>
+ <dl>
+ <dt><code>tos</code></dt>
+ <dd>Optional. The value of the ToS bits to be set on the
+ encapsulating packet. It may also be the word
+ <code>inherit</code>, in which case the ToS will be copied from
+ the inner packet if it is IPv4 or IPv6 (otherwise it will be
+ 0). Note that the ECN fields are always inherited. Default is
+ 0.</dd>
+ </dl>
+ <dl>
+ <dt><code>ttl</code></dt>
+ <dd>Optional. The TTL to be set on the encapsulating packet.
+ It may also be the word <code>inherit</code>, in which case the
+ TTL will be copied from the inner packet if it is IPv4 or IPv6
+ (otherwise it will be the system default, typically 64).
+ Default is the system default TTL.</dd>
+ </dl>
+ <dl>
+ <dt><code>csum</code></dt>
+ <dd>Optional. Compute GRE checksums on outgoing packets.
+ Checksums present on incoming packets will be validated
+ regardless of this setting. Note that GRE checksums
+ impose a significant performance penalty as they cover the
+ entire packet. As the contents of the packet is typically
+ covered by L3 and L4 checksums, this additional checksum only
+ adds value for the GRE and encapsulated Ethernet headers.
+ Default is disabled, set to <code>true</code> to enable.</dd>
+ </dl>
+ <dl>
+ <dt><code>df_inherit</code></dt>
+ <dd>Optional. If enabled, the Don't Fragment bit will be copied
+ from the inner IP headers (those of the encapsulated traffic)
+ to the outer (tunnel) headers. Default is disabled; set to
+ <code>true</code> to enable.</dd>
+ </dl>
+ <dl>
+ <dt><code>df_default</code></dt>
+ <dd>Optional. If enabled, the Don't Fragment bit will be set by
+ default on tunnel headers if the <code>df_inherit</code> option
+ is not set, or if the encapsulated packet is not IP. Default
+ is enabled; set to <code>false</code> to disable.</dd>
+ </dl>
+ <dl>
+ <dt><code>pmtud</code></dt>
+ <dd>Optional. Enable tunnel path MTU discovery. If enabled
+ ``ICMP Destination Unreachable - Fragmentation Needed''
+ messages will be generated for IPv4 packets with the DF bit set
+ and IPv6 packets above the minimum MTU if the packet size
+ exceeds the path MTU minus the size of the tunnel headers.
+ Note that this option causes behavior that is typically
+ reserved for routers and therefore is not entirely in
+ compliance with the IEEE 802.1D specification for bridges.
+ Default is enabled; set to <code>false</code> to disable.</dd>
+ </dl>
+ </dd>
+ <dt><code>capwap</code></dt>
+ <dd>Ethernet tunneling over the UDP transport portion of CAPWAP
+ (RFC 5415). This allows interoperability with certain switches
+ where GRE is not available. Note that only the tunneling component
+ of the protocol is implemented. Due to the non-standard use of
+ CAPWAP, UDP ports 58881 and 58882 are used as the source and
+ destination ports respectively. Each tunnel must be uniquely
+ identified by the combination of
+ <ref column="options" key="remote_ip"/> and
+ <ref column="options" key="local_ip"/>. If two ports are defined
+ that are the same except one includes
+ <ref column="options" key="local_ip"/> and the other does not, the
+ more specific one is matched first. CAPWAP support is not
+ available on all platforms. Currently it is only supported in the
+ Linux kernel module with kernel versions >= 2.6.25. The following
+ options may be specified in the <ref column="options"/> column:
+ <dl>
+ <dt><code>remote_ip</code></dt>
+ <dd>Required. The tunnel endpoint.</dd>
+ </dl>
+ <dl>
+ <dt><code>local_ip</code></dt>
+ <dd>Optional. The destination IP that received packets must
+ match. Default is to match all addresses.</dd>
+ </dl>
+ <dl>
+ <dt><code>tos</code></dt>
+ <dd>Optional. The value of the ToS bits to be set on the
+ encapsulating packet. It may also be the word
+ <code>inherit</code>, in which case the ToS will be copied from
+ the inner packet if it is IPv4 or IPv6 (otherwise it will be
+ 0). Note that the ECN fields are always inherited. Default is
+ 0.</dd>
+ </dl>
+ <dl>
+ <dt><code>ttl</code></dt>
+ <dd>Optional. The TTL to be set on the encapsulating packet.
+ It may also be the word <code>inherit</code>, in which case the
+ TTL will be copied from the inner packet if it is IPv4 or IPv6
+ (otherwise it will be the system default, typically 64).
+ Default is the system default TTL.</dd>
+ </dl>
+ <dl>
+ <dt><code>in_key</code></dt>
+ <dd>Optional. The WSI key that received packets must contain.
+ It may either be a 64-bit number (no key and a key of 0 are
+ treated as equivalent) or the word <code>flow</code>. If
+ <code>flow</code> is specified then any key will be accepted
+ and the key will be placed in the <code>tun_id</code> field
+ for matching in the flow table. The ovs-ofctl manual page
+ contains additional information about matching fields in
+ OpenFlow flows. Default is no key.</dd>
+ </dl>
+ <dl>
+ <dt><code>out_key</code></dt>
+ <dd>Optional. The WSI key to be set on outgoing packets. It may
+ either be a 64-bit number or the word <code>flow</code>. If
+ <code>flow</code> is specified then the key may be set using
+ the <code>set_tunnel</code> Nicira OpenFlow vendor extension (0
+ is used in the absence of an action). The ovs-ofctl manual
+ page contains additional information about the Nicira OpenFlow
+ vendor extensions. Default is no key.</dd>
+ </dl>
+ <dl>
+ <dt><code>key</code></dt>
+ <dd>Optional. Shorthand to set <code>in_key</code> and
+ <code>out_key</code> at the same time.</dd>
+ </dl>
+ <dl>
+ <dt><code>df_inherit</code></dt>
+ <dd>Optional. If enabled, the Don't Fragment bit will be copied
+ from the inner IP headers (those of the encapsulated traffic)
+ to the outer (tunnel) headers. Default is disabled; set to
+ <code>true</code> to enable.</dd>
+ </dl>
+ <dl>
+ <dt><code>df_default</code></dt>
+ <dd>Optional. If enabled, the Don't Fragment bit will be set by
+ default on tunnel headers if the <code>df_inherit</code> option
+ is not set, or if the encapsulated packet is not IP. Default
+ is enabled; set to <code>false</code> to disable.</dd>
+ </dl>
+ <dl>
+ <dt><code>pmtud</code></dt>
+ <dd>Optional. Enable tunnel path MTU discovery. If enabled
+ ``ICMP Destination Unreachable - Fragmentation Needed''
+ messages will be generated for IPv4 packets with the DF bit set
+ and IPv6 packets above the minimum MTU if the packet size
+ exceeds the path MTU minus the size of the tunnel headers.
+ Note that this option causes behavior that is typically
+ reserved for routers and therefore is not entirely in
+ compliance with the IEEE 802.1D specification for bridges.
+ Default is enabled; set to <code>false</code> to disable.</dd>
+ </dl>
+ <dl>
+ <dt><code>header_cache</code></dt>
+ <dd>Optional. Enable caching of tunnel headers and the output
+ path. This can lead to a significant performance increase
+ without changing behavior. In general it should not be
+ necessary to adjust this setting. However, the caching can
+ bypass certain components of the IP stack (such as IP tables)
+ and it may be useful to disable it if these features are
+ required or as a debugging measure. Default is enabled, set to
+ <code>false</code> to disable.</dd>
+ </dl>
+ </dd>
+ <dt><code>patch</code></dt>
+ <dd>
+ <p>
+ A pair of virtual devices that act as a patch cable. The <ref
+ column="options"/> column must have the following key-value pair:
+ </p>
+ <dl>
+ <dt><code>peer</code></dt>
+ <dd>
+ The <ref column="name"/> of the <ref table="Interface"/> for
+ the other side of the patch. The named <ref
+ table="Interface"/>'s own <code>peer</code> option must specify
+ this <ref table="Interface"/>'s name. That is, the two patch
+ interfaces must have reversed <ref column="name"/> and
+ <code>peer</code> values.
+ </dd>
+ </dl>
+ </dd>
+ <dt><code>null</code></dt>
+ <dd>An ignored interface.</dd>
+ </dl>
+ </column>
+
+ <column name="options">
+ Configuration options whose interpretation varies based on
+ <ref column="type"/>.
+ </column>
+ </group>
+
+ <group title="Interface Status">
+ <p>
+ Status information about interfaces attached to bridges, updated every
+ 5 seconds. Not all interfaces have all of these properties; virtual
+ interfaces don't have a link speed, for example. Non-applicable
+ columns will have empty values.
+ </p>
+ <column name="admin_state">
+ <p>
+ The administrative state of the physical network link.
+ </p>
+ </column>
+
+ <column name="link_state">
+ <p>
+ The observed state of the physical network link. This is ordinarily
+ the link's carrier status. If the interface's <ref table="Port"/> is
+ a bond configured for miimon monitoring, it is instead the network
+ link's miimon status.
+ </p>
+ </column>
+
+ <column name="link_speed">
+ <p>
+ The negotiated speed of the physical network link.
+ Valid values are positive integers greater than 0.
+ </p>
+ </column>
+
+ <column name="duplex">
+ <p>
+ The duplex mode of the physical network link.
+ </p>
+ </column>
+
+ <column name="mtu">
+ <p>
+ The MTU (maximum transmission unit); i.e. the largest
+ amount of data that can fit into a single Ethernet frame.
+ The standard Ethernet MTU is 1500 bytes. Some physical media
+ and many kinds of virtual interfaces can be configured with
+ higher MTUs.
+ </p>
+ <p>
+ This column will be empty for an interface that does not
+ have an MTU as, for example, some kinds of tunnels do not.
+ </p>
+ </column>
+
+ <column name="status">
+ <p>
+ Key-value pairs that report port status. Supported status values are
+ <ref column="type"/>-dependent; some interfaces may not have a valid
+ <ref column="status" key="driver_name"/>, for example.
+ </p>
+ <p>The currently defined key-value pairs are:</p>
+ <dl>
+ <dt><code>driver_name</code></dt>
+ <dd>The name of the device driver controlling the network
+ adapter.</dd>
+ </dl>
+ <dl>
+ <dt><code>driver_version</code></dt>
+ <dd>The version string of the device driver controlling the
+ network adapter.</dd>
+ </dl>
+ <dl>
+ <dt><code>firmware_version</code></dt>
+ <dd>The version string of the network adapter's firmware, if
+ available.</dd>
+ </dl>
+ <dl>
+ <dt><code>source_ip</code></dt>
+ <dd>The source IP address used for an IPv4 tunnel end-point,
+ such as <code>gre</code> or <code>capwap</code>.</dd>
+ </dl>
+ <dl>
+ <dt><code>tunnel_egress_iface</code></dt>
+ <dd>Egress interface for tunnels. Currently only relevant for GRE
+ and CAPWAP tunnels. On Linux systems, this column will show
+ the name of the interface which is responsible for routing
+ traffic destined for the configured
+ <ref column="options" key="remote_ip"/>. This could be an
+ internal interface such as a bridge port.</dd>
+ </dl>
+ <dl>
+ <dt><code>tunnel_egress_iface_carrier</code></dt>
+ <dd>Whether a carrier is detected on
+ <ref column="status" key="tunnel_egress_iface"/>. Valid values
+ are <code>down</code> and <code>up</code>.</dd>
+ </dl>
+ </column>
+ </group>
+
+ <group title="Ingress Policing">
+ <p>
+ These settings control ingress policing for packets received on this
+ interface. On a physical interface, this limits the rate at which
+ traffic is allowed into the system from the outside; on a virtual
+ interface (one connected to a virtual machine), this limits the rate at
+ which the VM is able to transmit.
+ </p>
+ <p>
+ Policing is a simple form of quality-of-service that simply drops
+ packets received in excess of the configured rate. Due to its
+ simplicity, policing is usually less accurate and less effective than
+ egress QoS (which is configured using the <ref table="QoS"/> and <ref
+ table="Queue"/> tables).
+ </p>
+ <p>
+ Policing is currently implemented only on Linux. The Linux
+ implementation uses a simple ``token bucket'' approach:
+ </p>
+ <ul>
+ <li>
+ The size of the bucket corresponds to <ref
+ column="ingress_policing_burst"/>. Initially the bucket is full.
+ </li>
+ <li>
+ Whenever a packet is received, its size (converted to tokens) is
+ compared to the number of tokens currently in the bucket. If the
+ required number of tokens are available, they are removed and the
+ packet is forwarded. Otherwise, the packet is dropped.
+ </li>
+ <li>
+ Whenever it is not full, the bucket is refilled with tokens at the
+ rate specified by <ref column="ingress_policing_rate"/>.
+ </li>
+ </ul>
+ <p>
+ Policing interacts badly with some network protocols, and especially
+ with fragmented IP packets. Suppose that there is enough network
+ activity to keep the bucket nearly empty all the time. Then this token
+ bucket algorithm will forward a single packet every so often, with the
+ period depending on packet size and on the configured rate. All of the
+ fragments of an IP packets are normally transmitted back-to-back, as a
+ group. In such a situation, therefore, only one of these fragments
+ will be forwarded and the rest will be dropped. IP does not provide
+ any way for the intended recipient to ask for only the remaining
+ fragments. In such a case there are two likely possibilities for what
+ will happen next: either all of the fragments will eventually be
+ retransmitted (as TCP will do), in which case the same problem will
+ recur, or the sender will not realize that its packet has been dropped
+ and data will simply be lost (as some UDP-based protocols will do).
+ Either way, it is possible that no forward progress will ever occur.
+ </p>
+ <column name="ingress_policing_rate">
+ <p>
+ Maximum rate for data received on this interface, in kbps. Data
+ received faster than this rate is dropped. Set to <code>0</code>
+ (the default) to disable policing.
+ </p>
+ </column>
+
+ <column name="ingress_policing_burst">
+ <p>Maximum burst size for data received on this interface, in kb. The
+ default burst size if set to <code>0</code> is 1000 kb. This value
+ has no effect if <ref column="ingress_policing_rate"/>
+ is <code>0</code>.</p>
+ <p>
+ Specifying a larger burst size lets the algorithm be more forgiving,
+ which is important for protocols like TCP that react severely to
+ dropped packets. The burst size should be at least the size of the
+ interface's MTU. Specifying a value that is numerically at least as
+ large as 10% of <ref column="ingress_policing_rate"/> helps TCP come
+ closer to achieving the full rate.
+ </p>
+ </column>
+ </group>
+
+ <group title="Connectivity Fault Management">
+ <p>
+ 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.
+ </p>
+
+ <p>
+ 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.
+ </p>
+
+ <column name="cfm_mpid">
+ 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 <ref table="Interface"/>.
+ </column>
+
+ <column name="cfm_fault">
+ <p>
+ Indicates a connectivity fault triggered by an inability to receive
+ heartbeats from any remote endpoint. When a fault is triggered on
+ <ref table="Interface"/>s participating in bonds, they will be
+ disabled.
+ </p>
+ <p>
+ 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.
+ </p>
+ </column>
+
+ <column name="cfm_remote_mpids">
+ 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
+ <ref table="Interface"/> is receiving broadcasts from is regularly
+ collected and written to this column.
+ </column>
+ </group>
+
+ <group title="Other Features">
+
+ <column name="lacp_current">
+ Boolean value indicating LACP status for this interface. If true, this
+ interface has current LACP information about its LACP partner. This
+ information may be used to monitor the health of interfaces in a LACP
+ enabled port. This column will be empty if LACP is not enabled.
+ </column>
+
+ <column name="external_ids">
+ Key-value pairs for use by external frameworks that integrate
+ with Open vSwitch, rather than by Open vSwitch itself. System
+ integrators should either use the Open vSwitch development
+ mailing list to coordinate on common key-value definitions, or
+ choose key names that are likely to be unique. The currently
+ defined common key-value pairs are:
+ <dl>
+ <dt><code>attached-mac</code></dt>
+ <dd>
+ The MAC address programmed into the ``virtual hardware'' for this
+ interface, in the form
+ <var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>.
+ For Citrix XenServer, this is the value of the <code>MAC</code>
+ field in the VIF record for this interface.</dd>
+ <dt><code>iface-id</code></dt>
+ <dd>A system-unique identifier for the interface. On XenServer,
+ this will commonly be the same as
+ <ref column="external_ids" key="xs-vif-uuid"/>.</dd>
+ </dl>
+ <p>
+ Additionally the following key-value pairs specifically
+ apply to an interface that represents a virtual Ethernet interface
+ connected to a virtual machine. These key-value pairs should not be
+ present for other types of interfaces. Keys whose names end
+ in <code>-uuid</code> 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.
+ </p>
+ <p>The currently defined key-value pairs for XenServer are:</p>
+ <dl>
+ <dt><code>xs-vif-uuid</code></dt>
+ <dd>The virtual interface associated with this interface.</dd>
+ <dt><code>xs-network-uuid</code></dt>
+ <dd>The virtual network to which this interface is attached.</dd>
+ <dt><code>xs-vm-uuid</code></dt>
+ <dd>The VM to which this interface belongs.</dd>
+ </dl>
+ </column>
+
+ <column name="other_config">
+ Key-value pairs for rarely used interface features.
+ <dl>
+ <dt><code>cfm_interval</code></dt>
+ <dd> The transmission interval of CFM heartbeats in milliseconds.
+ Three missed heartbeat receptions indicate a connectivity fault.
+ Defaults to 1000ms. </dd>
+ <dt><code>cfm_extended</code></dt>
+ <dd> 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 <code>cfm_interval</code> configuration parameter by breaking
+ wire compatibility with 802.1ag compliant implementations.
+ Defaults to false.</dd>
+ <dt><code>bond-stable-id</code></dt>
+ <dd> A positive integer using in <code>stable</code> bond mode to
+ make slave selection decisions. Allocating
+ <ref column="other_config" key="bond-stable-id"/> values
+ consistently across interfaces participating in a bond will
+ guarantee consistent slave selection decisions across
+ <code>ovs-vswitchd</code> instances when using <code>stable</code>
+ bonding mode.</dd>
+ <dt><code>lacp-port-id</code></dt>
+ <dd> The LACP port ID of this <ref table="Interface"/>. Port IDs are
+ used in LACP negotiations to identify individual ports
+ participating in a bond. Must be a number between 1 and
+ 65535.</dd>
+ <dt><code>lacp-port-priority</code></dt>
+ <dd> The LACP port priority of this <ref table="Interface"/>. In
+ LACP negotiations <ref table="Interface"/>s with numerically lower
+ priorities are preferred for aggregation. Must be a number between
+ 1 and 65535.</dd>
+ <dt><code>lacp-aggregation-key</code></dt>
+ <dd> The LACP aggregation key of this <ref table="Interface"/>.
+ <ref table="Interface"/>s with different aggregation keys may not
+ be active within a given <ref table="Port"/> at the same time. Must
+ be a number between 1 and 65535.</dd>
+ </dl>
+ </column>
+
+ <column name="statistics">
+ <p>
+ Key-value pairs that report interface statistics. The current
+ implementation updates these counters periodically. In the future,
+ we plan to, instead, update them when an interface is created, when
+ they are queried (e.g. using an OVSDB <code>select</code> operation),
+ and just before an interface is deleted due to virtual interface
+ hot-unplug or VM shutdown, and perhaps at other times, but not on any
+ regular periodic basis.</p>
+ <p>
+ The currently defined key-value pairs are listed below. These are
+ the same statistics reported by OpenFlow in its <code>struct
+ ofp_port_stats</code> structure. If an interface does not support a
+ given statistic, then that pair is omitted.</p>
+ <ul>
+ <li>
+ Successful transmit and receive counters:
+ <dl>
+ <dt><code>rx_packets</code></dt>
+ <dd>Number of received packets.</dd>
+ <dt><code>rx_bytes</code></dt>
+ <dd>Number of received bytes.</dd>
+ <dt><code>tx_packets</code></dt>
+ <dd>Number of transmitted packets.</dd>
+ <dt><code>tx_bytes</code></dt>
+ <dd>Number of transmitted bytes.</dd>
+ </dl>
+ </li>
+ <li>
+ Receive errors:
+ <dl>
+ <dt><code>rx_dropped</code></dt>
+ <dd>Number of packets dropped by RX.</dd>
+ <dt><code>rx_frame_err</code></dt>
+ <dd>Number of frame alignment errors.</dd>
+ <dt><code>rx_over_err</code></dt>
+ <dd>Number of packets with RX overrun.</dd>
+ <dt><code>rx_crc_err</code></dt>
+ <dd>Number of CRC errors.</dd>
+ <dt><code>rx_errors</code></dt>
+ <dd>
+ Total number of receive errors, greater than or equal
+ to the sum of the above.
+ </dd>
+ </dl>
+ </li>
+ <li>
+ Transmit errors:
+ <dl>
+ <dt><code>tx_dropped</code></dt>
+ <dd>Number of packets dropped by TX.</dd>
+ <dt><code>collisions</code></dt>
+ <dd>Number of collisions.</dd>
+ <dt><code>tx_errors</code></dt>
+ <dd>
+ Total number of transmit errors, greater
+ than or equal to the sum of the above.
+ </dd>
+ </dl>
+ </li>
+ </ul>
+ </column>
+ </group>
+ </table>
+
+ <table name="QoS" title="Quality of Service configuration">
+ <p>Quality of Service (QoS) configuration for each Port that
+ references it.</p>
+
+ <column name="type">
+ <p>The type of QoS to implement. The <ref table="Open_vSwitch"
+ column="capabilities"/> column in the <ref table="Open_vSwitch"/> table
+ identifies the types that a switch actually supports. The currently
+ defined types are listed below:</p>
+ <dl>
+ <dt><code>linux-htb</code></dt>
+ <dd>
+ Linux ``hierarchy token bucket'' classifier. See tc-htb(8) (also at
+ <code>http://linux.die.net/man/8/tc-htb</code>) and the HTB manual
+ (<code>http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm</code>)
+ for information on how this classifier works and how to configure it.
+ </dd>
+ </dl>
+ <dl>
+ <dt><code>linux-hfsc</code></dt>
+ <dd>
+ Linux "Hierarchical Fair Service Curve" classifier.
+ See <code>http://linux-ip.net/articles/hfsc.en/</code> for
+ information on how this classifier works.
+ </dd>
+ </dl>
+ </column>
+
+ <column name="queues">
+ <p>A map from queue numbers to <ref table="Queue"/> records. The
+ supported range of queue numbers depend on <ref column="type"/>. The
+ queue numbers are the same as the <code>queue_id</code> used in
+ OpenFlow in <code>struct ofp_action_enqueue</code> and other
+ structures. Queue 0 is used by OpenFlow output actions that do not
+ specify a specific queue.</p>
+ </column>
+
+ <column name="other_config">
+ <p>Key-value pairs for configuring QoS features that depend on
+ <ref column="type"/>.</p>
+ <p>The <code>linux-htb</code> and <code>linux-hfsc</code> classes support
+ the following key-value pairs:</p>
+ <dl>
+ <dt><code>max-rate</code></dt>
+ <dd>Maximum rate shared by all queued traffic, in bit/s.
+ Optional. If not specified, for physical interfaces, the
+ default is the link rate. For other interfaces or if the
+ link rate cannot be determined, the default is currently 100
+ Mbps.</dd>
+ </dl>
+ </column>
+
+ <column name="external_ids">
+ Key-value pairs for use by external frameworks that integrate with Open
+ vSwitch, rather than by Open vSwitch itself. System integrators should
+ either use the Open vSwitch development mailing list to coordinate on
+ common key-value definitions, or choose key names that are likely to be
+ unique. No common key-value pairs are currently defined.
+ </column>
+ </table>
+
+ <table name="Queue" title="QoS output queue.">
+ <p>A configuration for a port output queue, used in configuring Quality of
+ Service (QoS) features. May be referenced by <ref column="queues"
+ table="QoS"/> column in <ref table="QoS"/> table.</p>
+
+ <column name="other_config">
+ <p>Key-value pairs for configuring the output queue. The supported
+ key-value pairs and their meanings depend on the <ref column="type"/>
+ of the <ref column="QoS"/> records that reference this row.</p>
+ <p>The key-value pairs defined for <ref table="QoS"/> <ref table="QoS"
+ column="type"/> of <code>min-rate</code> are:</p>
+ <dl>
+ <dt><code>min-rate</code></dt>
+ <dd>Minimum guaranteed bandwidth, in bit/s. Required. The
+ floor value is 1500 bytes/s (12,000 bit/s).</dd>
+ </dl>
+ <p>The key-value pairs defined for <ref table="QoS"/> <ref table="QoS"
+ column="type"/> of <code>linux-htb</code> are:</p>
+ <dl>
+ <dt><code>min-rate</code></dt>
+ <dd>Minimum guaranteed bandwidth, in bit/s.</dd>
+ <dt><code>max-rate</code></dt>
+ <dd>Maximum allowed bandwidth, in bit/s. Optional. If specified, the
+ queue's rate will not be allowed to exceed the specified value, even
+ if excess bandwidth is available. If unspecified, defaults to no
+ limit.</dd>
+ <dt><code>burst</code></dt>
+ <dd>Burst size, in bits. This is the maximum amount of ``credits''
+ that a queue can accumulate while it is idle. Optional. Details of
+ the <code>linux-htb</code> implementation require a minimum burst
+ size, so a too-small <code>burst</code> will be silently
+ ignored.</dd>
+ <dt><code>priority</code></dt>
+ <dd>A nonnegative 32-bit integer. Defaults to 0 if
+ unspecified. A queue with a smaller <code>priority</code>
+ will receive all the excess bandwidth that it can use before
+ a queue with a larger value receives any. Specific priority
+ values are unimportant; only relative ordering matters.</dd>
+ </dl>
+ <p>The key-value pairs defined for <ref table="QoS"/> <ref table="QoS"
+ column="type"/> of <code>linux-hfsc</code> are:</p>
+ <dl>
+ <dt><code>min-rate</code></dt>
+ <dd>Minimum guaranteed bandwidth, in bit/s.</dd>
+ <dt><code>max-rate</code></dt>
+ <dd>Maximum allowed bandwidth, in bit/s. Optional. If specified, the
+ queue's rate will not be allowed to exceed the specified value, even
+ if excess bandwidth is available. If unspecified, defaults to no
+ limit.</dd>
+ </dl>
+ </column>
+
+ <column name="external_ids">
+ Key-value pairs for use by external frameworks that integrate with Open
+ vSwitch, rather than by Open vSwitch itself. System integrators should
+ either use the Open vSwitch development mailing list to coordinate on
+ common key-value definitions, or choose key names that are likely to be
+ unique. No common key-value pairs are currently defined.
+ </column>
+ </table>
+
+ <table name="Mirror" title="Port mirroring (SPAN/RSPAN/ERSPAN).">
+ <p>A port mirror within a <ref table="Bridge"/>.</p>
+ <p>A port mirror configures a bridge to send selected frames to special
+ ``mirrored'' ports, in addition to their normal destinations. Mirroring
+ traffic may also be referred to as SPAN, RSPAN, or ERSPAN, depending on how
+ the mirrored traffic is sent.</p>
+
+ <column name="name">
+ Arbitrary identifier for the <ref table="Mirror"/>.
+ </column>
+
+ <group title="Selecting Packets for Mirroring">
+ <p>
+ To be selected for mirroring, a given packet must enter or leave the
+ bridge through a selected port and it must also be in one of the
+ selected VLANs.
+ </p>
+
+ <column name="select_all">
+ If true, every packet arriving or departing on any port is
+ selected for mirroring.
+ </column>
+
+ <column name="select_dst_port">
+ Ports on which departing packets are selected for mirroring.
+ </column>
+
+ <column name="select_src_port">
+ Ports on which arriving packets are selected for mirroring.
+ </column>
+
+ <column name="select_vlan">
+ VLANs on which packets are selected for mirroring. An empty set
+ selects packets on all VLANs.
+ </column>
+ </group>
+
+ <group title="Mirroring Destination Configuration">
+ <p>
+ These columns are mutually exclusive. Exactly one of them must be
+ nonempty.
+ </p>
+
+ <column name="output_port">
+ <p>Output port for selected packets, if nonempty.</p>
+ <p>Specifying a port for mirror output reserves that port exclusively
+ for mirroring. No frames other than those selected for mirroring
+ will be forwarded to the port, and any frames received on the port
+ will be discarded.</p>
+ <p>
+ The output port may be any kind of port supported by Open vSwitch.
+ It may be, for example, a physical port (sometimes called SPAN), or a
+ GRE tunnel (sometimes called ERSPAN).
+ </p>
+ </column>
+
+ <column name="output_vlan">
+ <p>Output VLAN for selected packets, if nonempty.</p>
+ <p>The frames will be sent out all ports that trunk
+ <ref column="output_vlan"/>, as well as any ports with implicit VLAN
+ <ref column="output_vlan"/>. When a mirrored frame is sent out a
+ trunk port, the frame's VLAN tag will be set to
+ <ref column="output_vlan"/>, replacing any existing tag; when it is
+ sent out an implicit VLAN port, the frame will not be tagged. This
+ type of mirroring is sometimes called RSPAN.</p>
+ <p>
+ The following destination MAC addresses will not be mirrored to a
+ VLAN to avoid confusing switches that interpret the protocols that
+ they represent:
+ </p>
+ <dl>
+ <dt><code>01:80:c2:00:00:00</code></dt>
+ <dd>IEEE 802.1D Spanning Tree Protocol (STP).</dd>
+
+ <dt><code>01:80:c2:00:00:01</code></dt>
+ <dd>IEEE Pause frame.</dd>
+
+ <dt><code>01:80:c2:00:00:0<var>x</var></code></dt>
+ <dd>Other reserved protocols.</dd>
+
+ <dt><code>01:00:0c:cc:cc:cc</code></dt>
+ <dd>
+ Cisco Discovery Protocol (CDP), VLAN Trunking Protocol (VTP),
+ Dynamic Trunking Protocol (DTP), Port Aggregation Protocol (PAgP),
+ and others.
+ </dd>
+
+ <dt><code>01:00:0c:cc:cc:cd</code></dt>
+ <dd>Cisco Shared Spanning Tree Protocol PVSTP+.</dd>
+
+ <dt><code>01:00:0c:cd:cd:cd</code></dt>
+ <dd>Cisco STP Uplink Fast.</dd>
+
+ <dt><code>01:00:0c:00:00:00</code></dt>
+ <dd>Cisco Inter Switch Link.</dd>
+ </dl>
+ <p><em>Please note:</em> Mirroring to a VLAN can disrupt a network that
+ contains unmanaged switches. Consider an unmanaged physical switch
+ with two ports: port 1, connected to an end host, and port 2,
+ connected to an Open vSwitch configured to mirror received packets
+ into VLAN 123 on port 2. Suppose that the end host sends a packet on
+ port 1 that the physical switch forwards to port 2. The Open vSwitch
+ forwards this packet to its destination and then reflects it back on
+ port 2 in VLAN 123. This reflected packet causes the unmanaged
+ physical switch to replace the MAC learning table entry, which
+ correctly pointed to port 1, with one that incorrectly points to port
+ 2. Afterward, the physical switch will direct packets destined for
+ the end host to the Open vSwitch on port 2, instead of to the end
+ host on port 1, disrupting connectivity. If mirroring to a VLAN is
+ desired in this scenario, then the physical switch must be replaced
+ by one that learns Ethernet addresses on a per-VLAN basis. In
+ addition, learning should be disabled on the VLAN containing mirrored
+ traffic. If this is not done then intermediate switches will learn
+ the MAC address of each end host from the mirrored traffic. If
+ packets being sent to that end host are also mirrored, then they will
+ be dropped since the switch will attempt to send them out the input
+ port. Disabling learning for the VLAN will cause the switch to
+ correctly send the packet out all ports configured for that VLAN. If
+ Open vSwitch is being used as an intermediate switch, learning can be
+ disabled by adding the mirrored VLAN to <ref column="flood_vlans"/>
+ in the appropriate <ref table="Bridge"/> table or tables.</p>
+ <p>
+ Mirroring to a GRE tunnel has fewer caveats than mirroring to a
+ VLAN and should generally be preferred.
+ </p>
+ </column>
+ </group>
+
+ <group title="Other Features">
+ <column name="external_ids">
+ Key-value pairs for use by external frameworks that integrate with Open
+ vSwitch, rather than by Open vSwitch itself. System integrators should
+ either use the Open vSwitch development mailing list to coordinate on
+ common key-value definitions, or choose key names that are likely to be
+ unique. No common key-value pairs are currently defined.
+ </column>
+ </group>
+ </table>
+
+ <table name="Controller" title="OpenFlow controller configuration.">
+ <p>An OpenFlow controller.</p>
+
+ <p>
+ Open vSwitch supports two kinds of OpenFlow controllers:
+ </p>
+
+ <dl>
+ <dt>Primary controllers</dt>
+ <dd>
+ <p>
+ This is the kind of controller envisioned by the OpenFlow 1.0
+ specification. Usually, a primary controller implements a network
+ policy by taking charge of the switch's flow table.
+ </p>
+
+ <p>
+ Open vSwitch initiates and maintains persistent connections to
+ primary controllers, retrying the connection each time it fails or
+ drops. The <ref table="Bridge" column="fail_mode"/> column in the
+ <ref table="Bridge"/> table applies to primary controllers.
+ </p>
+
+ <p>
+ Open vSwitch permits a bridge to have any number of primary
+ controllers. When multiple controllers are configured, Open
+ vSwitch connects to all of them simultaneously. Because
+ OpenFlow 1.0 does not specify how multiple controllers
+ coordinate in interacting with a single switch, more than
+ one primary controller should be specified only if the
+ controllers are themselves designed to coordinate with each
+ other. (The Nicira-defined <code>NXT_ROLE</code> OpenFlow
+ vendor extension may be useful for this.)
+ </p>
+ </dd>
+ <dt>Service controllers</dt>
+ <dd>
+ <p>
+ These kinds of OpenFlow controller connections are intended for
+ occasional support and maintenance use, e.g. with
+ <code>ovs-ofctl</code>. Usually a service controller connects only
+ briefly to inspect or modify some of a switch's state.
+ </p>
+
+ <p>
+ Open vSwitch listens for incoming connections from service
+ controllers. The service controllers initiate and, if necessary,
+ maintain the connections from their end. The <ref table="Bridge"
+ column="fail_mode"/> column in the <ref table="Bridge"/> table does
+ not apply to service controllers.
+ </p>
+
+ <p>
+ Open vSwitch supports configuring any number of service controllers.
+ </p>
+ </dd>
+ </dl>
+
+ <p>
+ The <ref column="target"/> determines the type of controller.
+ </p>
+
+ <group title="Core Features">
+ <column name="target">
+ <p>Connection method for controller.</p>
+ <p>
+ The following connection methods are currently supported for primary
+ controllers:
+ </p>
+ <dl>
+ <dt><code>ssl:<var>ip</var></code>[<code>:<var>port</var></code>]</dt>
+ <dd>
+ <p>The specified SSL <var>port</var> (default: 6633) on the host at
+ the given <var>ip</var>, which must be expressed as an IP address
+ (not a DNS name). The <ref table="Open_vSwitch" column="ssl"/>
+ column in the <ref table="Open_vSwitch"/> table must point to a
+ valid SSL configuration when this form is used.</p>
+ <p>SSL support is an optional feature that is not always built as
+ part of Open vSwitch.</p>
+ </dd>
+ <dt><code>tcp:<var>ip</var></code>[<code>:<var>port</var></code>]</dt>
+ <dd>The specified TCP <var>port</var> (default: 6633) on the host at
+ the given <var>ip</var>, which must be expressed as an IP address