(not a DNS name).
</p>
<p>
- SSL key and certificate configuration happens outside the
- database.
+ SSL key and certificate configuration happens outside the
+ database.
</p>
</dd>
<group title="Identification">
<column name="name">
- Symbolic name for the switch, such as its hostname.
+ Symbolic name for the switch, such as its hostname.
</column>
<column name="description">
- An extended description for the switch, such as its switch login
- banner.
+ An extended description for the switch, such as its switch login
+ banner.
</column>
</group>
+ <group title="Error Notification">
+ <p>
+ An entry in this column indicates to the NVC that this switch
+ has encountered a fault. The switch must clear this column
+ when the fault has been cleared.
+ </p>
+
+ <column name="switch_fault_status" key="mac_table_exhaustion">
+ Indicates that the switch has been unable to process MAC
+ entries requested by the NVC due to lack of table resources.
+ </column>
+
+ <column name="switch_fault_status" key="tunnel_exhaustion">
+ Indicates that the switch has been unable to create tunnels
+ requested by the NVC due to lack of resources.
+ </column>
+
+ <column name="switch_fault_status" key="unspecified_fault">
+ Indicates that an error has occurred in the switch but that no
+ more specific information is available.
+ </column>
+
+ </group>
</table>
<table name="Physical_Port" title="A port within a physical switch.">
<group title="Identification">
<column name="name">
- Symbolic name for the port. The name ought to be unique within a given
- <ref table="Physical_Switch"/>, but the database is not capable of
- enforcing this.
+ Symbolic name for the port. The name ought to be unique within a given
+ <ref table="Physical_Switch"/>, but the database is not capable of
+ enforcing this.
</column>
<column name="description">
- An extended description for the port.
+ An extended description for the port.
+ </column>
+ </group>
+ <group title="Error Notification">
+ <p>
+ An entry in this column indicates to the NVC that the physical port has
+ encountered a fault. The switch must clear this column when the errror
+ has been cleared.
+ </p>
+ <column name="port_fault_status" key="invalid_vlan_map">
+ <p>
+ Indicates that a VLAN-to-logical-switch mapping requested by
+ the controller could not be instantiated by the switch
+ because of a conflict with local configuration.
+ </p>
+ </column>
+ <column name="port_fault_status" key="unspecified_fault">
+ <p>
+ Indicates that an error has occurred on the port but that no
+ more specific information is available.
+ </p>
</column>
</group>
+
</table>
<table name="Logical_Binding_Stats" title="Statistics for a VLAN on a physical port bound to a logical network.">
<group title="Identification">
<column name="name">
- Symbolic name for the logical switch.
+ Symbolic name for the logical switch.
</column>
<column name="description">
- An extended description for the logical switch, such as its switch
- login banner.
+ An extended description for the logical switch, such as its switch
+ login banner.
</column>
</group>
</table>
</p>
<column name="MAC">
- A MAC address that has been learned by the NSC.
+ A MAC address that has been learned by the NVC.
</column>
<column name="logical_switch">
<column name="MAC">
<p>
- A MAC address that has been learned by the VTEP.
+ A MAC address that has been learned by the VTEP.
</p>
<p>
- The keyword <code>unknown-dst</code> is used as a special
- ``Ethernet address'' that indicates the locations to which
- packets in a logical switch whose destination addresses do not
- otherwise appear in <ref table="Ucast_Macs_Local"/> (for
- unicast addresses) or <ref table="Mcast_Macs_Local"/> (for
- multicast addresses) should be sent.
+ The keyword <code>unknown-dst</code> is used as a special
+ ``Ethernet address'' that indicates the locations to which
+ packets in a logical switch whose destination addresses do not
+ otherwise appear in <ref table="Ucast_Macs_Local"/> (for
+ unicast addresses) or <ref table="Mcast_Macs_Local"/> (for
+ multicast addresses) should be sent.
</p>
</column>
<column name="MAC">
<p>
- A MAC address that has been learned by the NSC.
+ A MAC address that has been learned by the NVC.
</p>
<p>
- The keyword <code>unknown-dst</code> is used as a special
- ``Ethernet address'' that indicates the locations to which
- packets in a logical switch whose destination addresses do not
- otherwise appear in <ref table="Ucast_Macs_Remote"/> (for
- unicast addresses) or <ref table="Mcast_Macs_Remote"/> (for
- multicast addresses) should be sent.
+ The keyword <code>unknown-dst</code> is used as a special
+ ``Ethernet address'' that indicates the locations to which
+ packets in a logical switch whose destination addresses do not
+ otherwise appear in <ref table="Ucast_Macs_Remote"/> (for
+ unicast addresses) or <ref table="Mcast_Macs_Remote"/> (for
+ multicast addresses) should be sent.
</p>
</column>
<group title="Identification">
<column name="name">
- Symbolic name for the logical router.
+ Symbolic name for the logical router.
</column>
<column name="description">
- An extended description for the logical router.
+ An extended description for the logical router.
</column>
</group>
</table>
+ <table name="Arp_Sources_Local" title="ARP source addresses for logical routers">
+ <p>
+ MAC address to be used when a VTEP issues ARP requests on behalf
+ of a logical router.
+ </p>
+
+ <p>
+ A distributed logical router is implemented by a set of VTEPs
+ (both hardware VTEPs and vswitches). In order for a given VTEP
+ to populate the local ARP cache for a logical router, it issues
+ ARP requests with a source MAC address that is unique to the VTEP. A
+ single per-VTEP MAC can be re-used across all logical
+ networks. This table contains the MACs that are used by the
+ VTEPs of a given HSC. The table provides the mapping from MAC to
+ physical locator for each VTEP so that replies to the ARP
+ requests can be sent back to the correct VTEP using the
+ appropriate physical locator.
+ </p>
+
+ <column name="src_mac">
+ The source MAC to be used by a given VTEP.
+ </column>
+
+ <column name="locator">
+ The <ref table="Physical_Locator"/> to use for replies to ARP
+ requests from this MAC address.
+ </column>
+ </table>
+
+ <table name="Arp_Sources_Remote" title="ARP source addresses for logical routers">
+ <p>
+ MAC address to be used when a remote VTEP issues ARP requests on behalf
+ of a logical router.
+ </p>
+
+ <p>
+ This table is the remote counterpart of <ref
+ table="Arp_sources_local"/>. The NVC writes this table to notify
+ the HSC of the MACs that will be used by remote VTEPs when they
+ issue ARP requests on behalf of a distributed logical router.
+ </p>
+
+ <column name="src_mac">
+ The source MAC to be used by a given VTEP.
+ </column>
+
+ <column name="locator">
+ The <ref table="Physical_Locator"/> to use for replies to ARP
+ requests from this MAC address.
+ </column>
+ </table>
+
<table name="Physical_Locator_Set">
<p>
A set of one or more <ref table="Physical_Locator"/>s.
encapsulations to be introduced later.
</p>
</column>
+
<group title="Bidirectional Forwarding Detection (BFD)">
<p>
- BFD, defined in RFC 5880, allows point to point detection of
- connectivity failures by occasional transmission of BFD control
- messages.
+ BFD, defined in RFC 5880, allows point to point detection of
+ connectivity failures by occasional transmission of BFD control
+ messages. VTEPs are expected to implement BFD.
</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's willing to transmit them. An endpoint
- which fails to receive BFD control messages for a period of three
- times the expected reception rate, will signal a connectivity
- fault. In the case of a unidirectional connectivity issue, the
- system not receiving BFD control messages will signal the problem
- to its peer in the messages is transmists.
+ 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's willing to transmit them. An endpoint
+ which fails to receive BFD control messages for a period of three
+ times the expected reception rate will signal a connectivity
+ fault. In the case of a unidirectional connectivity issue, the
+ system not receiving BFD control messages will signal the problem
+ to its peer in the messages it transmits.
</p>
- <column name="bfd" key="min_rx">
- The minimum rate, in milliseconds, at which this BFD session is
- willing to receive BFD control messages. The actual rate may slower
- if the remote endpoint isn't willing to transmit as quickly as
- specified. Defaults to <code>1000</code>.
- </column>
-
- <column name="bfd" key="min_tx">
- The minimum rate, in milliseconds, at which this BFD session is
- willing to transmit BFD control messages. The actual rate may be
- slower if the remote endpoint isn't willing to receive as quickly as
- specified. Defaults to <code>100</code>.
- </column>
-
- <column name="bfd" key="cpath_down">
- Concatenated path down may be used when the local system should not
- have traffic forwarded to it for some reason other than a connectivty
- failure on the interface being monitored. The local BFD session will
- notify the remote session of the connectivity problem, at which time
- the remote session may choose not to forward traffic. Defaults to
- <code>false</code>.
- </column>
-
- <column name="bfd_status" key="state">
- State of the BFD session. One of <code>ADMIN_DOWN</code>,
- <code>DOWN</code>, <code>INIT</code>, or <code>UP</code>.
- </column>
-
- <column name="bfd_status" key="forwarding">
- True if the BFD session believes this <ref table="Physical_Locator"/> may be
- used to forward traffic. Typically this means the local session is
- up, and the remote system isn't signalling a problem such as
- concatenated path down.
- </column>
-
- <column name="bfd_status" key="diagnostic">
- A short message indicating what the BFD session thinks is wrong in
- case of a problem.
- </column>
-
- <column name="bfd_status" key="remote state">
- State of the remote endpoint's BFD session.
- </column>
-
- <column name="bfd_status" key="remote diagnostic">
- A short message indicating what the remote endpoint's BFD session
- thinks is wrong in case of a problem.
- </column>
+ <p>
+ A hardware VTEP is expected to use BFD to determine reachability of
+ devices at the end of the tunnels with which it exchanges data. This
+ can enable the VTEP to choose a functioning service node among a set of
+ service nodes providing high availability. It also enables the NVC to
+ report the health status of tunnels.
+ </p>
+
+ <p>
+ In most cases the BFD peer of a hardware VTEP will be an Open vSwitch
+ instance. The Open vSwitch implementation of BFD aims to comply
+ faithfully with the requirements put forth in RFC 5880. 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>
+
+ <column name="bfd" key="enable" type='{"type": "boolean"}'>
+ True to enable BFD on this <ref table="Physical_Locator"/>.
+ </column>
+
+ <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 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"}'>
+ True to consider the interface capable of packet I/O as long as it
+ continues to receive any packets (not just BFD packets). This
+ prevents link congestion that causes consecutive BFD control packets
+ to be lost from marking the interface down.
+ </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"}'>
+ 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_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 and
+ expected as destination for received BFD packets. The default is
+ <code>00:23:20:00:00:01</code>.
+ </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.0</code>.
+ </column>
+
+ <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.1</code>.
+ </column>
+ </group>
+
+ <group title="BFD Status">
+ <p>
+ The VTEP 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="Physical_Locator"/> 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 a short message that reports what the
+ local BFD session thinks is wrong.
+ </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 a short message that reports what the
+ remote endpoint's BFD session thinks is wrong.
+ </column>
+ </group>
</group>
</table>
git://git.onelab.eu / sliver-openvswitch.git / blobdiff