The OVN Southbound database sits at the center of the OVN
architecture. It is the one component that speaks both southbound
directly to all the hypervisors and gateways, via
- <code>ovn-controller</code>, and northbound to the Cloud Management
- System, via <code>ovn-northd</code>:
+ <code>ovn-controller</code>/<code>ovn-controller-vtep</code>, and
+ northbound to the Cloud Management System, via <code>ovn-northd</code>:
</p>
<h2>Database Structure</h2>
<dt><code>external_ids</code>: map of string-string pairs</dt>
<dd>
Key-value pairs for use by the software that manages the OVN Southbound
- database rather than by <code>ovn-controller</code>. In particular,
- <code>ovn-northd</code> can use key-value pairs in this column to relate
- entities in the southbound database to higher-level entities (such as
- entities in the OVN Northbound database). Individual key-value pairs in
- this column may be documented in some cases to aid in understanding and
- troubleshooting, but the reader should not mistake such documentation as
- comprehensive.
+ database rather than by
+ <code>ovn-controller</code>/<code>ovn-controller-vtep</code>. In
+ particular, <code>ovn-northd</code> can use key-value pairs in this
+ column to relate entities in the southbound database to higher-level
+ entities (such as entities in the OVN Northbound database). Individual
+ key-value pairs in this column may be documented in some cases to aid
+ in understanding and troubleshooting, but the reader should not mistake
+ such documentation as comprehensive.
</dd>
</dl>
<p>
Each row in this table represents a hypervisor or gateway (a chassis) in
the physical network (PN). Each chassis, via
- <code>ovn-controller</code>, adds and updates its own row, and keeps a
- copy of the remaining rows to determine how to reach other hypervisors.
+ <code>ovn-controller</code>/<code>ovn-controller-vtep</code>, adds
+ and updates its own row, and keeps a copy of the remaining rows to
+ determine how to reach other hypervisors.
</p>
<p>
A <dfn>gateway</dfn> is a chassis that forwards traffic between the
OVN-managed part of a logical network and a physical VLAN, extending a
tunnel-based logical network into a physical network. Gateways are
- typically dedicated nodes that do not host VMs.
+ typically dedicated nodes that do not host VMs and will be controlled
+ by <code>ovn-controller-vtep</code>.
</p>
<column name="vtep_logical_switches">
- Stores all vtep logical switch names connected by this gateway
- chassis.
+ Stores all VTEP logical switch names connected by this gateway
+ chassis. The <ref table="Port_Binding"/> table entry with
+ <ref column="options" table="Port_Binding"/>:<code>vtep-physical-switch</code>
+ equal <ref table="Chassis"/> <ref column="name" table="Chassis"/>, and
+ <ref column="options" table="Port_Binding"/>:<code>vtep-logical-switch</code>
+ value in <ref table="Chassis"/>
+ <ref column="vtep_logical_switches" table="Chassis"/>, will be
+ associated with this <ref table="Chassis"/>.
</column>
</group>
</table>
The <ref column="encaps" table="Chassis"/> column in the <ref
table="Chassis"/> table refers to rows in this table to identify
how OVN may transmit logical dataplane packets to this chassis.
- Each chassis, via <code>ovn-controller</code>(8), adds and updates
- its own rows and keeps a copy of the remaining rows to determine
- how to reach other chassis.
+ Each chassis, via <code>ovn-controller</code>(8) or
+ <code>ovn-controller-vtep</code>(8), adds and updates its own rows
+ and keeps a copy of the remaining rows to determine how to reach
+ other chassis.
</p>
<column name="type">
</p>
<p>
- The following actions are defined:
+ The following actions are defined:
</p>
<dl>
<dt><code>output;</code></dt>
<dd>
<p>
- In the ingress pipeline, this action executes the
- <code>egress</code> pipeline as a subroutine. If
- <code>outport</code> names a logical port, the egress pipeline
- executes once; if it is a multicast group, the egress pipeline runs
- once for each logical port in the group.
+ In the ingress pipeline, this action executes the
+ <code>egress</code> pipeline as a subroutine. If
+ <code>outport</code> names a logical port, the egress pipeline
+ executes once; if it is a multicast group, the egress pipeline runs
+ once for each logical port in the group.
</p>
<p>
<code>output</code> becomes a no-op if <code>outport</code> ==
<code>inport</code>.
</p>
- </dd>
+ </dd>
<dt><code>next;</code></dt>
+ <dt><code>next(<var>table</var>);</code></dt>
<dd>
- Executes the next logical datapath table as a subroutine.
+ Executes another logical datapath table as a subroutine. By default,
+ the table after the current one is executed. Specify
+ <var>table</var> to jump to a specific table in the same pipeline.
</dd>
<dt><code><var>field</var> = <var>constant</var>;</code></dt>
<dd>
<p>
- Sets data or metadata field <var>field</var> to constant value
- <var>constant</var>, e.g. <code>outport = "vif0";</code> to set the
- logical output port. To set only a subset of bits in a field,
- specify a subfield for <var>field</var> or a masked
- <var>constant</var>, e.g. one may use <code>vlan.pcp[2] = 1;</code>
- or <code>vlan.pcp = 4/4;</code> to set the most sigificant bit of
- the VLAN PCP.
+ Sets data or metadata field <var>field</var> to constant value
+ <var>constant</var>, e.g. <code>outport = "vif0";</code> to set the
+ logical output port. To set only a subset of bits in a field,
+ specify a subfield for <var>field</var> or a masked
+ <var>constant</var>, e.g. one may use <code>vlan.pcp[2] = 1;</code>
+ or <code>vlan.pcp = 4/4;</code> to set the most sigificant bit of
+ the VLAN PCP.
</p>
<p>
<code>ingress</code> pipeline but not in the <code>egress</code>
pipeline.
</p>
- </dd>
+ </dd>
+
+ <dt><code><var>field1</var> = <var>field2</var>;</code></dt>
+ <dd>
+ <p>
+ Sets data or metadata field <var>field1</var> to the value of data
+ or metadata field <var>field2</var>, e.g. <code>reg0 =
+ ip4.src;</code> copies <code>ip4.src</code> into <code>reg0</code>.
+ To modify only a subset of a field's bits, specify a subfield for
+ <var>field1</var> or <var>field2</var> or both, e.g. <code>vlan.pcp
+ = reg0[0..2];</code> copies the least-significant bits of
+ <code>reg0</code> into the VLAN PCP.
+ </p>
+
+ <p>
+ <var>field1</var> and <var>field2</var> must be the same type,
+ either both string or both integer fields. If they are both
+ integer fields, they must have the same width.
+ </p>
+
+ <p>
+ If <var>field1</var> or <var>field2</var> has prerequisites, they
+ are added implicitly to <ref column="match"/>. It is possible to
+ write an assignment with contradictory prerequisites, such as
+ <code>ip4.src = ip6.src[0..31];</code>, but the contradiction means
+ that a logical flow with such an assignment will never be matched.
+ </p>
+ </dd>
+
+ <dt><code><var>field1</var> <-> <var>field2</var>;</code></dt>
+ <dd>
+ <p>
+ Similar to <code><var>field1</var> = <var>field2</var>;</code>
+ except that the two values are exchanged instead of copied. Both
+ <var>field1</var> and <var>field2</var> must modifiable.
+ </p>
+ </dd>
</dl>
<p>
</p>
<dl>
- <dt><code><var>field1</var> = <var>field2</var>;</code></dt>
- <dd>
- Extends the assignment action to allow copying between fields.
- </dd>
-
<dt><code>learn</code></dt>
<dt><code>conntrack</code></dt>
</p>
<p>
- <code>ovn-controller</code> populates the <code>chassis</code> column
- for the records that identify the logical ports that are located on its
- hypervisor, which <code>ovn-controller</code> in turn finds out by
- monitoring the local hypervisor's Open_vSwitch database, which
- identifies logical ports via the conventions described in
- <code>IntegrationGuide.md</code>.
+ <code>ovn-controller</code>/<code>ovn-controller-vtep</code>
+ populates the <code>chassis</code> column for the records that
+ identify the logical ports that are located on its hypervisor/gateway,
+ which <code>ovn-controller</code>/<code>ovn-controller-vtep</code> in
+ turn finds out by monitoring the local hypervisor's Open_vSwitch
+ database, which identifies logical ports via the conventions described
+ in <code>IntegrationGuide.md</code>.
</p>
<p>
(This is not critical because resources hosted on the chassis are equally
unreachable regardless of whether their rows are present.) To handle the
case where a VM is shut down abruptly on one chassis, then brought up
- again on a different one, <code>ovn-controller</code> must overwrite the
- <code>chassis</code> column with new information.
+ again on a different one,
+ <code>ovn-controller</code>/<code>ovn-controller-vtep</code> must
+ overwrite the <code>chassis</code> column with new information.
</p>
- <column name="datapath">
- The logical datapath to which the logical port belongs.
- </column>
+ <group title="Core Features">
+ <column name="datapath">
+ The logical datapath to which the logical port belongs.
+ </column>
- <column name="logical_port">
- A logical port, taken from <ref table="Logical_Port" column="name"
- db="OVN_Northbound"/> in the OVN_Northbound database's
- <ref table="Logical_Port" db="OVN_Northbound"/> table. OVN does not
- prescribe a particular format for the logical port ID.
- </column>
+ <column name="logical_port">
+ A logical port, taken from <ref table="Logical_Port" column="name"
+ db="OVN_Northbound"/> in the OVN_Northbound database's <ref
+ table="Logical_Port" db="OVN_Northbound"/> table. OVN does not
+ prescribe a particular format for the logical port ID.
+ </column>
- <column name="type">
- <p>
- A type for this logical port. Logical ports can be used to model
- other types of connectivity into an OVN logical switch. Leaving this column
- blank maintains the default logical port behavior.
- </p>
+ <column name="chassis">
+ The physical location of the logical port. To successfully identify a
+ chassis, this column must be a <ref table="Chassis"/> record. This is
+ populated by
+ <code>ovn-controller</code>/<code>ovn-controller-vtep</code>.
+ </column>
- <p>
- There are no other logical port types implemented yet.
- </p>
- </column>
+ <column name="tunnel_key">
+ <p>
+ A number that represents the logical port in the key (e.g. STT key or
+ Geneve TLV) field carried within tunnel protocol packets.
+ </p>
- <column name="options">
- This column provides key/value settings specific to the logical port
- <ref column="type"/>.
- </column>
+ <p>
+ The tunnel ID must be unique within the scope of a logical datapath.
+ </p>
+ </column>
- <column name="tunnel_key">
- <p>
- A number that represents the logical port in the key (e.g. STT key or
- Geneve TLV) field carried within tunnel protocol packets.
- </p>
+ <column name="mac">
+ <p>
+ The Ethernet address or addresses used as a source address on the
+ logical port, each in the form
+ <var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>.
+ The string <code>unknown</code> is also allowed to indicate that the
+ logical port has an unknown set of (additional) source addresses.
+ </p>
+
+ <p>
+ A VM interface would ordinarily have a single Ethernet address. A
+ gateway port might initially only have <code>unknown</code>, and then
+ add MAC addresses to the set as it learns new source addresses.
+ </p>
+ </column>
+
+ <column name="type">
+ <p>
+ A type for this logical port. Logical ports can be used to model other
+ types of connectivity into an OVN logical switch. The following types
+ are defined:
+ </p>
+
+ <dl>
+ <dt>(empty string)</dt>
+ <dd>VM (or VIF) interface.</dd>
+ <dt><code>localnet</code></dt>
+ <dd>
+ A connection to a locally accessible network from each
+ <code>ovn-controller</code> instance. A logical switch can only
+ have a single <code>localnet</code> port attached and at most one
+ regular logical port. This is used to model direct connectivity to
+ an existing network.
+ </dd>
+
+ <dt><code>vtep</code></dt>
+ <dd>
+ A port to a logical switch on a VTEP gateway chassis. In order to
+ get this port correctly recognized by the OVN controller, the <ref
+ column="options"
+ table="Port_Binding"/>:<code>vtep-physical-switch</code> and <ref
+ column="options"
+ table="Port_Binding"/>:<code>vtep-logical-switch</code> must also
+ be defined.
+ </dd>
+ </dl>
+ </column>
+ </group>
+ <group title="Localnet Options">
<p>
- The tunnel ID must be unique within the scope of a logical datapath.
+ These options apply to logical ports with <ref column="type"/> of
+ <code>localnet</code>.
</p>
- </column>
-
- <column name="parent_port">
- For containers created inside a VM, this is taken from
- <ref table="Logical_Port" column="parent_name" db="OVN_Northbound"/>
- in the OVN_Northbound database's <ref table="Logical_Port"
- db="OVN_Northbound"/> table. It is left empty if
- <ref column="logical_port"/> belongs to a VM or a container created
- in the hypervisor.
- </column>
- <column name="tag">
- When <ref column="logical_port"/> identifies the interface of a container
- spawned inside a VM, this column identifies the VLAN tag in
- the network traffic associated with that container's network interface.
- It is left empty if <ref column="logical_port"/> belongs to a VM or a
- container created in the hypervisor.
- </column>
+ <column name="options" key="network_name">
+ Required. <code>ovn-controller</code> uses the configuration entry
+ <code>ovn-bridge-mappings</code> to determine how to connect to this
+ network. <code>ovn-bridge-mappings</code> is a list of network names
+ mapped to a local OVS bridge that provides access to that network. An
+ example of configuring <code>ovn-bridge-mappings</code> would be:
+
+ <pre>$ ovs-vsctl set open . external-ids:ovn-bridge-mappings=physnet1:br-eth0,physnet2:br-eth1</pre>
+
+ <p>
+ When a logical switch has a <code>localnet</code> port attached,
+ every chassis that may have a local vif attached to that logical
+ switch must have a bridge mapping configured to reach that
+ <code>localnet</code>. Traffic that arrives on a
+ <code>localnet</code> port is never forwarded over a tunnel to
+ another chassis.
+ </p>
+ </column>
- <column name="chassis">
- The physical location of the logical port. To successfully identify a
- chassis, this column must be a <ref table="Chassis"/> record. This is
- populated by <code>ovn-controller</code>.
- </column>
+ <column name="tag">
+ If set, indicates that the port represents a connection to a specific
+ VLAN on a locally accessible network. The VLAN ID is used to match
+ incoming traffic and is also added to outgoing traffic.
+ </column>
+ </group>
- <column name="mac">
+ <group title="VTEP Options">
<p>
- The Ethernet address or addresses used as a source address on the
- logical port, each in the form
- <var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>.
- The string <code>unknown</code> is also allowed to indicate that the
- logical port has an unknown set of (additional) source addresses.
+ These options apply to logical ports with <ref column="type"/> of
+ <code>vtep</code>.
</p>
+ <column name="options" key="vtep-physical-switch">
+ Required. The name of the VTEP gateway.
+ </column>
+
+ <column name="options" key="vtep-logical-switch">
+ Required. A logical switch name connected by the VTEP gateway. Must
+ be set when <ref column="type"/> is <code>vtep</code>.
+ </column>
+ </group>
+
+ <group title="Nested Containers">
<p>
- A VM interface would ordinarily have a single Ethernet address. A
- gateway port might initially only have <code>unknown</code>, and then
- add MAC addresses to the set as it learns new source addresses.
+ These columns support containers nested within a VM. Specifically,
+ they are used when <ref column="type"/> is empty and <ref
+ column="logical_port"/> identifies the interface of a container spawned
+ inside a VM. They are empty for containers or VMs that run directly on
+ a hypervisor.
</p>
- </column>
+
+ <column name="parent_port">
+ This is taken from
+ <ref table="Logical_Port" column="parent_name" db="OVN_Northbound"/>
+ in the OVN_Northbound database's <ref table="Logical_Port"
+ db="OVN_Northbound"/> table.
+ </column>
+
+ <column name="tag">
+ <p>
+ Identifies the VLAN tag in the network traffic associated with that
+ container's network interface.
+ </p>
+
+ <p>
+ This column is used for a different purpose when <ref column="type"/>
+ is <code>localnet</code> (see <code>Localnet Options</code>, above).
+ </p>
+ </column>
+ </group>
</table>
</database>