- 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.
- 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.
- 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.
+ 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.
- 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.
+ 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>
- 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>
+ <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>