<?xml version="1.0" encoding="utf-8"?>
-<database title="Hardware VTEP Database">
+<database name="vtep" title="Hardware VTEP Database">
<p>
This schema specifies relations that a VTEP can use to integrate
physical ports into logical switches maintained by a network
virtualization controller such as NSX.
</p>
-
+
<p>Glossary:</p>
<dl>
<dd>
Virtual Routing and Forwarding instance.
</dd>
- </dl>
+ </dl>
<table name="Global" title="Top-level configuration.">
Top-level configuration for a hardware VTEP. There must be
exactly one record in the <ref table="Global"/> table.
<column name="switches">
- The physical switches managed by the VTEP.
+ <p>
+ The physical switch or switches managed by the VTEP.
+ </p>
+
+ <p>
+ When a physical switch integrates support for this VTEP schema, which
+ is expected to be the most common case, this column should point to one
+ <ref table="Physical_Switch"/> record that represents the switch
+ itself. In another possible implementation, a server or a VM presents
+ a VTEP schema front-end interface to one or more physical switches,
+ presumably communicating with those physical switches over a
+ proprietary protocol. In that case, this column would point to one
+ <ref table="Physical_Switch"/> for each physical switch, and the set
+ might change over time as the front-end server comes to represent a
+ differing set of switches.
+ </p>
</column>
<group title="Database Configuration">
<dt><code>ssl:<var>ip</var></code>[<code>:<var>port</var></code>]</dt>
<dd>
<p>
- The specified SSL <var>port</var> (default: 6632) on the host at
+ The specified SSL <var>port</var> (default: 6640) on the host at
the given <var>ip</var>, which must be expressed as an IP address
(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>
<dt><code>tcp:<var>ip</var></code>[<code>:<var>port</var></code>]</dt>
<dd>
- The specified TCP <var>port</var> (default: 6632) on the host at
+ The specified TCP <var>port</var> (default: 6640) on the host at
the given <var>ip</var>, which must be expressed as an IP address
(not a DNS name).
</dd>
<dd>
<p>
Listens for SSL connections on the specified TCP <var>port</var>
- (default: 6632). If <var>ip</var>, which must be expressed as an
+ (default: 6640). If <var>ip</var>, which must be expressed as an
IP address (not a DNS name), is specified, then connections are
restricted to the specified local IP address.
</p>
<dt><code>ptcp:</code>[<var>port</var>][<code>:<var>ip</var></code>]</dt>
<dd>
Listens for connections on the specified TCP <var>port</var>
- (default: 6632). If <var>ip</var>, which must be expressed as an
+ (default: 6640). If <var>ip</var>, which must be expressed as an
IP address (not a DNS name), is specified, then connections are
restricted to the specified local IP address.
</dd>
</p>
<column name="other_config" key="dscp"
- type='{"type": "integer"}'>
+ type='{"type": "integer"}'>
The Differentiated Service Code Point (DSCP) is specified using 6 bits
in the Type of Service (TOS) field in the IP header. DSCP provides a
mechanism to classify the network traffic and provide Quality of
The physical ports within the switch.
</column>
+ <column name="tunnels">
+ Tunnels created by this switch as instructed by the NVC.
+ </column>
+
<group title="Network Status">
<column name="management_ips">
IPv4 or IPv6 addresses at which the switch may be contacted
<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.
+ 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">
requested by the NVC due to lack of resources.
</column>
+ <column name="switch_fault_status" key="lr_switch_bindings_fault">
+ Indicates that the switch has been unable to create the logical router
+ interfaces requested by the NVC due to conflicting configurations or a
+ lack of hardware resources.
+ </column>
+
+ <column name="switch_fault_status" key="lr_static_routes_fault">
+ Indicates that the switch has been unable to create the static routes
+ requested by the NVC due to conflicting configurations or a lack of
+ hardware resources.
+ </column>
+
+ <column name="switch_fault_status" key="lr_creation_fault">
+ Indicates that the switch has been unable to create the logical router
+ requested by the NVC due to conflicting configurations or a lack of
+ hardware resources.
+ </column>
+
+ <column name="switch_fault_status" key="lr_support_fault">
+ Indicates that the switch does not support logical routing.
+ </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.
</group>
</table>
+ <table name="Tunnel" title="A tunnel created by a physical switch.">
+ A tunnel created by a <ref table="Physical_Switch"/>.
+
+ <column name="local">
+ Tunnel end-point local to the physical switch.
+ </column>
+
+ <column name="remote">
+ Tunnel end-point remote to the physical switch.
+ </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. 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 it transmits.
+ </p>
+
+ <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 many 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 Local Configuration">
+ <p>
+ The HSC writes the key-value pairs in the
+ <ref column="bfd_config_local"/> column to specify the local
+ configurations to be used for BFD sessions on this tunnel.
+ </p>
+
+ <column name="bfd_config_local" 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 expected as destination for received BFD packets.
+ The default is <code>00:23:20:00:00:01</code>.
+ </column>
+
+ <column name="bfd_config_local" key="bfd_dst_ip">
+ Set to an IPv4 address to set the IP address that is expected as destination
+ for received BFD packets. The default is <code>169.254.1.0</code>.
+ </column>
+
+ </group>
+
+ <group title="BFD Remote Configuration">
+ <p>
+ The <ref column="bfd_config_remote"/> column is the remote
+ counterpart of the <ref column="bfd_config_local"/> column.
+ The NVC writes the key-value pairs in this column.
+ </p>
+
+ <column name="bfd_config_remote" 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 destination MAC to be used for transmitted BFD packets.
+ The default is <code>00:23:20:00:00:01</code>.
+ </column>
+
+ <column name="bfd_config_remote" 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 Parameters">
+ <p>
+ The NVC sets up key-value pairs in the <ref column="bfd_params"/>
+ column to enable and configure BFD.
+ </p>
+
+ <column name="bfd_params" key="enable" type='{"type": "boolean"}'>
+ True to enable BFD on this <ref table="Tunnel"/>. If not
+ specified, BFD will not be enabled by default.
+ </column>
+
+ <column name="bfd_params" 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_params" 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_params" key="decay_min_rx" type='{"type": "integer"}'>
+ An alternate receive interval, in milliseconds, that must be greater
+ than or equal to <ref column="bfd_params" key="min_rx"/>. The
+ implementation should switch from <ref column="bfd_params" key="min_rx"/>
+ to <ref column="bfd_params" key="decay_min_rx"/> when there is no obvious
+ incoming data traffic at the tunnel, to reduce the CPU and bandwidth
+ cost of monitoring an idle tunnel. This feature may be disabled by
+ setting a value of 0. This feature is reset whenever
+ <ref column="bfd_params" key="decay_min_rx"/> or
+ <ref column="bfd_params" key="min_rx"/> changes.
+ </column>
+
+ <column name="bfd_params" key="forwarding_if_rx" type='{"type": "boolean"}'>
+ When <code>true</code>, traffic received on the <ref table="Tunnel"/>
+ is used to indicate the capability of packet I/O.
+ BFD control packets are still transmitted and received. At least one
+ BFD control packet must be received every
+ 100 * <ref column="bfd_params" key="min_rx"/> amount of time.
+ Otherwise, even if traffic is received, the
+ <ref column="bfd_params" key="forwarding"/> will be <code>false</code>.
+ </column>
+
+ <column name="bfd_params" 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 connectivity
+ 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_params" 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>
+
+ </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 tunnel. When BFD is
+ not enabled, with <ref column="bfd_params" key="enable"/>, the
+ HSC clears all key-value pairs from <ref column="bfd_status"/>.
+ </p>
+
+ <column name="bfd_status" key="enabled" type='{"type": "boolean"}'>
+ Set to true if the BFD session has been successfully enabled.
+ Set to false if the VTEP cannot support BFD or has insufficient
+ resources to enable BFD on this tunnel. The NVC will disable
+ the BFD monitoring on the other side of the tunnel once this
+ value is set to false.
+ </column>
+
+ <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="Tunnel"/>
+ 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">
+ A diagnostic code specifying the local system's reason for the
+ last change in session state. The error messages are defined in
+ section 4.1 of [RFC 5880].
+ </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">
+ A diagnostic code specifying the remote system's reason for the
+ last change in session state. The error messages are defined in
+ section 4.1 of [RFC 5880].
+ </column>
+
+ <column name="bfd_status" key="info">
+ A short message providing further information about the BFD status
+ (possibly including reasons why BFD could not be enabled).
+ </column>
+ </group>
+ </group>
+ </table>
+
<table name="Physical_Port" title="A port within a physical switch.">
A port within a <ref table="Physical_Switch"/>.
Identifies how VLANs on the physical port are bound to logical switches.
If, for example, the map contains a (VLAN, logical switch) pair, a packet
that arrives on the port in the VLAN is considered to belong to the
- paired logical switch.
+ paired logical switch. A value of zero in the VLAN field means
+ that untagged traffic on the physical port is mapped to the
+ logical switch.
+ </column>
+
+ <column name="acl_bindings">
+ <p>
+ Attach Access Control Lists (ACLs) to the physical port. The
+ column consists of a map of VLAN tags to <ref table="ACL"/>s. If the value of
+ the VLAN tag in the map is 0, this means that the ACL is
+ associated with the entire physical port. Non-zero values mean
+ that the ACL is to be applied only on packets carrying that VLAN
+ tag value. Switches will not necessarily support matching on the
+ VLAN tag for all ACLs, and unsupported ACL bindings will cause
+ errors to be reported. The binding of an ACL to a specific
+ VLAN and the binding of an ACL to the entire physical port
+ should not be combined on a single physical port. That is, a
+ mix of zero and non-zero keys in the map is not recommended.
+ </p>
</column>
<column name="vlan_stats">
column with a mapping for every VLAN that is bound in <ref
column="vlan_bindings"/>. An implementation that does not support such
statistics or only partially supports them would not populate this column
- or partially populate it, respectively.
+ or partially populate it, respectively. A value of zero in the
+ VLAN field refers to untagged traffic on the physical port.
</column>
<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.
+ 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 error
+ 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>
+ <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="invalid_ACL_binding">
+ <p>
+ Indicates that an error has occurred in associating an ACL
+ with a port.
+ </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>
+ Indicates that an error has occurred on the port but that no
+ more specific information is available.
+ </p>
</column>
</group>
</p>
<p>
- For <code>vxlan_over_ipv4</code> encapsulation, this column
- is the VXLAN VNI that identifies a logical switch. It must
- be in the range 0 to 16,777,215.
+ For <code>vxlan_over_ipv4</code> encapsulation, when the tunnel key
+ per <ref table="Logical_Switch"/> model is in use, this column is the
+ VXLAN VNI that identifies a logical switch. It must be in the range
+ 0 to 16,777,215.
</p>
</column>
</group>
<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>
</table>
- <table name="Ucast_Macs_Remote" title="Unicast MACs (remote)">
+
<table name="Ucast_Macs_Remote" title="Unicast MACs (remote)">
<p>
Mapping of unicast MAC addresses to tunnels (physical
locators). This table is written by the NVC, so it contains the
<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>
addresses of the appropriate VTEP(s).
</column>
+ <column name="ipaddr">
+ The IP address to which this MAC corresponds. Optional field for
+ the purpose of ARP supression.
+ </column>
</table>
<table name="Mcast_Macs_Remote" title="Multicast MACs (remote)">
in which case the physical locators will be IP addresses of
service nodes. If the VTEP supports replication onto multiple
tunnels, then this may be used to replicate directly onto
- VTEP-hyperisor tunnels.
+ VTEP-hypervisor tunnels.
</p>
<column name="MAC">
<p>
- A MAC address that has been learned by the NVC.
+ 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>
<table name="Logical_Router" title="A logical L3 router.">
<p>
A logical router, or VRF. A logical router may be connected to one or more
- logical switches. Subnet addresses and interface addresses may be configured on the
+ logical switches. Subnet addresses and interface addresses may be configured on the
interfaces.
</p>
-
+
<column name="switch_binding">
Maps from an IPv4 or IPv6 address prefix in CIDR notation to a
logical switch. Multiple prefixes may map to the same switch. By
One or more static routes, mapping IP prefixes to next hop IP addresses.
</column>
+ <column name="acl_binding">
+ Maps ACLs to logical router interfaces. The router interfaces
+ are indicated using IP address notation, and must be the same
+ interfaces created in the <ref column="switch_binding"/>
+ column. For example, an ACL could be associated with the logical
+ router interface with an address of 192.68.1.1 as defined in the
+ example above.
+ </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>
+
+ <group title="Error Notification">
+ <p>
+ An entry in this column indicates to the NVC that the HSC has
+ encountered a fault in configuring state related to the
+ logical router.
+ </p>
+ <column name="LR_fault_status" key="invalid_ACL_binding">
+ <p>
+ Indicates that an error has occurred in associating an ACL
+ with a logical router port.
+ </p>
+ </column>
+ <column name="LR_fault_status" key="unspecified_fault">
+ <p>
+ Indicates that an error has occurred in configuring the
+ logical router but that no
+ more specific information is available.
+ </p>
+ </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">
table="Physical_Locator"/> records.''
</p>
- <column name="locators"/>
+ <column name="locators"/>
</table>
<table name="Physical_Locator">
</p>
<p>
- For the <code>vxlan_over_ipv4</code> encapsulation, the only
- encapsulation defined so far, all endpoints associated with a given <ref
- table="Logical_Switch"/> must use a common tunnel key, which is carried
- in the <ref table="Logical_Switch" column="tunnel_key"/> column of <ref
- table="Logical_Switch"/>.
- </p>
-
- <p>
- For some encapsulations yet to be defined, we expect <ref
- table="Physical_Locator"/> to identify both an endpoint and a tunnel key.
- When the first such encapsulation is defined, we expect to add a
- ``tunnel_key'' column to <ref table="Physical_Locator"/> to allow the
- tunnel key to be defined.
- </p>
-
- <p>
- See the ``Per Logical-Switch Tunnel Key'' section in the <ref
- table="Logical_Switch"/> table for further discussion of the model.
+ The <code>vxlan_over_ipv4</code> encapsulation, the only encapsulation
+ defined so far, can use either tunnel key model described in the ``Per
+ Logical-Switch Tunnel Key'' section in the <ref table="Logical_Switch"/>
+ table. When the tunnel key per <ref table="Logical_Switch"/> model is in
+ use, the <ref table="Logical_Switch" column="tunnel_key"/> column in the
+ <ref table="Logical_Switch"/> table is filled with a VNI and the <ref
+ column="tunnel_key"/> column in this table is empty; in the
+ key-per-tunnel model, the opposite is true. The former model is older,
+ and thus likely to be more widely supported. See the ``Per
+ Logical-Switch Tunnel Key'' section in the <ref table="Logical_Switch"/>
+ table for further discussion of the model.
</p>
<column name="encapsulation_type">
</p>
</column>
- <group title="Bidirectional Forwarding Detection (BFD)">
+ <column name="tunnel_key">
<p>
- 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.
+ This column is used only in the tunnel key per <ref
+ table="Logical_Switch"/>+<ref table="Physical_Locator"/> model (see
+ above).
</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 it transmits.
- </p>
-
+
<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.
+ For <code>vxlan_over_ipv4</code> encapsulation, when the <ref
+ table="Logical_Switch"/>+<ref table="Physical_Locator"/> model is in
+ use, this column is the VXLAN VNI. It must be in the range 0 to
+ 16,777,215.
</p>
+ </column>
+ </table>
+ <table name="ACL_entry">
+ <p>
+ Describes the individual entries that comprise an Access Control List.
+ </p>
+ <p>
+ Each entry in the table is a single rule to match on certain
+ header fields. While there are a large number of fields that can
+ be matched on, most hardware cannot match on arbitrary
+ combinations of fields. It is common to match on either L2
+ fields (described below in the L2 group of columns) or L3/L4 fields
+ (the L3/L4 group of columns) but not both. The hardware switch
+ controller may log an error if an ACL entry requires it to match
+ on an incompatible mixture of fields.
+ </p>
+ <column name="sequence">
<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.
+ The sequence number for the ACL entry for the purpose of
+ ordering entries in an ACL. Lower numbered entries are matched
+ before higher numbered entries.
</p>
-
- <group title="BFD Configuration">
- <p>
- A controller sets up key-value pairs in the <ref column="bfd"/>
- column to enable and configure BFD.
+ </column>
+ <group title="L2 fields">
+ <column name="source_mac">
+ <p>
+ Source MAC address, in the form
+ <var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>
</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
+ </column>
+ <column name="dest_mac">
+ <p>
+ Destination MAC 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>
- </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>
+ </p>
+ </column>
+ <column name="ethertype">
+ <p>
+ Ethertype in hexadecimal, in the form
+ <var>0xAAAA</var>
+ </p>
+ </column>
+ </group>
+ <group title="L3/L4 fields">
+ <column name="source_ip">
+ <p>
+ Source IP address, in the form
+ <var>xx.xx.xx.xx</var> for IPv4 or appropriate
+ colon-separated hexadecimal notation for IPv6.
+ </p>
+ </column>
+ <column name="source_mask">
+ <p>
+ Mask that determines which bits of source_ip to match on, in the form
+ <var>xx.xx.xx.xx</var> for IPv4 or appropriate
+ colon-separated hexadecimal notation for IPv6.
+ </p>
+ </column>
+ <column name="dest_ip">
+ <p>
+ Destination IP address, in the form
+ <var>xx.xx.xx.xx</var> for IPv4 or appropriate
+ colon-separated hexadecimal notation for IPv6.
+ </p>
+ </column>
+ <column name="dest_mask">
+ <p>
+ Mask that determines which bits of dest_ip to match on, in the form
+ <var>xx.xx.xx.xx</var> for IPv4 or appropriate
+ colon-separated hexadecimal notation for IPv6.
+ </p>
+ </column>
+ <column name="protocol">
+ <p>
+ Protocol number in the IPv4 header, or value of the "next
+ header" field in the IPv6 header.
+ </p>
+ </column>
+ <column name="source_port_min">
+ <p>
+ Lower end of the range of source port values. The value
+ specified is included in the range.
+ </p>
+ </column>
+ <column name="source_port_max">
+ <p>
+ Upper end of the range of source port values. The value
+ specified is included in the range.
+ </p>
+ </column>
+ <column name="dest_port_min">
+ <p>
+ Lower end of the range of destination port values. The value
+ specified is included in the range.
+ </p>
+ </column>
+ <column name="dest_port_max">
+ <p>
+ Upper end of the range of destination port values. The value
+ specified is included in the range.
+ </p>
+ </column>
+ <column name="tcp_flags">
+ <p>
+ Integer representing the value of TCP flags to match. For
+ example, the SYN flag is the second least significant bit in
+ the TCP flags. Hence a value of 2 would indicate that the "SYN"
+ flag should be set (assuming an appropriate mask).
+ </p>
+ </column>
+ <column name="tcp_flags_mask">
+ <p>
+ Integer representing the mask to apply when matching TCP
+ flags. For example, a value of 2 would imply that the "SYN"
+ flag should be matched and all other flags ignored.
+ </p>
+ </column>
+ <column name="icmp_type">
+ <p>
+ ICMP type to be matched.
+ </p>
+ </column>
+ <column name="icmp_code">
+ <p>
+ ICMP code to be matched.
+ </p>
+ </column>
+ </group>
+ <column name="direction">
+ <p>
+ Direction of traffic to match on the specified port, either
+ "ingress" (toward the logical switch or router) or "egress"
+ (leaving the logical switch or router).
+ </p>
+ </column>
+ <column name="action">
+ <p>
+ Action to take for this rule, either "permit" or "deny".
+ </p>
+ </column>
+ <group title="Error Notification">
+ <p>
+ An entry in this column indicates to the NVC that the ACL
+ could not be configured as requested. The switch must clear this column when the error
+ has been cleared.
+ </p>
+ <column name="acle_fault_status" key="invalid_acl_entry">
+ <p>
+ Indicates that an ACL entry requested by
+ the controller could not be instantiated by the switch,
+ e.g. because it requires an unsupported combination of
+ fields to be matched.
+ </p>
+ </column>
+ <column name="acle_fault_status" key="unspecified_fault">
+ <p>
+ Indicates that an error has occurred in configuring the ACL
+ entry but no
+ more specific information is available.
+ </p>
+ </column>
+ </group>
+ </table>
+ <table name="ACL">
+ <p>
+ Access Control List table. Each ACL is constructed as a set of
+ entries from the <ref table="ACL_entry"/> table. Packets that
+ are not matched by any entry in the ACL are allowed by default.
+ </p>
+ <column name="acl_entries">
+ <p>
+ A set of references to entries in the <ref table="ACL_entry"/> table.
+ </p>
+ </column>
+ <column name="acl_name">
+ <p>
+ A human readable name for the ACL, which may (for example) be displayed on
+ the switch CLI.
+ </p>
+ </column>
+ <group title="Error Notification">
+ <p>
+ An entry in this column indicates to the NVC that the ACL
+ could not be configured as requested. The switch must clear this column when the error
+ has been cleared.
+ </p>
+ <column name="acl_fault_status" key="invalid_acl">
+ <p>
+ Indicates that an ACL requested by
+ the controller could not be instantiated by the switch,
+ e.g., because it requires an unsupported combination of
+ fields to be matched.
+ </p>
+ </column>
+ <column name="acl_fault_status" key="resource_shortage">
+ <p>
+ Indicates that an ACL requested by
+ the controller could not be instantiated by the switch due
+ to a shortage of resources (e.g. TCAM space).
+ </p>
+ </column>
+ <column name="acl_fault_status" key="unspecified_fault">
+ <p>
+ Indicates that an error has occurred in configuring the ACL
+ but no
+ more specific information is available.
+ </p>
+ </column>
</group>
</table>
-
</database>
projects / cascardo / ovs.git / blobdiff