information such as destination MAC address, IP address, and TCP
port.
</dd>
-
- <dt><code>stable</code></dt>
- <dd>
- <p>Deprecated and slated for removal in February 2013.</p>
- <p>Attempts to always assign a given flow to the same slave
- consistently. In an effort to maintain stability, no load
- balancing is done. Uses a similar hashing strategy to
- <code>balance-tcp</code>, always taking into account L3 and L4
- fields even if LACP negotiations are unsuccessful. </p>
- <p>Slave selection decisions are made based on <ref table="Interface"
- column="other_config" key="bond-stable-id"/> if set. Otherwise,
- OpenFlow port number is used. Decisions are consistent across all
- <code>ovs-vswitchd</code> instances with equivalent
- <ref table="Interface" column="other_config" key="bond-stable-id"/>
- values.</p>
- </dd>
</dl>
<p>These columns apply only to bonded ports. Their values are
on a host.
</column>
+ <column name="mac_in_use">
+ The MAC address in use by this interface.
+ </column>
+
<column name="mac">
<p>Ethernet address to set for this interface. If unset then the
default MAC address is used:</p>
Same as IPSEC_GRE except 64 bit key.
</dd>
- <dt><code>capwap</code></dt>
- <dd>
- An Ethernet tunnel over the UDP transport portion of CAPWAP (RFC
- 5415). This allows interoperability with certain switches that do
- not support GRE. Only the tunneling component of the protocol is
- implemented. UDP ports 58881 and 58882 are used as the source and
- destination ports respectively. CAPWAP is currently supported only
- with the Linux kernel datapath with kernel version 2.6.26 or later.
-
- CAPWAP support is deprecated and will be removed no earlier than
- February 2013.
- </dd>
-
<dt><code>vxlan</code></dt>
<dd>
<p>
An Ethernet tunnel over the experimental, UDP-based VXLAN
protocol described at
- <code>http://tools.ietf.org/html/draft-mahalingam-dutt-dcops-vxlan-02</code>.
+ <code>http://tools.ietf.org/html/draft-mahalingam-dutt-dcops-vxlan-03</code>.
VXLAN is currently supported only with the Linux kernel datapath
with kernel version 2.6.26 or later.
</p>
</p>
</dd>
+ <dt><code>lisp</code></dt>
+ <dd>
+ A layer 3 tunnel over the experimental, UDP-based Locator/ID
+ Separation Protocol (RFC 6830). LISP is currently supported only
+ with the Linux kernel datapath with kernel version 2.6.26 or later.
+ </dd>
+
<dt><code>patch</code></dt>
<dd>
A pair of virtual devices that act as a patch cable.
<p>
These options apply to interfaces with <ref column="type"/> of
<code>gre</code>, <code>ipsec_gre</code>, <code>gre64</code>,
- <code>ipsec_gre64</code>, <code>capwap</code>, and
- <code>vxlan</code>.
+ <code>ipsec_gre64</code>, <code>vxlan</code>, and <code>lisp</code>.
</p>
<p>
key="in_key"/> at all.
</li>
<li>
- A positive 24-bit (for VXLAN), 32-bit (for GRE) or 64-bit (for
- CAPWAP) number. The tunnel receives only packets with the
+ A positive 24-bit (for VXLAN and LISP), 32-bit (for GRE) or 64-bit
+ (for GRE64) number. The tunnel receives only packets with the
specified key.
</li>
<li>
key="out_key"/> at all.
</li>
<li>
- A positive 24-bit (for VXLAN), 32-bit (for GRE) or 64-bit (for
- CAPWAP) number. Packets sent through the tunnel will have the
+ A positive 24-bit (for VXLAN and LISP), 32-bit (for GRE) or 64-bit
+ (for GRE64) number. Packets sent through the tunnel will have the
specified key.
</li>
<li>
<column name="status" key="source_ip">
The source IP address used for an IPv4 tunnel end-point, such as
- <code>gre</code> or <code>capwap</code>.
+ <code>gre</code>.
</column>
<column name="status" key="tunnel_egress_iface">
- 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.
+ Egress interface for tunnels. Currently only relevant for GRE 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.
</column>
<column name="status" key="tunnel_egress_iface_carrier"
</group>
<group title="Bonding Configuration">
- <column name="other_config" key="bond-stable-id"
- type='{"type": "integer", "minInteger": 1}'>
- Used 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.
- </column>
-
<column name="other_config" key="lacp-port-id"
type='{"type": "integer", "minInteger": 1, "maxInteger": 65535}'>
The LACP port ID of this <ref table="Interface"/>. Port IDs are
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.
+ There is one exception: some hypervisors support ``migration'' from a
+ given hypervisor to itself (most often for test purposes). During
+ such a ``migration,'' two instances of a single <ref
+ column="external_ids" key="iface-id"/> might both be briefly marked
+ <code>active</code> on a single hypervisor.
</p>
</column>
git://git.onelab.eu / sliver-openvswitch.git / blobdiff