This database is the interface between OVN and the cloud management system (CMS), such as OpenStack, running above it. The CMS produces almost all of the contents of the database. The ovn-northd program monitors the database contents, transforms it, and stores it into the database.

We generally speak of ``the'' CMS, but one can imagine scenarios in which multiple CMSes manage different parts of an OVN deployment.

External IDs

Each of the tables in this database contains a special column, named external_ids. This column has the same form and purpose each place it appears.

external_ids: map of string-string pairs
Key-value pairs for use by the CMS. The CMS might use certain pairs, for example, to identify entities in its own configuration that correspond to those in this database.

Each row represents one L2 logical switch. A given switch's ports are the rows whose column points to its row.

A name for the logical switch. This name has no special meaning or purpose other than to provide convenience for human interaction with the ovn-nb database. There is no requirement for the name to be unique. The logical switch's UUID should be used as the unique identifier.

The router port to which this logical switch is connected, or empty if this logical switch is not connected to any router. A switch may be connected to at most one logical router, but this is not a significant restriction because logical routers may be connected into arbitrary topologies.

See External IDs at the beginning of this document.

A port within an L2 logical switch.

The logical switch to which the logical port is connected.

The logical port name.

For entities (VMs or containers) that are spawned in the hypervisor, the name used here must match those used in the in the database's table, because hypervisors use as a lookup key to identify the network interface of that entity.

For containers that are spawned inside a VM, the name can be any unique identifier. In such a case, must be populated.

When identifies the interface of a container spawned inside a tenant VM, this column represents the VM interface through which the container interface sends its network traffic. The name used here must match those used in the in the table, because hypervisors in this case use as a lookup key to identify the network interface of the tenant VM. When identifies the interface of a container spawned inside a tenant VM, this column identifies the VLAN tag in the network traffic associated with that container's network interface. When there are multiple container interfaces inside a VM, all of them send their network traffic through a single VM network interface and this value helps OVN identify the correct container interface. This column is populated by ovn-northd, rather than by the CMS plugin as is most of this database. When a logical port is bound to a physical location in the OVN Southbound database table, ovn-northd sets this column to true; otherwise, or if the port becomes unbound later, it sets it to false. This allows the CMS to wait for a VM's (or container's) networking to become active before it allows the VM (or container) to start. The logical port's own Ethernet address or addresses, each in the form xx:xx:xx:xx:xx:xx. Like a physical Ethernet NIC, a logical port ordinarily has a single fixed Ethernet address. The string unknown is also allowed to indicate that the logical port has an unknown set of (additional) source addresses.

A set of L2 (Ethernet) or L3 (IPv4 or IPv6) addresses or L2+L3 pairs from which the logical port is allowed to send packets and to which it is allowed to receive packets. If this column is empty, all addresses are permitted.

Exact syntax is TBD. One could simply use comma- or space-separated L2 and L3 addresses in each set member, or replace this by a subset of the general-purpose expression language used for the column in the OVN Southbound database's table.

See External IDs at the beginning of this document.

Each row in this table represents one ACL rule for the logical switch in its column. The column for the highest- matching row in this table determines a packet's treatment. If no row matches, packets are allowed by default. (Default-deny treatment is possible: add a rule with 0, true as , and deny as .)

The switch to which the ACL rule applies. The expression in the column may match against logical ports within this switch. The ACL rule's priority. Rules with numerically higher priority take precedence over those with lower. If two ACL rules with the same priority both match, then the one actually applied to a packet is undefined. The packets that the ACL should match, in the same expression language used for the column in the OVN Southbound database's table. Match inport and outport against names of logical ports within to implement ingress and egress ACLs, respectively. In logical switches connected to logical routers, the special port name ROUTER refers to the logical router port.

The action to take when the ACL rule matches:

 If set to true, packets that match the ACL will trigger a log message on the transport node or nodes that perform ACL processing. Logging may be combined with any . See External IDs at the beginning of this document.

Each row represents one L3 logical router. A given router's ports are the rows whose column points to its row.

The logical router's own IP address. The logical router uses this address for ICMP replies (e.g. network unreachable messages) and other traffic that it originates and responds to traffic destined to this address (e.g. ICMP echo requests). IP address to use as default gateway, if any. See External IDs at the beginning of this document.

A port within an L3 logical router.

A router port is always attached to a switch port. The connection can be identified by following the column from an appropriate row.

The router to which the port belongs. The IP network and netmask of the network on the router port. Used for routing. The Ethernet address that belongs to this router port. See External IDs at the beginning of this document.