- <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="external_ids" key="iface-status"
+ type='{"type": "string",
+ "enum": ["set", ["active", "inactive"]]}'>
+ <p>
+ Hypervisors may sometimes have more than one interface associated
+ with a given <ref column="external_ids" key="iface-id"/>, only one of
+ which is actually in use at a given time. For example, in some
+ circumstances XenServer has both a ``tap'' and a ``vif'' interface
+ for a single <ref column="external_ids" key="iface-id"/>, but only
+ uses one of them at a time. A hypervisor that behaves this way must
+ mark the currently in use interface <code>active</code> and the
+ others <code>inactive</code>. A hypervisor that never has more than
+ one interface for a given <ref column="external_ids" key="iface-id"/>
+ may mark that interface <code>active</code> or omit <ref
+ column="external_ids" key="iface-status"/> entirely.
+ </p>
+
+ <p>
+ During VM migration, a given <ref column="external_ids"
+ key="iface-id"/> might transiently be marked <code>active</code> on
+ two different hypervisors. That is, <code>active</code> means that
+ this <ref column="external_ids" key="iface-id"/> is the active
+ instance within a single hypervisor, not in a broader scope.
+ </p>
+ </column>
+
+ <column name="external_ids" key="xs-vif-uuid">
+ The virtual interface associated with this interface.
+ </column>
+
+ <column name="external_ids" key="xs-network-uuid">
+ The virtual network to which this interface is attached.
+ </column>
+
+ <column name="external_ids" key="vm-id">
+ The VM to which this interface belongs. On XenServer, this will be the
+ same as <ref column="external_ids" key="xs-vm-uuid"/>.
+ </column>
+
+ <column name="external_ids" key="xs-vm-uuid">
+ The VM to which this interface belongs.
+ </column>
+ </group>
+
+ <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.
+ </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
+ the interface on the particular VLAN.
+ </p>
+
+ <p>
+ VLAN splinters consider a VLAN to be in use if:
+ </p>
+
+ <ul>
+ <li>
+ The VLAN is the <ref table="Port" column="tag"/> value in any <ref
+ table="Port"/> record.
+ </li>
+
+ <li>
+ The VLAN is listed within the <ref table="Port" column="trunks"/>
+ column of the <ref table="Port"/> record of an interface on which
+ VLAN splinters are enabled.
+
+ An empty <ref table="Port" column="trunks"/> does not influence the
+ in-use VLANs: creating 4,096 VLAN devices is impractical because it
+ will exceed the current 1,024 port per datapath limit.
+ </li>
+
+ <li>
+ An OpenFlow flow within any bridge matches the VLAN.
+ </li>
+ </ul>
+
+ <p>
+ The same set of in-use VLANs applies to every interface on which VLAN
+ splinters are enabled. That is, the set is not chosen separately for
+ each interface but selected once as the union of all in-use VLANs based
+ on the rules above.
+ </p>
+
+ <p>
+ It does not make sense to enable VLAN splinters on an interface for an
+ access port, or on an interface that is not a physical port.
+ </p>
+
+ <p>
+ 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"
+ type='{"type": "boolean"}'>
+ <p>
+ Set to <code>true</code> to enable VLAN splinters on this interface.
+ Defaults to <code>false</code>.
+ </p>
+
+ <p>
+ VLAN splinters increase kernel and userspace memory overhead, so do
+ not use them unless they are needed.
+ </p>
+
+ <p>
+ VLAN splinters do not support 802.1p priority tags. Received
+ priorities will appear to be 0, regardless of their actual values,
+ and priorities on transmitted packets will also be cleared to 0.
+ </p>
+ </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.
+
+ <column name="other_config"/>
+ <column name="external_ids"/>
+ </group>
+ </table>
+
+ <table name="Flow_Table" title="OpenFlow table configuration">
+ <p>Configuration for a particular OpenFlow table.</p>
+
+ <column name="name">
+ The table's name. Set this column to change the name that controllers
+ will receive when they request table statistics, e.g. <code>ovs-ofctl
+ 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">
+ <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>
+
+ <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>
+
+ <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>
+ When a flow must be evicted due to overflow, the flow to evict is
+ chosen through an approximation of the following algorithm:
+ </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.
+ </li>
+
+ <li>
+ Consider the flows in the largest group, that is, the group that
+ contains the greatest number of flows. If two or more groups all
+ have the same largest number of flows, consider the flows in all of
+ those groups.
+ </li>
+
+ <li>
+ Among the flows under consideration, choose the flow that expires
+ soonest for eviction.
+ </li>
+ </ol>
+
+ <p>
+ 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>