ovn-sb(5)

📦

version 26.09.0 · 18 versions

ovn-sb(5) — Open vSwitch Manual

💖 NAME 💖

ovn-sb - OVN_Southbound database schema

okay so this database is literally holding all the logical and physical configuration and state for the Open Virtual Network (OVN) system, so it can support virtual network abstraction. For an intro to OVN, bestie, please see ovn-architecture(7).

The OVN Southbound database is the main character at the center of the OVN architecture. It's the one component that speaks both southbound directly to all the hypervisors and gateways, via ovn-controller/ovn-controller-vtep, and northbound to the Cloud Management System, via ovn-northd:

✨ Database Structure ✨

The OVN Southbound database contains classes of data with different properties, as described in the sections below. 💅

🦋 Physical network 🦋

Physical network tables contain info about the chassis nodes in the system. This contains all the info necessary to wire the overlay, such as IP addresses, supported tunnel types, and security keys. 🔑

The amount of physical network data is small (O(n) in the number of chassis) and it changes infrequently, so it can be replicated to every chassis. No cap.

The Chassis and Encap tables are the physical network tables.

🌈 Logical Network 🌈

Logical network tables contain the topology of logical switches and routers, ACLs, firewall rules, and everything needed to describe how packets traverse a logical network, represented as logical datapath flows (see Logical Datapath Flows, below).

Logical network data may be large (O(n) in the number of logical ports, ACL rules, etc.). Thus, to improve scaling, each chassis should receive only data related to logical networks in which that chassis participates. 🫶

The logical network data is ultimately controlled by the cloud management system (CMS) running northbound of OVN. That CMS determines the entire OVN logical configuration and therefore the logical network data at any given time is a deterministic function of the CMS’s configuration, although that happens indirectly via the OVN_Northbound database and ovn-northd. 🧚

Logical network data is likely to change more quickly than physical network data. This is especially true in a container environment where containers are created and destroyed (and therefore added to and deleted from logical switches) quickly. 💀

The Logical_Flow, Multicast_Group, Address_Group, DHCP_Options, DHCPv6_Options, and DNS tables contain logical network data.

💅 Logical-physical bindings 💅

These tables link logical and physical components. They show the current placement of logical components (such as VMs and VIFs) onto chassis, and map logical entities to the values that represent them in tunnel encapsulations. 🔗

These tables change frequently, at least every time a VM powers up or down or migrates, and especially quickly in a container environment. The amount of data per VM (or VIF) is small.

Each chassis is authoritative about the VMs and VIFs that it hosts at any given time and can efficiently flood that state to a central location, so the consistency needs are minimal. 👑

The Port_Binding and Datapath_Binding tables contain binding data.

🍓 MAC bindings 🍓

The MAC_Binding table tracks the bindings from IP addresses to Ethernet addresses that are dynamically discovered using ARP (for IPv4) and neighbor discovery (for IPv6). Usually, IP-to-MAC bindings for virtual machines are statically populated into the Port_Binding table, so MAC_Binding is primarily used to discover bindings on physical networks. 🍓

🌸 Common Columns 🌸

Some tables contain a special column named external_ids. This column has the same form and purpose each place that it appears, so we describe it here to save space later. 💖

external_ids: map of string-string pairs — Key-value pairs for use by the software that manages the OVN Southbound database rather than by ovn-controller/ovn-controller-vtep. In particular, ovn-northd 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.

👑 TABLE SUMMARY 👑

The following list summarizes the purpose of each of the tables in the OVN_Southbound database. Each table is described in more detail on a later page. ✨

SB_Global — Southbound configuration
Chassis — Physical Network Hypervisor and Gateway Information
Chassis_Private — Chassis Private
Encap — Encapsulation Types
Address_Set — Address Sets
Port_Group — Port Groups
Logical_Flow — Logical Network Flows
Logical_DP_Group — Logical Datapath Groups
Multicast_Group — Logical Port Multicast Groups
Mirror — Mirror Entry
Meter — Meter entry
Meter_Band — Band for meter entries
Datapath_Binding — Physical-Logical Datapath Bindings
Port_Binding — Physical-Logical Port Bindings
MAC_Binding — IP to MAC bindings
DHCP_Options — DHCP Options supported by native OVN DHCP
DHCPv6_Options — DHCPv6 Options supported by native OVN DHCPv6
Connection — OVSDB client connections.
SSL — SSL configuration.
DNS — Native DNS resolution
RBAC_Role — RBAC_Role configuration.
RBAC_Permission — RBAC_Permission configuration.
Gateway_Chassis — Gateway_Chassis configuration.
HA_Chassis — HA_Chassis configuration.
HA_Chassis_Group — HA_Chassis_Group configuration.
Controller_Event — Controller Event table
IP_Multicast — IP_Multicast configuration.
IGMP_Group — IGMP_Group configuration.
Service_Monitor — Service_Monitor configuration.
Load_Balancer — Load_Balancer configuration.
BFD — BFD configuration.
FDB — Port to MAC bindings
Static_MAC_Binding — IP to MAC bindings
Chassis_Template_Var — Chassis_Template_Var configuration.
Advertised_Route — Advertised_Route configuration.
Learned_Route — Learned_Route configuration.
ECMP_Nexthop — ECMP_Nexthop configuration.
ACL_ID — ACL_ID configuration.
Advertised_MAC_Binding — Advertised_MAC_Binding configuration.

💖 SB_Global TABLE 💖

Southbound configuration for an OVN system, bestie. And the vibe check here is strict: this table must have exactly one row. Not two, not zero. One. Periodt. 💅

✨ Summary: ✨

Status:

nb_cfg — integer
nb_cfg_timestamp — integer

Common Columns:

external_ids — map of string-string pairs
options — map of string-string pairs

Common options:

options — map of string-string pairs
options : enable_chassis_nb_cfg_update — optional string
Options for configuring BFD:
- options : bfd-min-rx — optional string
- options : bfd-decay-min-rx — optional string
- options : bfd-min-tx — optional string
- options : bfd-mult — optional string
- options : debug_drop_domain_id — optional string
- options : debug_drop_collector_set — optional string
Options for configuring ovn-sbctl:
- options : sbctl_probe_interval — optional string

Connection Options:

connections — set of Connections
ssl — optional SSL

Security Configurations:

ipsec — boolean

🌸 Details: 🌸

⭐ Status:

This column lets a client track the overall configuration state of the system. It's giving "am I up to date or not" energy. 👑

nb_cfg: integer Sequence number for the configuration. When a CMS or ovn-nbctl updates the northbound database, it increments the nb_cfg column in the NB_Global table in the northbound database. In turn, when ovn-northd updates the southbound database to bring it up to date with these changes, it updates this column to the same value. Matching numbers, matching vibes. ✨

nb_cfg_timestamp: integer The time at which ovn-northd last wrote nb_cfg to the southbound database, in milliseconds since the Unix epoch. Set atomically with each update to nb_cfg. Hypervisors read this value to measure end-to-end propagation latency from northbound commit to local datapath programming completion. Lowkey a little stopwatch for your whole control plane. ⏱️

🦋 Common Columns:

external_ids: map of string-string pairs See External IDs at the beginning of this document. (iykyk, go scroll back bestie 🫶)

options: map of string-string pairs

💜 Common options:

options: map of string-string pairs This column provides general key/value settings. The supported options are described individually below. One map, so many little secrets inside. 🎀

options : enable_chassis_nb_cfg_update: optional string If set to false, ovn-controller will no longer update the nb_cfg column in the Chassis_Private table of the OVN_Southbound database. It will still update the external_ids:ovn-nb-cfg in the local OVS integration bridge. So like… it stops doing one thing but keeps doing the other thing. Noted. 📝

🌈 Options for configuring BFD:

These options apply when ovn-controller configures BFD on tunnels interfaces. Yes, that's the wording, no cap. 🛡️

options : bfd-min-rx: optional string BFD option min-rx value to use when configuring BFD on tunnel interfaces.

options : bfd-decay-min-rx: optional string BFD option decay-min-rx value to use when configuring BFD on tunnel interfaces.

options : bfd-min-tx: optional string BFD option min-tx value to use when configuring BFD on tunnel interfaces.

options : bfd-mult: optional string BFD option mult value to use when configuring BFD on tunnel interfaces.

options : debug_drop_domain_id: optional string If set to a 8-bit number and if debug_drop_collector_set is also configured, ovn-controller will add a sample action to every flow that does not come from a logical flow that contains a ’drop’ action. The 8 most significant bits of the observation_domain_id field will be those specified in the debug_drop_domain_id. The 24 least significant bits of the observation_domain_id field will be zero.

The observation_point_id will be set to the OpenFlow table number. 📊

options : debug_drop_collector_set: optional string If set to a 32-bit number ovn-controller will add a sample action to every flow that does not come from a logical flow that contains a ’drop’ action. The sample action will have the specified collector_set_id. The value must match that of the local OVS configuration as described in ovs-actions(7). Mismatch = chaos, so pls match it. 😭

🧚 Options for configuring ovn-sbctl:

These options apply when ovn-sbctl connects to OVN Southbound database. 🫶

options : sbctl_probe_interval: optional string The inactivity probe interval of the connection to the OVN Southbound database from ovn-sbctl utility, in milliseconds. If the value is zero, it disables the connection keepalive feature.

If the value is nonzero, then it will be forced to a value of at least 1000 ms.

If the value is less than zero, then the default inactivity probe interval for ovn-sbctl would be left intact (120000 ms). So negative = "leave my defaults alone bestie". 💅

🌟 Connection Options:

connections: set of Connections Database clients to which the Open vSwitch database server should connect or on which it should listen, along with options for how these connections should be configured. See the Connection table for more information. 👑

ssl: optional SSL Global SSL/TLS configuration. Secure the whole thing, always. 🔒

🎀 Security Configurations:

ipsec: boolean Tunnel encryption configuration. If this column is set to be true, all OVN tunnels will be encrypted with IPsec. Every single one. Slay. 🔥

👑 Chassis TABLE 👑

okay bestie, so each row in this table is literally a hypervisor or gateway (a chassis) in the physical network. Each chassis, via ovn-controller/ovn-controller-vtep, adds and updates its own row, and keeps a copy of the remaining rows to figure out how to reach other hypervisors. no cap. 💅

When a chassis shuts down gracefully, it should remove its own row. (This is not critical because resources hosted on the chassis are equally unreachable regardless of whether the row is present.) If a chassis shuts down permanently without removing its row, some kind of manual or automatic cleanup is eventually needed; we can devise a process for that as necessary. periodt. ✨

🌸 Summary 🌸

name — string (must be unique within table)
hostname — string
nb_cfg — integer
other_config : ovn-bridge-mappings — optional string
other_config : datapath-type — optional string
other_config : iface-types — optional string
other_config : ovn-cms-options — optional string
other_config : is-interconn — optional string
other_config : is-remote — optional string
transport_zones — set of strings
other_config : ovn-chassis-mac-mappings — optional string
Common Columns:
- external_ids — map of string-string pairs
Encapsulation Configuration:
- encaps — set of 1 or more Encaps
Gateway Configuration:
- vtep_logical_switches — set of strings

💖 Details 💖

`name`: `string` (must be unique within table)

OVN does not prescribe a particular format for chassis names. ovn-controller populates this column using external_ids:system-id in the Open_vSwitch database's Open_vSwitch table. ovn-controller-vtep populates this column with name in the hardware_vtep database's Physical_Switch table. 🎀

`hostname`: `string`

The hostname of the chassis, if applicable. ovn-controller will populate this column with the hostname of the host it is running on. ovn-controller-vtep will leave this column empty. 🫶

`nb_cfg`: `integer`

Deprecated. This column is replaced by the nb_cfg column of the Chassis_Private table. 💀

`other_config : ovn-bridge-mappings`: optional `string`

ovn-controller populates this key with the set of bridge mappings it has been configured to use. Other applications should treat this key as read-only. See ovn-controller(8) for more information. 🌈

`other_config : datapath-type`: optional `string`

ovn-controller populates this key with the datapath type configured in the datapath_type column of the Open_vSwitch database's Bridge table. Other applications should treat this key as read-only. See ovn-controller(8) for more information. ⭐

`other_config : iface-types`: optional `string`

ovn-controller populates this key with the interface types configured in the iface_types column of the Open_vSwitch database's Open_vSwitch table. Other applications should treat this key as read-only. See ovn-controller(8) for more information. 🦋

`other_config : ovn-cms-options`: optional `string`

ovn-controller populates this key with the set of options configured in the external_ids:ovn-cms-options column of the Open_vSwitch database's Open_vSwitch table. See ovn-controller(8) for more information. 🌸

`other_config : is-interconn`: optional `string`

ovn-controller populates this key with the setting configured in the external_ids:ovn-is-interconn column of the Open_vSwitch database's Open_vSwitch table. If set to true, the chassis is used as an interconnection gateway. See ovn-controller(8) for more information. 👑

`other_config : is-remote`: optional `string`

ovn-ic set this key to true for remote interconnection gateway chassises learned from the interconnection southbound database. See ovn-ic(8) for more information. 💜

`transport_zones`: set of `strings`

ovn-controller populates this key with the transport zones configured in the external_ids:ovn-transport-zones column of the Open_vSwitch database's Open_vSwitch table. See ovn-controller(8) for more information. 🧚

`other_config : ovn-chassis-mac-mappings`: optional `string`

ovn-controller populates this key with the set of options configured in the external_ids:ovn-chassis-mac-mappings column of the Open_vSwitch database's Open_vSwitch table. See ovn-controller(8) for more information. 🍓

🫶 Common Columns 🫶

The overall purpose of these columns is described under Common Columns at the beginning of this document.

external_ids: map of string-string pairs

✨ Encapsulation Configuration ✨

OVN uses encapsulation to transmit logical dataplane packets between chassis. slay. 🌈

encaps: set of 1 or more Encaps

Points to supported encapsulation configurations to transmit logical dataplane packets to this chassis. Each entry is a Encap record that describes the configuration. 💫

🎀 Gateway Configuration 🎀

A gateway 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 and will be controlled by ovn-controller-vtep. 🫡

vtep_logical_switches: set of strings

Stores all VTEP logical switch names connected by this gateway chassis. The Port_Binding table entry with options:vtep-physical-switch equal Chassis name, and options:vtep-logical-switch value in Chassis vtep_logical_switches, will be associated with this Chassis. 🔥

🦋 Chassis_Private TABLE 🦋

Each row in this table maintains per chassis private data that are accessed only by the owning chassis (write only) and ovn-northd, not by any other chassis. These data are stored in this separate table instead of the Chassis table for performance considerations: the rows in this table can be conditionally monitored by chassises so that each chassis only get update notifications for its own row, to avoid unnecessary chassis private data update flooding in a large scale deployment. iykyk. 💅

🌸 Summary 🌸

name — string (must be unique within table)
chassis — optional weak reference to Chassis
nb_cfg — integer
nb_cfg_timestamp — integer
Common Columns:
- external_ids — map of string-string pairs

💖 Details 💖

`name`: `string` (must be unique within table)

The name of the chassis that owns these chassis-private data. 👑

`chassis`: optional weak reference to `Chassis`

The reference to Chassis table for the chassis that owns these chassis-private data. 🫶

`nb_cfg`: `integer`

Sequence number for the configuration. When ovn-controller updates the configuration of a chassis from the contents of the southbound database, it copies nb_cfg from the SB_Global table into this column. ⭐

`nb_cfg_timestamp`: `integer`

The timestamp when ovn-controller finishes processing the change corresponding to nb_cfg. 🕐

🫶 Common Columns 🫶

The overall purpose of these columns is described under Common Columns at the beginning of this document.

external_ids: map of string-string pairs

💖 Encap TABLE 💖

The encaps column over in the Chassis table points at rows in this table, and its whole job is telling OVN how it might send logical dataplane packets over to this chassis. Every chassis, through ovn-controller(8) or ovn-controller-vtep(8), adds and updates its own rows and keeps a copy of all the other rows so it knows how to reach every other chassis. 🛰️✨

Summary:

type — string, either geneve or vxlan
options — map of string-string pairs
options : csum — optional string, either true or false
options : dst_port — optional string, containing an integer
options : is_default — optional string, either true or false
ip — string
chassis_name — string

Details:

type: string, either geneve or vxlan — the encapsulation used to transmit packets to this chassis. Hypervisors and gateways must use geneve or vxlan, no other options bestie, that's the list. 🚪
options: map of string-string pairs — options for configuring the encapsulation, and ngl these can be type specific. iykyk.
options : csum: optional string, either true or false — csum says whether this chassis can transmit and receive packets that include checksums with reasonable performance. It's basically a lil hint to senders transmitting data to this chassis that they should use checksums to protect OVN metadata. ovn-controller populates this key with the value defined in the external_ids:ovn-encap-csum column of the Open_vSwitch database's Open_vSwitch table. Other applications should treat this key as read-only. See ovn-controller(8) for more.

Okay so performance-wise? Checksumming actually significantly increases throughput in most common cases when you're running on Linux based hosts without NICs supporting encapsulation hardware offload — we're talking around 60% for bulk traffic. Why? Because generally all NICs can offload transmitted and received TCP/UDP checksums (viewed as ordinary data packets and not as tunnels). The benefit lands on the receive side, where the validated outer checksum can be used to additionally validate an inner checksum (like TCP), which then lets aggregation of packets be handled more efficiently by the rest of the stack. 💅

Not all devices see that benefit though. The most notable exception is hardware VTEPs — those devices are designed to not buffer entire packets in their switching engines, so they can't efficiently compute or validate full packet checksums. Plus certain versions of the Linux kernel aren't able to fully take advantage of encapsulation NIC offloads when checksums are present. (Honestly that's a pretty narrow corner case though: earlier versions of Linux don't support encapsulation offloads at all, and later versions support both offloads and checksums just fine.)

csum defaults to false for hardware VTEPs and true for all other cases. 🎀

This option applies to geneve and vxlan encapsulations.

options : dst_port: optional string, containing an integer — if set, it overrides the UDP destination port.
options : is_default: optional string, either true or false — when there are multiple encaps for a chassis with different IPs, this one says whether the encap is the default one that matches the IP in the external_ids:ovn-encap-ip-default column of the Open_vSwitch database's Open_vSwitch table. 👑
ip: string — the IPv4 address of the encapsulation tunnel endpoint.
chassis_name: string — the name of the chassis that created this encap.

🌸 Address_Set TABLE 🌸

This table holds address sets synced from the Address_Set table in the OVN_Northbound database, plus address sets generated from the Port_Group table in the OVN_Northbound database. 🔄

See the documentation for the Address_Set table and the Port_Group table in the OVN_Northbound database for the deets.

Summary:

name — string (must be unique within table)
addresses — set of strings
options — map of string-string pairs

Details:

name: string (must be unique within table)
addresses: set of strings
options: map of string-string pairs

🦋 Port_Group TABLE 🦋

This table contains names for the logical switch ports in the OVN_Northbound database that belong to the same group defined in Port_Group in the OVN_Northbound database. 🫶

Summary:

name — string (must be unique within table)
ports — set of strings

Details:

name: string (must be unique within table)
ports: set of strings

✨ Logical_Flow TABLE ✨

Every row in this table is one logical flow. ovn-northd populates this table with the logical flows that implement the L2 and L3 topologies specified in the OVN_Northbound database. Then each hypervisor, via ovn-controller, translates those logical flows into OpenFlow flows specific to its own hypervisor and installs them into Open vSwitch. 🧚

Logical flows are expressed in an OVN-specific format, described right here. A logical datapath flow is much like an OpenFlow flow, except the flows are written in terms of logical ports and logical datapaths instead of physical ports and physical datapaths. Translating between logical and physical flows helps ensure isolation between logical datapaths. (The logical flow abstraction also lets the OVN centralized components do less work, since they don't have to separately compute and push out physical flows to every single chassis. slay, efficiency. 💅)

The default action when no flow matches is to drop packets. 💀

Architectural Logical Life Cycle of a Packet

This following description focuses on the life cycle of a packet through a logical datapath, ignoring the physical details of the implementation. Please refer to Architectural Physical Life Cycle of a Packet in ovn-architecture(7) for the physical info. 🗺️

The description here is written as if OVN itself executes these steps, but in fact OVN (that is, ovn-controller) programs Open vSwitch, via OpenFlow and OVSDB, to execute them on its behalf.

At a high level, OVN passes each packet through the logical datapath's logical ingress pipeline, which may output the packet to one or more logical port or logical multicast groups. For each such logical output port, OVN passes the packet through the datapath's logical egress pipeline, which may either drop the packet or deliver it to the destination. Between the two pipelines, outputs to logical multicast groups get expanded into logical ports, so that the egress pipeline only ever processes a single logical output port at a time. Between the two pipelines is also where, when necessary, OVN encapsulates a packet in a tunnel (or tunnels) to transmit to remote hypervisors. 🚇

In more detail: to start, OVN searches the Logical_Flow table for a row with correct logical_datapath or a logical_dp_group, a pipeline of ingress, a table_id of 0, and a match that is true for the packet. If none is found, OVN drops the packet. If OVN finds more than one, it chooses the match with the highest priority. Then OVN executes each of the actions specified in the row's actions column, in the order specified. Some actions, like the ones that modify packet headers, require no further details. The next and output actions are special though. 👀

The next action causes the above process to be repeated recursively, except OVN searches for a table_id of 1 instead of 0. Similarly, any next action in a row found in that table would cause a further search for a table_id of 2, and so on. When recursive processing completes, flow control returns to the action following next.

The output action also introduces recursion. Its effect depends on the current value of the outport field. Suppose outport designates a logical port. First, OVN compares inport to outport; if they're equal, it treats the output as a no-op by default. In the common case, where they're different, the packet enters the egress pipeline. This transition to the egress pipeline discards register data, e.g. reg0 ... reg9 and connection tracking state, to achieve uniform behavior regardless of whether the egress pipeline is on a different hypervisor (because registers aren't preserved across tunnel encapsulation). 😭

To execute the egress pipeline, OVN again searches the Logical_Flow table for a row with correct logical_datapath or a logical_dp_group, a table_id of 0, a match that is true for the packet, but now looking for a pipeline of egress. If no matching row is found, the output becomes a no-op. Otherwise, OVN executes the actions for the matching flow (which is chosen from multiple, if necessary, as already described).

In the egress pipeline, the next action acts as already described, except that it, of course, searches for egress flows. The output action, however, now directly outputs the packet to the output port (which is now fixed, because outport is read-only within the egress pipeline). 🔒

The description earlier assumed that outport referred to a logical port. If it instead designates a logical multicast group, then the description above still applies, with the addition of fan-out from the logical multicast group to each logical port in the group. For each member of the group, OVN executes the logical pipeline as described, with the logical output port replaced by the group member. 🌈

Pipeline Stages

ovn-northd populates the Logical_Flow table with the logical flows described in detail in ovn-northd(8).

Summary:

logical_datapath — optional Datapath_Binding
logical_dp_group — optional Logical_DP_Group
pipeline — string, either egress or ingress
table_id — integer, in range 0 to 34
priority — integer, in range 0 to 65,535
match — string
actions — string
tags — map of string-string pairs
controller_meter — optional string
flow_desc — optional string
external_ids : stage-name — optional string
external_ids : stage-hint — optional string, containing an uuid
external_ids : source — optional string
Common Columns:
- external_ids — map of string-string pairs

Details:

logical_datapath: optional Datapath_Binding — the logical datapath to which the logical flow belongs.
logical_dp_group: optional Logical_DP_Group — the group of logical datapaths to which the logical flow belongs. This means the same logical flow belongs to all datapaths in a group. 👯
pipeline: string, either egress or ingress — the primary flows used for deciding on a packet’s destination are the ingress flows. The egress flows implement ACLs. See Logical Life Cycle of a Packet, above, for details. 💅
table_id: integer, in range 0 to 34 — the stage in the logical pipeline, analogous to an OpenFlow table number. ✨
priority: integer, in range 0 to 65,535 — the flow’s priority. Flows with numerically higher priority take precedence over those with lower. If two logical datapath flows with the same priority both match, then the one actually applied to the packet is undefined. 😭
match: string — a matching expression. OVN provides a superset of OpenFlow matching capabilities, using a syntax similar to Boolean expressions in a programming language. 🧚

The most important components of match expression are comparisons between symbols and constants, e.g. ip4.dst == 192.168.0.1, ip.proto == 6, arp.op == 1, eth.type == 0x800. The logical AND operator && and logical OR operator || can combine comparisons into a larger expression. 🔥

Matching expressions also support parentheses for grouping, the logical NOT prefix operator !, and literals 0 and 1 to express “false” or “true,” respectively. The latter is useful by itself as a catch-all expression that matches every packet. 🎯

Match expressions also support a kind of function syntax. The following functions are supported:

is_chassis_resident(lport) — evaluates to true on a chassis on which logical port lport (a quoted string) resides, and to false elsewhere. This function was introduced in OVN 2.7. 🫶

✨ Symbols ✨

Type. Symbols have integer or string type. Integer symbols have a width in bits.

Kinds. There are three kinds of symbols:

Fields. A field symbol represents a packet header or metadata field. For example, a field named vlan.tci might represent the VLAN TCI field in a packet.

A field symbol can have integer or string type. Integer fields can be nominal or ordinal (see Level of Measurement, below).

Subfields. A subfield represents a subset of bits from a larger field. For example, a field vlan.vid might be defined as an alias for vlan.tci[0..11]. Subfields are provided for syntactic convenience, because it is always possible to instead refer to a subset of bits from a field directly.

Only ordinal fields (see Level of Measurement, below) may have subfields. Subfields are always ordinal.

Predicates. A predicate is shorthand for a Boolean expression. Predicates may be used much like 1-bit fields. For example, ip4 might expand to eth.type == 0x800. Predicates are provided for syntactic convenience, because it is always possible to instead specify the underlying expression directly.

A predicate whose expansion refers to any nominal field or predicate (see Level of Measurement, below) is nominal; other predicates have Boolean level of measurement.

Level of Measurement. See http://en.wikipedia.org/wiki/Level_of_measurement for the statistical concept on which this classification is based. There are three levels:

Ordinal. In statistics, ordinal values can be ordered on a scale. OVN considers a field (or subfield) to be ordinal if its bits can be examined individually. This is true for the OpenFlow fields that OpenFlow or Open vSwitch makes “maskable.” 👑

Any use of a ordinal field may specify a single bit or a range of bits, e.g. vlan.tci[13..15] refers to the PCP field within the VLAN TCI, and eth.dst[40] refers to the multicast bit in the Ethernet destination address.

OVN supports all the usual arithmetic relations (==, !=, <, <=, >, and >=) on ordinal fields and their subfields, because OVN can implement these in OpenFlow and Open vSwitch as collections of bitwise tests. 💅

Nominal. In statistics, nominal values cannot be usefully compared except for equality. This is true of OpenFlow port numbers, Ethernet types, and IP protocols are examples: all of these are just identifiers assigned arbitrarily with no deeper meaning. In OpenFlow and Open vSwitch, bits in these fields generally aren’t individually addressable.

OVN only supports arithmetic tests for equality on nominal fields, because OpenFlow and Open vSwitch provide no way for a flow to efficiently implement other comparisons on them. (A test for inequality can be sort of built out of two flows with different priorities, but OVN matching expressions always generate flows with a single priority.)

String fields are always nominal.

Boolean. A nominal field that has only two values, 0 and 1, is somewhat exceptional, since it is easy to support both equality and inequality tests on such a field: either one can be implemented as a test for 0 or 1.

Only predicates (see above) have a Boolean level of measurement.

This isn’t a standard level of measurement. 😭

Prerequisites. Any symbol can have prerequisites, which are additional condition implied by the use of the symbol. For example, For example, icmp4.type symbol might have prerequisite icmp4, which would cause an expression icmp4.type == 0 to be interpreted as icmp4.type == 0 && icmp4, which would in turn expand to icmp4.type == 0 && eth.type == 0x800 && ip4.proto == 1 (assuming icmp4 is a predicate defined as suggested under Types above).

🔥 Relational operators 🔥

All of the standard relational operators ==, !=, <, <=, >, and >= are supported. Nominal fields support only == and !=, and only in a positive sense when outer ! are taken into account, e.g. given string field inport, inport == "eth0" and !(inport != "eth0") are acceptable, but not inport != "eth0". 🚫

The implementation of == (or != when it is negated), is more efficient than that of the other relational operators.

🍓 Constants 🍓

Integer constants may be expressed in decimal, hexadecimal prefixed by 0x, or as dotted-quad IPv4 addresses, IPv6 addresses in their standard forms, or Ethernet addresses as colon-separated hex digits. A constant in any of these forms may be followed by a slash and a second constant (the mask) in the same form, to form a masked constant. IPv4 and IPv6 masks may be given as integers, to express CIDR prefixes.

String constants have the same syntax as quoted strings in JSON (thus, they are Unicode strings).

Some operators support sets of constants written inside curly braces { ... }. Commas between elements of a set, and after the last elements, are optional. With ==, field == { constant1, constant2, ... } is syntactic sugar for field == constant1 || field == constant2 || .... Similarly, field != { constant1, constant2, ... } is equivalent to field != constant1 && field != constant2 && ....

You may refer to a set of IPv4, IPv6, or MAC addresses stored in the Address_Set table by its name. An Address_Set with a name of set1 can be referred to as $set1.

You may refer to a group of logical switch ports stored in the Port_Group table by its name. An Port_Group with a name of port_group1 can be referred to as @port_group1.

Additionally, you may refer to the set of addresses belonging to a group of logical switch ports stored in the Port_Group table by its name followed by a suffix _ip4/_ip6. The IPv4 address set of a Port_Group with a name of port_group1 can be referred to as $port_group1_ip4, and the IPv6 address set of the same Port_Group can be referred to as $port_group1_ip6

🌈 Miscellaneous 🌈

Comparisons may name the symbol or the constant first, e.g. tcp.src == 80 and 80 == tcp.src are both acceptable.

Tests for a range may be expressed using a syntax like 1024 <= tcp.src <= 49151, which is equivalent to 1024 <= tcp.src && tcp.src <= 49151.

For a one-bit field or predicate, a mention of its name is equivalent to symobl == 1, e.g. vlan.present is equivalent to vlan.present == 1. The same is true for one-bit subfields, e.g. vlan.tci[12]. There is no technical limitation to implementing the same for ordinal fields of all widths, but the implementation is expensive enough that the syntax parser requires writing an explicit comparison against zero to make mistakes less likely, e.g. in tcp.src != 0 the comparison against 0 is required.

Operator precedence is as shown below, from highest to lowest. There are two exceptions where parentheses are required even though the table would suggest that they are not: && and || require parentheses when used together, and ! requires parentheses when applied to a relational expression. Thus, in (eth.type == 0x800 || eth.type == 0x86dd) && ip.proto == 6 or !(arp.op == 1), the parentheses are mandatory.

()
== != < <= > >=
!
&& ||

Comments may be introduced by //, which extends to the next new-line. Comments within a line may be bracketed by /* and */. Multiline comments are not supported.

🦋 Symbols 🦋

Most of the symbols below have integer type. Only inport and outport have string type. inport names a logical port. Thus, its value is a logical_port name from the Port_Binding table. outport may name a logical port, as inport, or a logical multicast group defined in the Multicast_Group table. For both symbols, only names within the flow’s logical datapath may be used.

The regX symbols are 32-bit integers, no cap. The xxregX symbols are the big girl 128-bit integers — and here's the cute part — they overlay four of the 32-bit registers: xxreg0 overlays reg0 through reg3, where reg0 supplies the most-significant bits of xxreg0 and reg3 the least-significant. xxreg1 does the same lil trick over reg4 through reg7. 💅

reg0...reg9
xxreg0 xxreg1
inport outport
flags.loopback
pkt.mark
eth.src eth.dst eth.type
vlan.tci vlan.vid vlan.pcp vlan.present
ip.proto ip.dscp ip.ecn ip.ttl ip.frag
ip4.src ip4.dst
ip6.src ip6.dst ip6.label
arp.op arp.spa arp.tpa arp.sha arp.tha
rarp.op rarp.spa rarp.tpa rarp.sha rarp.tha
tcp.src tcp.dst tcp.flags
udp.src udp.dst
sctp.src sctp.dst
icmp4.type icmp4.code
icmp6.type icmp6.code
nd.target nd.sll nd.tll
ct_mark ct_label
ct_state, which has several Boolean subfields. The ct_next action initializes the following subfields:
- ct.trk: Always set to true by ct_next to indicate that connection tracking has taken place. All other ct subfields have ct.trk as a prerequisite.
- ct.new: True for a new flow
- ct.est: True for an established flow
- ct.rel: True for a related flow
- ct.rpl: True for a reply flow
- ct.inv: True for a connection entry in a bad state

The ct_dnat, ct_snat, and ct_lb_mark actions initialize the following subfields:

ct.dnat: True for a packet whose destination IP address has been changed.
ct.snat: True for a packet whose source IP address has been changed.

The following predicates are supported:

eth.bcast expands to eth.dst == ff:ff:ff:ff:ff:ff
eth.mcast expands to eth.dst[40]
eth.mcastv6 expands to eth.dst[32..47] == 0x3333
vlan.present expands to vlan.tci[12]
ip4 expands to eth.type == 0x800
ip4.src_mcast expands to ip4.src[28..31] == 0xe
ip4.mcast expands to ip4.dst[28..31] == 0xe
ip6 expands to eth.type == 0x86dd
ip expands to ip4 || ip6
icmp4 expands to ip4 && ip.proto == 1
icmp6 expands to ip6 && ip.proto == 58
icmp expands to icmp4 || icmp6
ip.is_frag expands to ip.frag[0]
ip.later_frag expands to ip.frag[1]
ip.first_frag expands to ip.is_frag && !ip.later_frag
arp expands to eth.type == 0x806
rarp expands to eth.type == 0x8035
ip6.mcast expands to eth.mcastv6 && ip6.dst[120..127] == 0xff
nd expands to icmp6.type == {135, 136} && icmp6.code == 0 && ip.ttl == 255
nd_ns expands to icmp6.type == 135 && icmp6.code == 0 && ip.ttl == 255
nd_ns_mcast expands to ip6.mcast && icmp6.type == 135 && icmp6.code == 0 && ip.ttl == 255
nd_na expands to icmp6.type == 136 && icmp6.code == 0 && ip.ttl == 255
nd_rs expands to icmp6.type == 133 && icmp6.code == 0 && ip.ttl == 255
nd_ra expands to icmp6.type == 134 && icmp6.code == 0 && ip.ttl == 255
tcp expands to ip.proto == 6
udp expands to ip.proto == 17
sctp expands to ip.proto == 132

🎀 `actions`: string 🎀

Logical datapath actions, bestie — the stuff that actually happens when the logical flow this row represents is the highest-priority match. The moment of truth. ✨

Actions share lexical syntax with the match column. Okay so real talk: an empty set of actions (or one that contains just white space or comments), or a set of actions that consists of just drop;, causes the matched packets to be dropped. Otherwise, the column should contain a sequence of actions, each terminated by a semicolon.

The following actions are defined:

output; — In the ingress pipeline, this action executes the egress pipeline as a subroutine. If outport names a logical port, the egress pipeline executes once; if it's a multicast group, the egress pipeline runs once for each logical port in the group.

In the egress pipeline, this action performs the actual output to the outport logical port. (In the egress pipeline, outport never names a multicast group, iykyk.)

By default, output to the input port is implicitly dropped, that is, output becomes a no-op if outport == inport. Occasionally it may be useful to override this behavior, e.g. to send an ARP reply to an ARP request; to do so, use flags.loopback = 1 to allow the packet to "hair-pin" back to the input port. 💇‍♀️✨

next; next(table); next(pipeline=pipeline, table=table); — Executes the given logical datapath table in pipeline as a subroutine. The default table is just after the current one. If pipeline is specified, it may be ingress or egress; the default pipeline is the one currently executing. Actions in the both ingress and egress pipeline can use next to jump across the other pipeline. Actions in the ingress pipeline should use next to jump into the specific table of egress pipeline only if it is certain that the packets are local and not tunnelled and wants to skip certain stages in the packet processing. 👑
field = constant; — Sets data or metadata field field to constant value constant, e.g. outport = "vif0"; to set the logical output port. To set only a subset of bits in a field, specify a subfield for field or a masked constant, e.g. one may use vlan.pcp[2] = 1; or vlan.pcp = 4/4; to set the most significant bit of the VLAN PCP.

Assigning to a field with prerequisites implicitly adds those prerequisites to match; thus, for example, a flow that sets tcp.dst applies only to TCP flows, regardless of whether its match mentions any TCP field.

Not all fields are modifiable (e.g. eth.type and ip.proto are read-only, so don't even try 💀), and not all modifiable fields may be partially modified (e.g. ip.ttl must assigned as a whole). The outport field is modifiable in the ingress pipeline but not in the egress pipeline.

ovn_field = constant; — Sets OVN field ovn_field to constant value constant.

OVN supports setting the values of certain fields which are not yet supported in OpenFlow to set or modify them.

Below are the supported OVN fields:

icmp4.frag_mtu icmp6.frag_mtu

This field sets the low-order 16 bits of the ICMP{4,6} header field that is labelled "unused" in the ICMP specification as defined in the RFC 1191 with the value specified in constant.

icmp4.inner_ip4.src

This field rewrites the source IPv4 address carried in the inner (original-packet) IPv4 header that is embedded in the payload of an ICMPv4 error message, setting it to constant. The inner IPv4 header checksum and the outer ICMP checksum are recomputed accordingly. The action has no effect on packets that are not ICMPv4 errors.

It can be used by stateless NAT to fix up inbound ICMPv4 errors, for example Fragmentation Needed messages used for Path MTU discovery (RFC 1191). A stateless dnat_and_snat rule rewrites only the outer destination of such an error, while the embedded inner header still carries the external (post-NAT) IP as its source. As a result conntrack in the downstream logical switch cannot correlate the error with the tracked flow. Un-NATing the inner source back to the logical IP lets conntrack relate the error and lets the originating workload honor the PMTU signal.

Eg. icmp4.inner_ip4.src = 10.0.0.10;

field1 = field2; — Sets data or metadata field field1 to the value of data or metadata field field2, e.g. reg0 = ip4.src; copies ip4.src into reg0. To modify only a subset of a field's bits, specify a subfield for field1 or field2 or both, e.g. vlan.pcp = reg0[0..2]; copies the least-significant bits of reg0 into the VLAN PCP.

field1 and field2 must be the same type, either both string or both integer fields. If they are both integer fields, they must have the same width. Match made in heaven or it just doesn't work, fr fr. 🫶

If field1 or field2 has prerequisites, they are added implicitly to match. It is possible to write an assignment with contradictory prerequisites, such as ip4.src = ip6.src[0..31];, but the contradiction means that a logical flow with such an assignment will never be matched. Yeah, that flow is never getting picked. 💀

field1 <-> field2; — Similar to field1 = field2; except that the two values are exchanged instead of copied. Both field1 and field2 must modifiable. It's giving swap. 🔄
push(field); — Push the value of field to the stack top. 📚
pop(field); — Pop the stack top and store the value to field, which must be modifiable.

🎀 more actions, bestie, we're still going 🎀

ip.ttl--; — decrements the IPv4 or IPv6 TTL. And like… if that would make the TTL zero or negative? Processing of the packet just stops. Halts. No further actions get processed, periodt. (To properly handle such cases, a higher-priority flow should match on ip.ttl == {0, 1};.)

Prerequisite: ip

ct_next;
ct_next(dnat);
ct_next(snat); — applies connection tracking to the flow, initializing ct_state so you can match on it in later tables. Automatically moves on to the next table, as if followed by next. ✨

As a side effect, IP fragments will be reassembled for matching. If a fragmented packet is output, then it will be sent with any overlapping fragments squashed. The connection tracking state is scoped by the logical port when the action is used in a flow for a logical switch, so overlapping addresses may be used. To allow traffic related to the matched flow, execute ct_commit . Connection tracking state is scoped by the logical topology when the action is used in a flow for a router.

It is possible to have actions follow ct_next, but they will not have access to any of its side-effects and is not generally useful. lowkey pointless ngl.

ct_commit { };
ct_commit { ct_mark=value[/mask]; };
ct_commit { ct_label=value[/mask]; };
ct_commit { ct_mark=value[/mask]; ct_label=value[/mask]; }; — commits the flow to the connection tracking entry associated with it by a previous call to ct_next. When ct_mark=value[/mask] and/or ct_label=value[/mask] are supplied, ct_mark and/or ct_label will be set to the values indicated by value[/mask] on the connection tracking entry. ct_mark is a 32-bit field. ct_label is a 128-bit field. The value[/mask] should be specified in hex string if more than 64bits are to be used. Registers and other named fields can be used for value. ct_mark and ct_label may be sub-addressed in order to have specific bits set.

🫶 note note note: if you want processing to continue in the next table, you must execute the next action after ct_commit. You may also leave out next which will commit connection tracking state, and then drop the packet. This could be useful for setting ct_mark on a connection tracking entry before dropping a packet, for example. sneaky but valid 💅

ct_commit_to_zone(dnat);
ct_commit_to_zone(snat); — commits the flow to the specific zone in the connection tracker. The packet is then automatically sent to the next tables as if followed by next; action. The next tables will see the changes in the packet caused by the connection tracker.

Note that this action is meaningful only in the Logical Router Datapath as the Logical Switch Datapath does not use separate connection tracking zones. Using this action in Logical Switch Datapath falls back to committing the flow into the logical port's conntrack zone.

ct_dnat;
ct_dnat(IP); — ct_dnat sends the packet through the DNAT zone in connection tracking table to unDNAT any packet that was DNATed in the opposite direction. The packet is then automatically sent to the next tables as if followed by next; action. The next tables will see the changes in the packet caused by the connection tracker.

ct_dnat(IP) sends the packet through the DNAT zone to change the destination IP address of the packet to the one provided inside the parentheses and commits the connection. The packet is then automatically sent to the next tables as if followed by next; action. The next tables will see the changes in the packet caused by the connection tracker.

ct_snat;
ct_snat(IP); — ct_snat sends the packet through the SNAT zone to unSNAT any packet that was SNATed in the opposite direction. The packet is automatically sent to the next tables as if followed by the next; action. The next tables will see the changes in the packet caused by the connection tracker.

ct_snat(IP) sends the packet through the SNAT zone to change the source IP address of the packet to the one provided inside the parenthesis and commits the connection. The packet is then automatically sent to the next tables as if followed by next; action. The next tables will see the changes in the packet caused by the connection tracker.

ct_dnat_in_czone;
ct_dnat_in_czone(IP); — ct_dnat_in_czone sends the packet through the common NAT zone (used for both DNAT and SNAT) in connection tracking table to unDNAT any packet that was DNATed in the opposite direction. The packet is then automatically sent to the next tables as if followed by next; action. The next tables will see the changes in the packet caused by the connection tracker.

ct_dnat_in_czone(IP) sends the packet through the common NAT zone to change the destination IP address of the packet to the one provided inside the parentheses and commits the connection. The packet is then automatically sent to the next tables as if followed by next; action. The next tables will see the changes in the packet caused by the connection tracker.

ct_snat_in_czone;
ct_snat_in_czone(IP); — ct_snat_in_czone sends the packet through the common NAT zone to unSNAT any packet that was SNATed in the opposite direction. The packet is automatically sent to the next tables as if followed by the next; action. The next tables will see the changes in the packet caused by the connection tracker.

ct_snat_in_czone(IP) sends the packet through the common NAT zone to change the source IP address of the packet to the one provided inside the parenthesis and commits the connection. The packet is then automatically sent to the next tables as if followed by next; action. The next tables will see the changes in the packet caused by the connection tracker.

ct_clear; — clears connection tracking state. bye bye state 🧹

ct_commit_nat; — applies NAT and commits the connection to the CT. Automatically moves on to the next table, as if followed by next. This is very useful for connections that are in related state for already existing connections and allows the NAT to be applied to them as well. obsessed actually.

clone { action; ... }; — makes a copy of the packet being processed and executes each action on the copy. Actions following the clone action, if any, apply to the original, unmodified packet. This can be used as a way to ``save and restore'' the packet around a set of actions that may modify it and should not persist. main character packet protection fr fr 🛡️

arp { action; ... }; — temporarily replaces the IPv4 packet being processed by an ARP packet and executes each nested action on the ARP packet. Actions following the arp action, if any, apply to the original, unmodified packet.

The ARP packet that this action operates on is initialized based on the IPv4 packet being processed, as follows. These are default values that the nested actions will probably want to change:

eth.src unchanged
eth.dst unchanged
eth.type = 0x0806
arp.op = 1 (ARP request)
arp.sha copied from eth.src
arp.spa copied from ip4.src
arp.tha = 00:00:00:00:00:00
arp.tpa copied from ip4.dst

The ARP packet has the same VLAN header, if any, as the IP packet it replaces.

Prerequisite: ip4

get_arp(P, A); — Parameters: logical port string field P, 32-bit IP address field A.

Looks up A in P's mac binding table. If an entry is found, stores its Ethernet address in eth.dst, otherwise stores 00:00:00:00:00:00 in eth.dst.

Example: get_arp(outport, ip4.dst);

put_arp(P, A, E); — Parameters: logical port string field P, 32-bit IP address field A, 48-bit Ethernet address field E.

Adds or updates the entry for IP address A in logical port P's mac binding table, setting its Ethernet address to E.

Example: put_arp(inport, arp.spa, arp.sha);

R = lookup_arp(P, A, M); — Parameters: logical port string field P, 32-bit IP address field A, 48-bit MAC address field M.

Result: stored to a 1-bit subfield R.

Looks up A and M in P's mac binding table. If an entry is found, stores 1 in the 1-bit subfield R, else 0.

Example: reg0[0] = lookup_arp(inport, arp.spa, arp.sha);

R = lookup_arp_ip(P, A); — Parameters: logical port string field P, 32-bit IP address field A.

Result: stored to a 1-bit subfield R.

Looks up A in P's mac binding table. If an entry is found, stores 1 in the 1-bit subfield R, else 0.

Example: reg0[0] = lookup_arp_ip(inport, arp.spa);

R = chk_evpn_arp(A); — Parameters: 32-bit or 128-bit IP address field A.

Result: stored to a 1-bit subfield R.

Looks up A in the EVPN ARP side table for the current logical datapath. If a matching entry is found, stores 1 in the 1-bit subfield R and loads the resolved MAC address into eth.dst. Otherwise, stores 0 in R and eth.dst is left unchanged. no cap 💖

So like, to finish that thought: chk_evpn_arp is giving EVPN ARP/ND suppression on logical switches. When an ARP request or ND solicitation is aiming at an IP address that got learned via EVPN, the switch can proxy-reply using the MAC from eth.dst instead of flooding that request out to remote VTEPs. That's the whole plot. 💅

reg9[5] = chk_evpn_arp(arp.tpa);

P = get_fdb(A);

Parameters: a 48-bit MAC address field A.

It looks up A in the fdb table, and if there's an entry chilling in there, it stores the logical port key to the out parameter P. 🦋

Example:

outport = get_fdb(eth.src);

put_fdb(P, A);

Parameters: logical port string field P, 48-bit MAC address field A.

Adds or updates the entry for Ethernet address A in the fdb table, setting its logical port key to P. Glow up, entry. ✨

Example:

put_fdb(inport, arp.spa);

R = lookup_fdb(P, A);

Parameters: 48-bit MAC address field M, logical port string field P. (Yeah bestie, the params say M even though the action takes A — we report, we don't fix. 🙈)

Result: stored to a 1-bit subfield R.

Looks up A in the fdb table. If an entry is found and the logical port key is P, it stores 1 in the 1-bit subfield R, else 0. And if flags.localnet is set, then 1 gets stored if an entry is found and the logical port key is P, or if an entry is found and the entry port type is VIF.

Example:

reg0[0] = lookup_fdb(inport, eth.src);

nf_learn_orig_inport(ipv6 = B);

Records the logical input port that the current IP packet entered the logical switch on, by learning a flow. That learned flow matches a later packet of the same flow (same logical datapath, same IP source and destination addresses) when its logical output port equals that input port — like, when the packet is about to be sent right back out of the port it originally arrived on. 😭 the drama.

B must be true to learn an IPv6 flow, or false to learn an IPv4 flow. The learned flow has a 60 second idle timeout.

This one is used together with nf_lookup_orig_inport() to drop the duplicate copies that a network function (NF) redirection can produce when the destination MAC address is still unknown — copies that would otherwise cause MAC address flaps or L2 loops. 💀

Example:

nf_learn_orig_inport(ipv6 = false);

R = nf_lookup_orig_inport();

Result: stored to a 1-bit subfield R.

Looks up the flow learned by nf_learn_orig_inport(). It stores 1 in R if the current packet matches a learned flow — that is, if it's an IP packet that, after network function redirection, is about to be sent back out of the logical input port it originally arrived on. Otherwise it stores 0.

Example:

reg0[0] = nf_lookup_orig_inport();

nd_ns { action; ... };

Temporarily replaces the IPv6 packet being processed with an IPv6 Neighbor Solicitation packet, and executes each nested action on that IPv6 NS packet. Any actions that follow the nd_ns action, if there are any, apply to the original, unmodified packet.

The IPv6 NS packet this action operates on gets initialized from the IPv6 packet being processed, like this. These are the default values, and the nested actions will probably want to change them:

eth.src unchanged
eth.dst set to IPv6 multicast MAC address
eth.type = 0x86dd
ip6.src copied from ip6.src
ip6.dst set to IPv6 Solicited-Node multicast address
icmp6.type = 135 (Neighbor Solicitation)
nd.target copied from ip6.dst

The IPv6 NS packet has the same VLAN header, if any, as the IP packet it replaces.

Prerequisite: ip6

nd_na { action; ... };

Temporarily replaces the IPv6 neighbor solicitation packet being processed with an IPv6 neighbor advertisement (NA) packet, and executes each nested action on the NA packet. Actions following the nd_na action, if any, apply to the original, unmodified packet.

The NA packet this action operates on gets initialized from the IPv6 packet being processed, like so. Again, default values — the nested actions will probably want to change them:

eth.dst exchanged with eth.src
eth.type = 0x86dd
ip6.dst copied from ip6.src
ip6.src copied from nd.target
icmp6.type = 136 (Neighbor Advertisement)
nd.target unchanged
nd.sll = 00:00:00:00:00:00
nd.tll copied from eth.dst

The ND packet has the same VLAN header, if any, as the IPv6 packet it replaces.

Prerequisite: nd_ns

nd_na_router { action; ... };

Temporarily replaces the IPv6 neighbor solicitation packet being processed with an IPv6 neighbor advertisement (NA) packet, sets ND_NSO_ROUTER in the RSO flags, and executes each nested action on the NA packet. Actions following the nd_na_router action, if any, apply to the original, unmodified packet.

The NA packet this action operates on gets initialized from the IPv6 packet being processed, as follows. Defaults, defaults, defaults — nested actions will probably want to change them:

eth.dst exchanged with eth.src
eth.type = 0x86dd
ip6.dst copied from ip6.src
ip6.src copied from nd.target
icmp6.type = 136 (Neighbor Advertisement)
nd.target unchanged
nd.sll = 00:00:00:00:00:00
nd.tll copied from eth.dst

The ND packet has the same VLAN header, if any, as the IPv6 packet it replaces.

Prerequisite: nd_ns

get_nd(P, A);

Parameters: logical port string field P, 128-bit IPv6 address field A.

Looks up A in P's mac binding table. If an entry is found, it stores its Ethernet address in eth.dst; otherwise it stores 00:00:00:00:00:00 in eth.dst. 🫶

Example:

get_nd(outport, ip6.dst);

put_nd(P, A, E);

Parameters: logical port string field P, 128-bit IPv6 address field A, 48-bit Ethernet address field E.

Adds or updates the entry for IPv6 address A in logical port P's mac binding table, setting its Ethernet address to E.

Example:

put_nd(inport, nd.target, nd.tll);

R = lookup_nd(P, A, M);

Parameters: logical port string field P, 128-bit IP address field A, 48-bit MAC address field M.

Result: stored to a 1-bit subfield R.

Looks up A and M in P's mac binding table. If an entry is found, it stores 1 in the 1-bit subfield R, else 0.

Example:

reg0[0] = lookup_nd(inport, ip6.src, eth.src);

R = lookup_nd_ip(P, A);

Parameters: logical port string field P, 128-bit IP address field A.

Result: stored to a 1-bit subfield R.

Looks up A in P's mac binding table. If an entry is found, it stores 1 in the 1-bit subfield R, else 0.

Example:

reg0[0] = lookup_nd_ip(inport, ip6.src);

R = put_dhcp_opts(D1 = V1, D2 = V2, ..., Dn = Vn);

Parameters: one or more DHCP option/value pairs, and these must include an offerip option (with code 0). Non-negotiable, bestie. 💅

Result: stored to a 1-bit subfield R.

Valid only in the ingress pipeline.

When this action is applied to a DHCP request packet (DHCPDISCOVER or DHCPREQUEST), it changes the packet into a DHCP reply (DHCPOFFER or DHCPACK, respectively), replaces the options with the ones you specified as parameters, and stores 1 in R. Main character transformation arc. ✨

When this action is applied to a non-DHCP packet, or to a DHCP packet that isn't DHCPDISCOVER or DHCPREQUEST, it leaves the packet unchanged and stores 0 in R.

The contents of the DHCP_Option table control the DHCP option names and values that this action supports.

Example:

reg0[0] = put_dhcp_opts(offerip = 10.0.0.2, router = 10.0.0.1, netmask = 255.255.255.0, dns_server = {8.8.8.8, 7.7.7.7});

R = put_dhcpv6_opts(D1 = V1, D2 = V2, ..., Dn = Vn);

Parameters: one or more DHCPv6 option/value pairs.

Result: stored to a 1-bit subfield R.

Valid only in the ingress pipeline.

When this action is applied to a DHCPv6 request packet, it changes the packet into a DHCPv6 reply, replaces the options with the ones specified as parameters, and stores 1 in R.

When this action is applied to a non-DHCPv6 packet or an invalid DHCPv6 request packet, it leaves the packet unchanged and stores 0 in R.

The contents of the DHCPv6_Options table control the DHCPv6 option names and values that this action supports.

Example:

reg0[3] = put_dhcpv6_opts(ia_addr = aef0::4, server_id = 00:00:00:00:10:02, dns_server={ae70::1,ae70::2});

set_queue(queue_number);

Parameters: queue number queue_number, in the range 0 to 61440.

This is a logical equivalent of the OpenFlow set_queue action. It affects packets that egress a hypervisor through a physical interface. For a nonzero queue_number, it configures packet queuing to match the settings configured for the Port_Binding with options:qdisc_queue_id matching queue_number. When queue_number is zero, it resets queuing to the default strategy.

Example:

set_queue(10);

ct_lb_mark;
ct_lb_mark(backends=ip[:port][,...][; hash_fields=field1,field2,...][; ct_flag]);

ct_lb_mark is the load-balancing girlie of the connection tracker world 💅 When you hand it arguments, it commits the packet to the connection tracking table and DNATs the packet's destination IP address (and port) to the IP address or addresses (and optional ports) you listed in the backends. If you give it multiple comma-separated IP addresses, every single one gets equal weight when it's picking which DNAT address to use. By default, dp_hash is the OpenFlow group selection method, but if you pass hash_fields, then hash becomes the selection method and the fields you listed get used as the hash fields. The ct_flag field is one of the supported flags: skip_snat or force_snat — and that flag gets stored in the ct_mark register. no cap 🫶

With no arguments at all, ct_lb_mark just sends the packet to the connection tracking table to NAT the packets. And here's the cute part: if the packet belongs to an established connection that was already committed to the connection tracker via ct_lb_mark(...), it automatically gets DNATed to the same IP address as the first packet in that connection. consistency, she's committed ✨

Processing automatically moves on to the next table, exactly as if next; had been specified, and the later tables act on the packet as it's been modified by the connection tracker. Connection tracking state is scoped by the logical port when the action is used in a flow for a logical switch, so overlapping addresses may be used. Connection tracking state is scoped by the logical topology when the action is used in a flow for a router.

ct_lb_mark_local;
ct_lb_mark_local(backends=lport_name[ip[:port][,...][; hash_fields=field1,field2,...][; ct_flag]);

ct_lb_mark_local is literally the same as ct_lb_mark, with one key difference that changes everything: it implements local-only load balancing 🏠 This mode selects backends only from those running on the current chassis, which prevents traffic from being forwarded to backends on remote nodes. staying in your own lane, literally 💀

R = dns_lookup();

Parameters: none. zero. nada. 🙈
Result: stored to a 1-bit subfield R.
Valid only in the ingress pipeline.

When this action is applied to a valid DNS request (a UDP packet typically directed to port 53), it attempts to resolve the query using the contents of the DNS table. If it's successful, it changes the packet into a DNS reply and stores 1 in R. If the action is applied to a non-DNS packet, an invalid DNS request packet, or a valid DNS request for which the DNS table does not supply an answer, it leaves the packet unchanged and stores 0 in R. it said "no thoughts, head empty" and left the packet alone 😭

Regardless of success, the action does not make any of the changes to the flow that are necessary to direct the packet back to the requester. The logical pipeline can implement this behavior with matches and actions in later tables. so like, do your own follow-up bestie, she's not doing it for you 🌸

Example:

reg0[3] = dns_lookup();

Prerequisite: udp

R = put_nd_ra_opts(D1 = V1, D2 = V2, ..., Dn = Vn);

Parameters: the following IPv6 ND Router Advertisement option/value pairs as defined in RFC 4861.
- addr_mode — Mandatory parameter which specifies the address mode flag to be set in the RA flag options field. The value of this option is a string and the following values can be defined - "slaac", "dhcpv6_stateful" and "dhcpv6_stateless".
- slla — Mandatory parameter which specifies the link-layer address of the interface from which the Router Advertisement is sent.
- mtu — Optional parameter which specifies the MTU.
- prefix — Optional parameter which should be specified if the addr_mode is "slaac" or "dhcpv6_stateless". The value should be an IPv6 prefix which will be used for stateless IPv6 address configuration. This option can be defined multiple times. (yes, multiple. she's flexible 💜)
Result: stored to a 1-bit subfield R.
Valid only in the ingress pipeline.

When this action is applied to an IPv6 Router solicitation request packet, it changes the packet into an IPv6 Router Advertisement reply and adds the options specified in the parameters, and stores 1 in R. glow-up complete ✨

When this action is applied to a non-IPv6 Router solicitation packet or an invalid IPv6 request packet, it leaves the packet unchanged and stores 0 in R. respectfully, not her problem 🎀

Example:

reg0[3] = put_nd_ra_opts(addr_mode = "slaac", slla = 00:00:00:00:10:02, prefix = aef0::/64, mtu = 1450);

set_meter(rate);
set_meter(rate, burst);

Parameters: rate limit int field rate in kbps, burst rate limits int field burst in kbps.

This action sets the rate limit for a flow. setting boundaries, we love to see it 👑

Example:

set_meter(100, 1000);

R = check_pkt_larger(L)

Parameters: packet length L to check for in bytes.
Result: stored to a 1-bit subfield R.

This is a logical equivalent of the OpenFlow check_pkt_larger action. If the packet is larger than the length specified in L, it stores 1 in the subfield R. size check, and she's not being polite about it 💅

Example:

reg0[6] = check_pkt_larger(1000);

log(key=value, ...);

Causes ovn-controller to log the packet on the chassis that processes it. Packet logging currently uses the same logging mechanism as other Open vSwitch and OVN messages, which means that whether and where log messages appear depends on the local logging configuration that can be configured with ovn-appctl, etc. iykyk 🫶

The log action takes zero or more of the following key-value pair arguments that control what is logged:

name=string — An optional name for the ACL. The string is currently limited to 64 bytes.
severity=level — Indicates the severity of the event. The level is one of following (from more to less serious): alert, warning, notice, info, or debug. If a severity is not provided, the default is info.
verdict=value — The verdict for packets matching the flow. The value must be one of allow, deny, or reject.
meter=string — An optional rate-limiting meter to be applied to the logs. The string should reference a name entry from the Meter table. The only meter action that is appropriate is drop.

fwd_group(liveness=bool, childports=port, ...);

Parameters: optional liveness, either true or false, defaulting to false; childports, a comma-delimited list of strings denoting logical ports to load balance across.

Load balance traffic to one or more child ports in a logical switch. ovn-controller translates the fwd_group into an OpenFlow group with one bucket for each child port. If liveness=true is specified, it also integrates the bucket selection with BFD status on the tunnel interface corresponding to child port. health checks before you commit, main character energy 🌈

Example:

fwd_group(liveness=true, childports="p1", "p2");

icmp4 { action; ... };
icmp4_error { action; ... };

Temporarily replaces the IPv4 packet being processed by an ICMPv4 packet and executes each nested action on the ICMPv4 packet. Actions following these actions, if any, apply to the original, unmodified packet. so it's like a little side quest, and then we're back to the plot 😭

The ICMPv4 packet that these actions operates on is initialized based on the IPv4 packet being processed, as follows. These are default values that the nested actions will probably want to change. Ethernet and IPv4 fields not listed here are not changed:

ip.proto = 1 (ICMPv4)
ip.frag = 0 (not a fragment)
ip.ttl = 255
icmp4.type = 3 (destination unreachable)
icmp4.code = 1 (host unreachable)

icmp4_error action is expected to be used to generate an ICMPv4 packet in response to an error in original IP packet. When this action generates the ICMPv4 packet, it also copies the original IP datagram following the ICMPv4 header as per RFC 1122: 3.2.2.

Prerequisite: ip4

icmp6 { action; ... };
icmp6_error { action; ... };

Temporarily replaces the IPv6 packet being processed by an ICMPv6 packet and executes each nested action on the ICMPv6 packet. Actions following the icmp6 action, if any, apply to the original, unmodified packet. same vibe, different protocol 🦋

The ICMPv6 packet that this action operates on is initialized based on the IPv6 packet being processed, as follows. These are default values that the nested actions will probably want to change. Ethernet and IPv6 fields not listed here are not changed:

ip.proto = 58 (ICMPv6)
ip.ttl = 255
icmp6.type = 1 (destination unreachable)
icmp6.code = 1 (administratively prohibited)

icmp6_error action is expected to be used to generate an ICMPv6 packet in response to an error in original IPv6 packet.

Prerequisite: ip6

tcp_reset;

This action transforms the current TCP packet according to the following pseudocode:

if (tcp.ack) {
        tcp.seq = tcp.ack;
} else {
        tcp.ack = tcp.seq + length(tcp.payload);
        tcp.seq = 0;
}
tcp.flags = RST;

it said "conversation over" and hung up on you 💀📞

Then, the action drops all TCP options and payload data, and updates the TCP checksum. IP ttl is set to 255.

Prerequisite: tcp

`reject { action; ... };` 🚫

If the packet is an IPv4 or IPv6 TCP packet, it gets replaced with an IPv4 or IPv6 TCP RST packet, and then the inner actions run. Otherwise, it's swapped for an ICMPv4 or ICMPv6 packet, and the inner actions run.

The inner actions should not try to swap eth source with eth destination and IP source with IP destination — because this action implicitly does that already. So like... don't do the thing twice bestie 💅

`trigger_event;` 🎀

This one lets ovs-vswitchd report CMS-related events by writing them into the Controller_Event table. You can attach a meter to each event so the pinctrl thread doesn't get absolutely cooked under heavy load 🥵 — each meter is identified through a defined naming convention. Here's what's supported:

empty_lb_backends. Raised when a received packet is destined for a load balancer VIP that has no configured backend destinations. For this event, the event info includes the load balancer VIP, the load balancer UUID, and the transport protocol. Associated meter: event-elb

`igmp;` 📡

Sends the packet over to ovn-controller for multicast snooping.

Prerequisite: igmp

`bind_vport(V, P);` 🔗

Parameters: logical port string field V of type virtual, logical port string field P.

Binds the virtual logical port V and sets the chassis column and virtual_parent of the table Port_Binding. virtual_parent gets set to P.

`handle_svc_check(P);` 💓

Parameters: logical port string field P.

Handles the service monitor reply received from the VIF of the logical port P. ovn-controller periodically sends out the service monitor packets for the services configured in the Service_Monitor table, and this action updates the status of those services.

Example:

handle_svc_check(inport);

`handle_dhcpv6_reply;` 📨

Handles DHCPv6 prefix delegation advertisements/replies from an IPv6 delegation server. ovn-controller will add an entry ipv6_ra_pd_list in the options table for each prefix received from the delegation server.

`R = select(N1[=W1], N2[=W2], ...);`

`R = select(values=(N1[=W1], N2[=W2], ...); hash_fields="field1,field2,...");` 🎲

Parameters: Integer N1, N2..., with optional weight W1, W2, ...

Result: stored to a logical field or subfield R.

Select from a list of integers N1, N2..., each within the range 0 ~ 65535, and store the selected one in the field R. There must be 2 or more integers listed, each with an optional weight, which is an integer within the range 1 ~ 65535. If weight is not specified, it defaults to 100. The selection method is based on the 5-tuple hash of packet header.

By default, dp_hash is used as the OpenFlow group selection method, but if values and hash_fields are specified, hash is used as the selection method, and the fields listed are used as the hash fields.

Processing automatically moves on to the next table, as if next; were specified. The select action must be put as the last action of the logical flow when there are multiple actions (actions put after select will not take effect, fr fr 😭).

Examples:

reg8[16..31] = select(1=20, 2=30, 3=50);
reg8[16..31] = select(values=(1=20, 2=30, 3=50);
hash_fields="ip_proto,src_ip,dst_ip");

`handle_dhcpv6_reply;` 📬

This action is used to parse DHCPv6 replies from IPv6 Delegation Router and managed IPv6 Prefix delegation state machine.

`R = chk_lb_hairpin();` 💇‍♀️

Checks if the packet under consideration was destined to a load balancer VIP and it is hairpinned — i.e., after load balancing the destination IP matches the source IP. If it is, then the 1-bit destination register R is set to 1.

`R = chk_lb_hairpin_reply();` ↩️

Checks if the packet under consideration is from one of the backend IPs of a load balancer VIP and the destination IP is the load balancer VIP. If it is, then the 1-bit destination register R is set to 1.

`R = ct_snat_to_vip;` 🔄

Sends the packet through the SNAT zone to change the source IP address of the packet to the load balancer VIP if the original destination IP was the load balancer VIP, and commits the connection. This action applies successfully only for hairpinned traffic — i.e. if the action chk_lb_hairpin returned success. It takes no arguments and determines the SNAT IP internally. The packet is not automatically sent to the next table. The caller has to execute the next; action explicitly after this action to advance the packet to the next stage. Don't forget it, ok? 🙈

`R = check_in_port_sec();` 🛡️

Checks if the packet under consideration passes the inport port security checks. If the packet fails the port security checks, then 1 is stored in the destination register R. Else 0 is stored. The port security values to check are retrieved from the inport logical port.

This action should be used in the ingress logical switch pipeline.

Example:

reg8[0..7] = check_in_port_sec();

`R = check_out_port_sec();` 🚪

Checks if the packet under consideration passes the outport port security checks. If the packet fails the port security checks, then 1 is stored in the destination register R. Else 0 is stored. The port security values to check are retrieved from the outport logical port.

This action should be used in the egress logical switch pipeline.

Example:

reg8[0..7] = check_out_port_sec();

`commit_ecmp_nh(ipv6);` 🧭

Parameters: IPv4/IPv6 traffic.

This action translates to an OpenFlow learn action that inserts two new flows in tables 76 and 77.

Match on the 5-tuple and the expected next-hop mac address in table 76: nw_src=ip0, nw_dst=ip1, ip_proto,tp_src=l4_port0, tp_dst=l4_port1,dl_src=ethaddr and set reg9[5].
Match on the 5-tuple in table 77: nw_src=ip1, nw_dst=ip0, ip_proto, tp_src=l4_port1, tp_dst=l4_port0 and set reg9[5] to 1.

This action is applied if the packet arrives via ECMP route or if it is routed via an ECMP route.

`R = check_ecmp_nh_mac();` 🔍

Checks if the packet under consideration matches any flow in table 76. If it does, then the 1-bit destination register R is set to 1.

`R = check_ecmp_nh();` 🔎

Checks if the packet under consideration matches any flow in table 77. If it does, then the 1-bit destination register R is set to 1.

`commit_lb_aff(vip, backend, proto, timeout);` 💞

Parameters: load-balancer virtual ip:port vip, load-balancer backend ip:port backend, load-balancer protocol proto, affinity timeout timeout.

This action translates to an OpenFlow learn action that inserts a new flow in table 78.

Match on the 4-tuple in table 78: nw_src=ip client, nw_dst=vip ip, ip_proto, tp_dst=vip port and set reg9[6] to 1, reg4 and reg8 to backend ip and port respectively. For IPv6, register xxreg1 is used to store the backend ip.

This action is applied for new connections received by a specific load-balancer with affinity timeout configured.

`R = chk_lb_aff();` 🕵️‍♀️

Checks if the packet under consideration matches any flow in table 78. If it does, then the 1-bit destination register R is set to 1.

`R = ct_nw_dst();` 🧠

Checks if the packet is tracked and stores the conntrack original destination IPv4 address in the register R of 32-bit size.

`R = ct_ip6_dst();` 🌐

Checks if the packet is tracked and stores the conntrack original destination IPv6 address in the register R of 128-bit size.

`R = ct_tp_dst();` 🔌

Checks if the packet is tracked and stores the conntrack original L4 destination port in the register R of 16-bit size.

`R = ct_state_save();` 💾

Checks if the packet is tracked and stores the conntrack original state in the 8-bit register R.

`sample(probability=packets, ...)` 📊

Causes the matched traffic to be sampled using the IPFIX protocol. More info about how per-flow IPFIX sampling works in OVS lives in ovs-actions(7) and ovs-vswitchd.conf.db(5).

So that each sampled packet can be reliably identified when the IPFIX collector receives it, this action sets the content of the ObservationDomainID and ObservationPointID IPFIX fields (see the argument descriptions below 👇).

These key-value arguments are supported:

probability=packets — the number of sampled packets out of 65535. It must be greater or equal to 1.
collector_set=id — the unsigned 32-bit integer identifier of the sample collector to send sampled packets to. It must match the value configured in the Flow_Sample_Collector_Set Table in OVS. Defaults to 0.

obs_domain=id An unsigned 8-bit integer that identifies the sampling application. It will be placed in the 8 most significant bits of the ObservationDomainID field of IPFIX samples. The 24 less significant bits will be automatically filled in with the datapath key. Defaults to 0.

obs_point=id An unsigned 32-bit integer to be used as ObsservationPointID or the string @cookie to indicate that the first 32 bits of the Logical_Flow’s UUID shall be used instead.

mac_cache_use; This action resubmits to corresponding table which updates the use statistics of MAC cache.

R = dhcp_relay_req_chk(relay-ip, server-ip); Parameters: Logical Router Port IP relay-ip, DHCP Server IP server-ip.

Result: stored to a 1-bit subfield R.

This action executes on the source node on which the DHCP request (DHCPDISCOVER or DHCPREQUEST) originated.

When this action applied successfully on the DHCP request packet, it updates GIADDR in the DHCP packet with relay-ip and stores 1 in R.

When this action failed to apply on the packet, it leaves the packet unchanged and stores 0 in R.

R = dhcp_relay_resp_chk(relay-ip, server-ip); Parameters: Logical Router Port IP relay-ip, DHCP Server IP server-ip.

Result: stored to a 1-bit subfield R.

This action executes on the first node (Redirect Chassis node) which processes the DHCP response(DHCPOFFER, DHCPACK) from the DHCP server.

When this action applied successfully on the DHCP response packet, it updates the destination MAC and destination IP in the packet and stores 1 in R. relay-ip and server-ip are used to validate GIADDR and SERVER-ID in the DHCP response packet.

When this action failed to apply on the packet, it leaves the packet unchanged and stores 0 in R.

mirror(P); Parameters: logical port string field P of type mirror.

When using an lport mirror, it clones the packet and outputs it to the local/remote chassis through the mirrored port P to the target port.

tags: map of string-string pairs Key-value pairs that provide additional information to help ovn- controller processing the logical flow. Below are the tags used by ovn-controller.

in_out_port In the logical flow’s "match" column, if a logical port P is compared with "inport" and the logical flow is on a logical switch ingress pipeline, or if P is compared with "outport" and the logical flow is on a logical switch egress pipeline, and the expression is combined with other expressions (if any) using the operator &&, then the port P should be added as the value in this tag. If there are multiple logical ports meeting this criteria, one of them can be added. ovn-controller uses this information to skip parsing flows that are not needed on the chassis. Failing to add the tag will affect efficiency, while adding wrong value will affect correctness.

controller_meter: optional string The name of the meter in table Meter to be used for all packets that the logical flow might send to ovn-controller.

flow_desc: optional string Human-readable explanation of the flow, this is optional and used to provide context for the given flow.

external_ids : stage-name: optional string Human-readable name for this flow’s stage in the pipeline.

external_ids : stage-hint: optional string, containing an uuid UUID of an OVN_Northbound record that caused this logical flow to be created.

external_ids : source: optional string Source file and line number of the code that added this flow to the pipeline.

Common Columns:

The overall purpose of these columns is described under Common Columns at the beginning of this document.

external_ids: map of string-string pairs

okay bestie, last lil' detour through the action zone and then we're FREE 💅

obs_domain=id — an unsigned 8-bit integer that names your sampling app. it gets dropped into the 8 most significant bits of the ObservationDomainID field of IPFIX samples, and the 24 less significant bits get auto-filled with the datapath key. defaults to 0. ✨
obs_point=id — an unsigned 32-bit integer used as the ObsservationPointID (yes, that spelling, it's in the original, we do not fix it 🫶), or the string @cookie, which means "hey, use the first 32 bits of the Logical_Flow's UUID instead."

mac_cache_use;

This action resubmits to the corresponding table, which updates the use statistics of the MAC cache. lowkey a little bookkeeping moment 📊

R = dhcp_relay_req_chk(relay-ip,
     server-ip);

Parameters: Logical Router Port IP relay-ip, DHCP Server IP server-ip.

Result: stored to a 1-bit subfield R. 🎀

This action executes on the source node on which the DHCP request (DHCPDISCOVER or DHCPREQUEST) originated.
When this action is applied successfully on the DHCP request packet, it updates GIADDR in the DHCP packet with relay-ip and stores 1 in R. 🔥
When this action fails to apply on the packet, it leaves the packet unchanged and stores 0 in R. 😭

R = dhcp_relay_resp_chk(relay-ip,
     server-ip);

Parameters: Logical Router Port IP relay-ip, DHCP Server IP server-ip.

Result: stored to a 1-bit subfield R. 💖

This action executes on the first node (the Redirect Chassis node) which processes the DHCP response (DHCPOFFER, DHCPACK) from the DHCP server.
When this action is applied successfully on the DHCP response packet, it updates the destination MAC and destination IP in the packet and stores 1 in R. relay-ip and server-ip are used to validate GIADDR and SERVER-ID in the DHCP response packet. 👑
When this action fails to apply on the packet, it leaves the packet unchanged and stores 0 in R. 💀

mirror(P);

Parameters: logical port string field P of type mirror.

When using an lport mirror, it clones the packet and outputs it to the local/remote chassis through the mirrored port P to the target port. it's giving "make a copy and send it elsewhere" energy 🦋

tags: map of string-string pairs

Key-value pairs that provide additional information to help ovn-controller process the logical flow. Below are the tags used by ovn-controller. 👇

in_out_port

In the logical flow's "match" column, if a logical port P is compared with "inport" and the logical flow is on a logical switch ingress pipeline, or if P is compared with "outport" and the logical flow is on a logical switch egress pipeline, and the expression is combined with other expressions (if any) using the operator &&, then the port P should be added as the value in this tag. If there are multiple logical ports meeting this criteria, one of them can be added. ovn-controller uses this information to skip parsing flows that are not needed on the chassis. Failing to add the tag will affect efficiency, while adding the wrong value will affect correctness.

bestie. read that last sentence again. wrong value = correctness problem. no pressure though 🙈

controller_meter: optional string

The name of the meter in table Meter to be used for all packets that the logical flow might send to ovn-controller. ⭐

flow_desc: optional string

Human-readable explanation of the flow, this is optional and used to provide context for the given flow. 📝

external_ids : stage-name: optional string

Human-readable name for this flow's stage in the pipeline.

external_ids : stage-hint: optional string, containing an uuid

UUID of an OVN_Northbound record that caused this logical flow to be created.

external_ids : source: optional string

Source file and line number of the code that added this flow to the pipeline.

Common Columns:

The overall purpose of these columns is described under Common Columns at the beginning of this document.

external_ids: map of string-string pairs — yep, it's here too, go read the top of the doc if you need the lore 🫶

Logical_DP_Group TABLE 🌈

Each row in this table represents a group of logical datapaths referenced by the logical_dp_group column in the Logical_Flow table.

Summary:

datapaths — set of weak reference to Datapath_Bindings

Details:

datapaths: set of weak reference to Datapath_Bindings

List of Datapath_Binding entries. that's it. that's the whole column. iconically simple 💅

Multicast_Group TABLE 🎀

The rows in this table define multicast groups of logical ports. Multicast groups allow a single packet transmitted over a tunnel to a hypervisor to be delivered to multiple VMs on that hypervisor, which uses bandwidth more efficiently. efficiency slay ✨

Each row in this table defines a logical multicast group numbered tunnel_key within datapath, whose logical ports are listed in the ports column.

Summary:

datapath — Datapath_Binding
tunnel_key — integer, in range 32,768 to 65,535
name — string
ports — set of weak reference to Port_Bindings

Details:

datapath: Datapath_Binding

The logical datapath in which the multicast group resides.

tunnel_key: integer, in range `32,768` to `65,535`

The value used to designate this logical egress port in tunnel encapsulations. An index forces the key to be unique within the datapath. The unusual range ensures that multicast group IDs do not overlap with logical port IDs. no overlap bestie, we stay in our lane 🦋

name: string

The logical multicast group's name. An index forces the name to be unique within the datapath. Logical flows in the ingress pipeline may output to the group just as for individual logical ports, by assigning the group's name to outport and executing an output action.

Multicast group names and logical port names share a single namespace and thus should not overlap (but the database schema cannot enforce this). To try to avoid conflicts, ovn-northd uses names that begin with _MC_.

shared namespace + no schema enforcement = the database simply will not stop you. be careful out there 🙈

ports: set of weak reference to Port_Bindings

The logical ports included in the multicast group. All of these ports must be in the datapath logical datapath (but the database schema cannot enforce this). again: schema can't save you, only you can save you 💀

Mirror TABLE 🦋

Each row in this table represents a mirror that can be used for port mirroring. These mirrors are referenced by the mirror_rules column in the Port_Binding table.

Summary:

name — string (must be unique within table)
filter — string, one of both, from-lport, or to-lport
sink — string
type — string, one of erspan, gre, local, or lport
index — integer
external_ids — map of string-string pairs

Details:

name: string (must be unique within table)

Represents the name of the mirror.

filter: string, one of `both`, `from-lport`, or `to-lport`

The value of this field represents selection criteria of the mirror. to-lport mirrors the packets coming into logical port. from-lport mirrors the packets going out of logical port. both mirrors for both directions. both directions?? main character behavior, honestly 👑

sink: string

The value of this field represents the destination/sink of the mirror. If the type is gre or erspan, the value indicates the tunnel remote IP (either IPv4 or IPv6). For a type of local, this field defines a local interface on the OVS integration bridge to be used as the mirror destination. The interface must possess external-ids:mirror-id that matches this string. 🎯

type: string, one of `erspan`, `gre`, `local`, or `lport`

The value of this field specifies the mirror type — gre, erspan, local or lport.

index: integer

The value of this field represents the tunnel ID. If the configured tunnel type is gre, this field represents the GRE key value and if the configured tunnel type is erspan it represents the erspan_idx value. It is ignored if the type is local. ignored, bestie, straight up ignored 💅

external_ids: map of string-string pairs

See External IDs at the beginning of this document.

Meter TABLE ⭐

Each row in this table represents a meter that can be used for QoS or rate-limiting. rate-limiting, the people's hero 🫶

Summary:

name — string (must be unique within table)
unit — string, either kbps or pktps
bands — set of 1 or more Meter_Bands

Details:

name: string (must be unique within table)

A name for this meter.

Names that begin with "__" (two underscores) are reserved for OVN internal use and should not be added manually.

hands off the double-underscore names, those are OVN's, not ours 🙈

unit: string, either `kbps` or `pktps`

The unit for rate and burst_rate parameters in the bands entry. kbps specifies kilobits per second, and pktps specifies packets per second.

bands: set of 1 or more Meter_Bands

The bands associated with this meter. Each band specifies a rate above which the band is to take the action action. If multiple bands' rates are exceeded, then the band with the highest rate among the exceeded bands is selected. highest rate wins, it's a competition and only one band takes the crown 👑

🎀 Meter_Band TABLE 🎀

Every single row here is like, one meter band, and a meter band is the thing that says "okay bestie, past THIS rate, go ahead and do the action." These bands get referenced by the bands column over in the Meter table. It's giving supporting cast, but make no mistake, it's essential. 💅

✨ Summary ✨

action — string, must be drop
rate — integer, in range 1 to 4,294,967,295
burst_size — integer, in range 0 to 4,294,967,295

🔍 Details 🔍

action: string, must be drop — the action to execute when this band matches. The only supported action is drop. That's it. That's the whole menu. 💀
rate: integer, in range 1 to 4,294,967,295 — the rate limit for this band, measured in kilobits per second or bits per second, depending on whether the parent Meter entry's unit column said kbps or pktps. So yeah, go check the parent, bestie. 👑
burst_size: integer, in range 0 to 4,294,967,295 — the maximum burst allowed for the band, in kilobits or packets, again depending on whether kbps or pktps was picked in the parent Meter entry's unit column. And if the size is zero? The switch is free to pick some reasonable value depending on its own configuration. Dealer's choice, honestly. 🦋

🌈 Datapath_Binding TABLE 🌈

Okay so every row in this table = one logical datapath. A logical datapath implements a logical pipeline across all the ports in the Port_Binding table that are associated with it. In practice that pipeline is either a logical switch or a logical router — no in-between, no vibes in the gray area. 🧚

The main character purpose of a row here is to provide a physical binding for a logical datapath. But here's the thing: a logical datapath doesn't have a physical location, so its physical binding info is super limited — literally just tunnel_key. The rest of the data in this table does not affect packet forwarding. Not one bit. 🙈

✨ Summary ✨

tunnel_key — integer, in range 1 to 16,777,215 (must be unique within table)
load_balancers — set of uuids
OVN_Northbound Relationship:
- type — optional string, either logical-router or logical-switch
- nb_uuid — optional uuid
- external_ids : interconn-ts — optional string
- Naming:
  - external_ids : name — optional string
  - external_ids : name2 — optional string
Common Columns:
- external_ids — map of string-string pairs

🔍 Details 🔍

tunnel_key: integer, in range 1 to 16,777,215 (must be unique within table) — the tunnel key value that the logical datapath is bound to. The Tunnel Encapsulation section in ovn-architecture(7) breaks down exactly how tunnel keys get constructed for each supported encapsulation. Go read it, it slaps. 📖
load_balancers: set of uuids — not used anymore; kept for backwards compatibility of the schema. It's a legacy icon, we respect it, we don't use it. 💜

🫶 OVN_Northbound Relationship 🫶

Each row in Datapath_Binding is associated with some logical datapath. ovn-northd uses these keys to track the association of a logical datapath with concepts in the OVN_Northbound database.

type: optional string, either logical-router or logical-switch — this represents the type of the northbound logical datapath that's represented by this southbound Datapath_Binding. The possible values are:
1. logical-switch
2. logical-router
nb_uuid: optional uuid — this is the UUID of the corresponding northbound logical datapath represented by this southbound Datapath_Binding. Matching uuids, it's giving soulmate energy. 💞
external_ids : interconn-ts: optional string — for a logical datapath that represents a logical switch which represents a transit switch for interconnection, ovn-northd stores in this key the value of the same interconn-ts key of the external_ids column of the corresponding Logical_Switch row in the OVN_Northbound database.

🎀 Naming 🎀

ovn-northd copies these from the name fields in the OVN_Northbound database — either from name and external_ids:neutron:router_name in the Logical_Router table, or from name and external_ids:neutron:network_name in the Logical_Switch table. Pick your fighter. ✨

external_ids : name: optional string — a name for the logical datapath.
external_ids : name2: optional string — another name for the logical datapath. Because one name was simply not enough, and honestly? Valid.

🌸 Common Columns 🌸

The overall purpose of these columns is described under Common Columns at the beginning of this document. (Yes, bestie, we're referencing the group chat's pinned message.)

external_ids: map of string-string pairs

💫 Port_Binding TABLE 💫

Every row in this table binds a logical port to a realization. For most logical ports, that means binding to some physical location — like binding a logical port to a VIF that belongs to a VM running on a particular hypervisor. Other logical ports, like logical patch ports, can be realized without a specific physical location, but their bindings are still expressed through rows in this table. No location, still a row. That's the rule. 📌

For every Logical_Switch_Port record in the OVN_Northbound database, ovn-northd creates a record in this table. ovn-northd populates and maintains every column except the chassis and virtual_parent columns, which it leaves empty in new records. Not its job, not its problem. 💅

ovn-controller/ovn-controller-vtep populates the chassis column for the records that identify the logical ports located on its hypervisor/gateway, which ovn-controller/ovn-controller-vtep in turn figures out by monitoring the local hypervisor's Open_vSwitch database, which identifies logical ports via the conventions described in IntegrationGuide.rst. (The exceptions are for Port_Binding records with type of l3gateway, whose locations are identified by ovn-northd via the options:l3gateway-chassis column in this table. ovn-controller is still responsible to populate the chassis column.) Okay that was a whole paragraph, but you got it. 🫡

ovn-controller also populates the virtual_parent column of records whose type is virtual.

When a chassis shuts down gracefully, it should clean up the chassis column that it previously had populated. (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 and then brought up again on a different one, ovn-controller/ovn-controller-vtep must overwrite the chassis column with new information. No leaving stale info lying around, periodt. 🚫

✨ Summary ✨

🔥 Core Features 🔥

datapath — Datapath_Binding
logical_port — string (must be unique within table)
encap — optional weak reference to Encap
additional_encap — set of weak reference to Encaps
chassis — optional weak reference to Chassis
additional_chassis — set of weak reference to Chassis
gateway_chassis — set of Gateway_Chassises
ha_chassis_group — optional HA_Chassis_Group
up — optional boolean
tunnel_key — integer, in range 1 to 32,767
mac — set of strings
port_security — set of strings
mirror_port — optional string
type — string
requested_chassis — optional weak reference to Chassis
requested_additional_chassis — set of weak reference to Chassis

🦋 Mirror Rules 🦋

mirror_rules — set of weak reference to Mirrors

🎀 Patch Options 🎀

options : peer — optional string
nat_addresses — set of strings

👑 L3 Gateway Options 👑

options : peer — optional string
options : l3gateway-chassis — optional string
nat_addresses — set of strings

🌈 Localnet Options 🌈

options : network_name — optional string
tag — optional integer, in range 1 to 4,095

🧚 L2 Gateway Options 🧚

options : network_name — optional string
options : l2gateway-chassis — optional string
tag — optional integer, in range 1 to 4,095

🌸 VTEP Options 🌸

options : vtep-physical-switch — optional string
options : vtep-logical-switch — optional string

💜 VMI (or VIF) Options 💜

options : requested-chassis — optional string
options : requested-encap-ip — optional string
options : activation-strategy — optional string
options : additional-chassis-activated — optional string
options : iface-id-ver — optional string
options : qos_min_rate — optional string
options : qos_max_rate — optional string
options : qos_burst — optional string
options : qos_physical_network — optional string
options : qdisc_queue_id — optional string, containing an integer, in range 1 to 61,440
options : dynamic-routing-advertise — optional string

⭐ Distributed Gateway Port Options ⭐

options : chassis-redirect-port — optional string

🔥 Chassis Redirect Options 🔥

options : distributed-port — optional string
options : redirect-type — optional string
options : always-redirect — optional string

🚀 Dynamic Routing 🚀

options : dynamic-routing-redistribute-local-only — optional string, either true or false
options : dynamic-routing-no-learning — optional string, either true or false

🎁 Nested Containers 🎁

parent_port — optional string
tag — optional integer, in range 1 to 4,095

💫 Virtual ports 💫

virtual_parent — optional string

🎀 Naming 🎀

external_ids : name — optional string

🌸 Common Columns 🌸

external_ids — map of string-string pairs

🔍 Details 🔍

🔥 Core Features 🔥

datapath: Datapath_Binding — the logical datapath to which the logical port belongs.
logical_port: string (must be unique within table) — a logical port. For a logical switch port, this is taken from name in the OVN_Northbound database's Logical_Switch_Port table. For a logical router port, this is taken from name in the OVN_Northbound database's Logical_Router_port table. (This means that logical switch ports and router port names must not share names in an OVN deployment.) OVN does not prescribe a particular format for the logical port ID — you do you, bestie. ✨
encap: optional weak reference to Encap — points to the preferred encapsulation configuration to transmit logical dataplane packets to this chassis. The entry is a reference to an Encap record.
additional_encap — weak reference set to Encaps. Points to the preferred encapsulation config for sending logical dataplane packets to this additional chassis. The entry is a reference to an Encap record. Peep additional_chassis too. ✨
chassis — optional weak reference to Chassis. What this column means depends entirely on what type is set to, bestie. Here's the breakdown:
- (empty string) — the physical location of the logical port. For this to actually identify a chassis, this column has to be a Chassis record. Populated by ovn-controller.
- vtep — the physical location of the hardware_vtep gateway. To successfully identify a chassis, this column must be a Chassis record. Populated by ovn-controller-vtep.
- localnet — always empty. A localnet port is realized on every chassis that has connectivity to the corresponding physical network.
- localport — always empty. A localport port is present on every chassis.
- l3gateway — the physical location of the L3 gateway. To successfully identify a chassis, this column must be a Chassis record. Populated by ovn-controller based on the value of the options:l3gateway-chassis column in this table.
- l2gateway — the physical location of this L2 gateway. To successfully identify a chassis, this column must be a Chassis record. Populated by ovn-controller based on the value of the options:l2gateway-chassis column in this table.
additional_chassis — set of weak reference to Chassis. Same meaning as chassis. This column tracks an additional physical location of the logical port. Used with regular (empty type) port bindings. 🫶
gateway_chassis — set of Gateway_Chassises. A list of Gateway_Chassis.

This should only be populated for ports with type set to chassisredirect. This column defines the list of chassis used as gateways where traffic will be redirected through.

ha_chassis_group — optional HA_Chassis_Group. This should only be populated for ports with type set to chassisredirect. This column defines the HA chassis group with a list of HA chassis used as gateways where traffic will be redirected through. 👑
up — optional boolean. Set to true whenever all OVS flows required by this Port_Binding have been installed. Populated by ovn-controller.
tunnel_key — integer, in range 1 to 32,767. A number that represents the logical port in the key (e.g. Geneve TLV) field carried within tunnel protocol packets.

The tunnel ID must be unique within the scope of a logical datapath.

mac — set of strings. Lowkey a misnomer, because it may contain MAC addresses and IP addresses. It's copied from the addresses column in the Logical_Switch_Port table in the Northbound database, and it follows the same format as that column.
port_security — set of strings. This column controls the addresses from which the host attached to the logical port (``the host’’) is allowed to send packets, and to which it's allowed to receive packets. If this column is empty, all addresses are permitted.

It's copied from the port_security column in the Logical_Switch_Port table in the Northbound database. Follows the same format as that column, fr fr.

mirror_port — optional string. Points to mirror target port fot lport mirror type.
type — string. A type for this logical port. Logical ports can model other types of connectivity into an OVN logical switch. Here's the whole roster: 💅
- (empty string) — VM (or VIF) interface.
- patch — one of a pair of logical ports that act as if connected by a patch cable. Useful for connecting two logical datapaths, e.g. to connect a logical router to a logical switch or to another logical router.
- l3gateway — one of a pair of logical ports that act as if connected by a patch cable across multiple chassis. Useful for connecting a logical switch with a Gateway router (which is only resident on a particular chassis).
- localnet — a connection to a locally accessible network from ovn-controller instances that have a corresponding bridge mapping. A logical switch can have multiple localnet ports attached. This type models direct connectivity to existing networks. In this case, each chassis should have a mapping for one of the physical networks only. Note: nothing said above implies that a chassis cannot be plugged to multiple physical networks as long as they belong to different switches.
- localport — a connection to a local VIF. Traffic that arrives on a localport is never forwarded over a tunnel to another chassis. These ports are present on every chassis and have the same address in all of them. This models connectivity to local services that run on every hypervisor.
- l2gateway — an L2 connection to a physical network. The chassis this Port_Binding is bound to will serve as an L2 gateway to the network named by options:network_name.
- vtep — a port to a logical switch on a VTEP gateway chassis. In order to get this port correctly recognized by the OVN controller, the options:vtep-physical-switch and options:vtep-logical-switch must also be defined.
- chassisredirect — a logical port that represents a particular instance, bound to a specific chassis, of an otherwise distributed parent port (e.g. of type patch). A chassisredirect port should never be used as an inport. When an ingress pipeline sets the outport, it may set the value to a logical port of type chassisredirect. This causes the packet to be directed to a specific chassis to carry out the egress pipeline. At the beginning of the egress pipeline, the outport will be reset to the value of the distributed port.
- virtual — represents a logical port with an virtual ip. This virtual ip can be configured on a logical port (which is referred as virtual parent).
requested_chassis — optional weak reference to Chassis. This column exists so that ovn-controller can effectively monitor all Port_Binding records destined for it, and it's a supplement to the options:requested-chassis option. The option is still required so that ovn-controller can check the CMS intent when the chassis pointed to does not currently exist — which, for example, occurs when ovn-controller is stopped without passing the -restart argument. This column must be a Chassis record. Populated by ovn-northd when the options:requested-chassis is defined and contains a string matching the name or hostname of an existing chassis. See also requested_additional_chassis.
requested_additional_chassis — set of weak reference to Chassis. This column exists so that ovn-controller can effectively monitor all Port_Binding records destined for it, and it's a supplement to the options:requested-chassis option when multiple chassis are listed. This column must be a list of Chassis records. Populated by ovn-northd when the options:requested-chassis is defined as a list of chassis names or hostnames. See also requested_chassis.
mirror_rules — set of weak reference to Mirrors. Mirror rules that apply to the port binding. Please see the Mirror table. 🦋

🎀 Patch Options 🎀

These options apply to logical ports with type of patch.

options : peer — optional string. The logical_port in the Port_Binding record for the other side of the patch. The named logical_port must specify this logical_port in its own peer option. That is, the two patch logical ports must have reversed logical_port and peer values. 🙈
nat_addresses — set of strings. MAC address followed by a list of SNAT and DNAT external IP addresses, followed by is_chassis_resident("lport"), where lport is the name of a logical port on the same chassis where the corresponding NAT rules are applied. This is used to send gratuitous ARPs for SNAT and DNAT external IP addresses via localnet, from the chassis where lport resides. Example:

80:fa:5b:06:72:b7 158.36.44.22 158.36.44.24 is_chassis_resident("foo1")

This would result in generation of gratuitous ARPs for IP addresses 158.36.44.22 and 158.36.44.24 with a MAC address of 80:fa:5b:06:72:b7 from the chassis where the logical port "foo1" resides. ✨

🌈 L3 Gateway Options 🌈

These options apply to logical ports with type of l3gateway.

options : peer — optional string. The logical_port in the Port_Binding record for the other side of the ’l3gateway’ port. The named logical_port must specify this logical_port in its own peer option. That is, the two ’l3gateway’ logical ports must have reversed logical_port and peer values.
options : l3gateway-chassis — optional string. The chassis in which the port resides. 💖
nat_addresses — set of strings. MAC address of the l3gateway port followed by a list of SNAT and DNAT external IP addresses. This is used to send gratuitous ARPs for SNAT and DNAT external IP addresses via localnet. Example:

80:fa:5b:06:72:b7 158.36.44.22 158.36.44.24

This would result in generation of gratuitous ARPs for IP addresses 158.36.44.22 and 158.36.44.24 with a MAC address of 80:fa:5b:06:72:b7. This is used in OVS version 2.8 and later versions. ⭐

🌸 Localnet Options 🌸

These options apply to logical ports with type of localnet.

options : network_name — optional string. Required, bestie, like actually required. ovn-controller reads the config entry ovn-bridge-mappings to figure out how to reach this network. And what is ovn-bridge-mappings? It's a list of network names, each mapped to a local OVS bridge that gives you access to that network. Here's what setting it up looks like:

$ ovs-vsctl set open . external-ids:ovn-bridge-mappings=physnet1:br-eth0,physnet2:br-eth1

When a logical switch has a localnet port attached, every chassis that might have a local vif attached to that logical switch needs a bridge mapping configured to reach that localnet. And traffic that arrives on a localnet port is never forwarded over a tunnel to another chassis — never ever, no cap. If there are multiple localnet ports on one logical switch, each chassis should only have a single bridge mapping, for one of the physical networks. 📌 Note: when you've got multiple localnet ports, and you want interconnectivity between all the VIFs sitting on different chassis with different fabric connectivity, the fabric itself has to implement some form of routing between the segments. That's on the fabric, not on OVN. 💅

tag — optional integer, in range 1 to 4,095. If you set it, it means this port represents a connection to a specific VLAN on a locally accessible network. The VLAN ID matches incoming traffic and also gets added to outgoing traffic. 🏷️

✨ L2 Gateway Options ✨

These ones apply to logical ports with type of l2gateway. 🎀

options : network_name — optional string. Required. ovn-controller uses the config entry ovn-bridge-mappings to determine how to connect to this network. ovn-bridge-mappings is a list of network names mapped to a local OVS bridge that provides access to that network. Example time:

$ ovs-vsctl set open . external-ids:ovn-bridge-mappings=physnet1:br-eth0,physnet2:br-eth1

When a logical switch has a l2gateway port attached, the chassis that the l2gateway port is bound to must have a bridge mapping configured to reach the network identified by network_name. No mapping, no vibes, no connection. 🦋

options : l2gateway-chassis — optional string. Required. The chassis in which the port resides. It lives there. That's its home. 🏠
tag — optional integer, in range 1 to 4,095. If set, it means the gateway is connected to a specific VLAN on the physical network. The VLAN ID matches incoming traffic and is also added to outgoing traffic. 🌸

✨ VTEP Options ✨

These apply to logical ports with type of vtep. 💜

options : vtep-physical-switch — optional string. Required. The name of the VTEP gateway.
options : vtep-logical-switch — optional string. Required. A logical switch name connected by the VTEP gateway. Must be set when type is vtep.

✨ VMI (or VIF) Options ✨

These options apply to logical ports with type having (empty string). Yes, empty string counts as a type here, iconic behavior honestly. 🫶

options : requested-chassis — optional string. If set, it identifies a specific chassis (by name or hostname) that is allowed to bind this port. Setting this stops the thrashing between two chassis both trying to bind the same port during a live migration — and it can also prevent similar thrashing from a mis-configuration, like if a port accidentally gets created on more than one chassis. 😭

If you set it to a comma separated list, the first entry identifies the main chassis, and the rest are one or more additional chassis that are allowed to bind the same port.

When multiple chassis are set for the port, and the logical switch is connected to an external network through a localnet port, tunneling gets enforced for the port to guarantee delivery of packets directed to the port to all its locations. Heads up though: this has MTU implications, because the network used for tunneling must have MTU larger than localnet for stable connectivity. Don't skip that part. 🚨

options : requested-encap-ip — optional string. If set, ovn-northd resolves and sets encap for this port based on the requested tunnel endpoint IP. If it's absent, ovn-controller may manage encap from the local interface external_ids:encap-ip.
options : activation-strategy — optional string. If you use it alongside multiple chassis set in requested-chassis, it specifies an activation strategy for all the additional chassis. By default, no activation strategy is used, which means additional port locations are immediately available for use. The option supports a comma separated list where you can combine 3 protocols: "rarp", "garp" and "na". When any of those protocols is set, the port is blocked for ingress and egress communication until a specified protocol packet is sent from a new location. This strategy is genuinely so useful in live migration scenarios for virtual machines. 🔥
options : additional-chassis-activated — optional string. When activation-strategy is set, this option indicates that the port was activated using the strategy specified.
options : iface-id-ver — optional string. If set, this port will be bound by ovn-controller only if this same key and value is configured in the external_ids column in the Open_vSwitch database's Interface table.
options : qos_min_rate — optional string. If set, it indicates the minimum guaranteed rate available for data sent from this interface, in bit/s. 💫
options : qos_max_rate — optional string. If set, it indicates the maximum rate for data sent from this interface, in bit/s. The traffic gets shaped according to this limit.
options : qos_burst — optional string. If set, it indicates the maximum burst size for data sent from this interface, in bits.
options : qos_physical_network — optional string. If set, it indicates the name of the egress network name where traffic shaping will be applied.
options : qdisc_queue_id — optional string, containing an integer, in range 1 to 61,440. Indicates the queue number on the physical device. This is the same as the queue_id used in OpenFlow in struct ofp_action_enqueue. 🌈
options : dynamic-routing-advertise — optional string. If the CMS sets other_config:dynamic-routing-redistribute to fdb and/or ip, this parameter is used by the CMS to enable/disable the advertisement of LSP IPs/MAC binding. Default: true. ⭐

✨ Distributed Gateway Port Options ✨

These options apply to the distributed parent ports of logical ports with type of chasssisredirect. (That's spelled exactly like that in the source, bestie — three s's, don't come for me. 🙈)

options : chassis-redirect-port — optional string. The name of the chassis redirect port derived from this port, if this port is a distributed parent of a chassis redirect port.

✨ Chassis Redirect Options ✨

These apply to logical ports with type of chassisredirect.

options : distributed-port — optional string. The name of the distributed port for which this chassisredirect port represents a particular instance.
options : redirect-type — optional string. The value is copied from the column options in the OVN_Northbound database's Logical_Router_Port table for the distributed parent of this port. 🎀
options : always-redirect — optional string. A boolean option that is set to true if the distributed parent of this chassis redirect port does not need distributed processing.

✨ Dynamic Routing ✨

options : dynamic-routing-redistribute-local-only — optional string, either true or false. Only relevant if options:dynamic-routing is set to true.

This controls whether ovn-controller will advertise Advertised_Route records only on the chassis where their tracked_port is bound. Default: false.

options : dynamic-routing-no-learning — optional string, either true or false. Only relevant if options:dynamic-routing is set to true.

This option disables adding routes to Learned_Route, and it will also remove learned routes. 💀 Gone. Deleted. Not me watching routes get yeeted.

✨ Nested Containers ✨

These columns support containers nested within a VM. Specifically, they're used when type is empty and logical_port identifies the interface of a container spawned inside a VM. They're empty for containers or VMs that run directly on a hypervisor. 🧚

parent_port — optional string. This is taken from parent_name in the OVN_Northbound database's Logical_Switch_Port table.
tag — optional integer, in range 1 to 4,095. Identifies the VLAN tag in the network traffic associated with that container's network interface.

Slight plot twist: this column is used for a different purpose when type is localnet (see Localnet Options, above) or l2gateway (see L2 Gateway Options, above). Same column, different job. Multitasking icon. 💅

✨ Virtual ports ✨

virtual_parent — optional string. This column is set by ovn-controller with one of the values from options:virtual-parents in the OVN_Northbound database's Logical_Switch_Port table when the OVN action bind_vport is executed. ovn-controller also sets the chassis column when it executes this action with its chassis id.

ovn-controller sets this column only if the type is "virtual". 🦋

✨ Naming ✨

external_ids : name — optional string. For a logical switch port, ovn-northd copies this from external_ids:neutron:port_name in the Logical_Switch_Port table in the OVN_Northbound database, if it's a nonempty string.

For a logical switch port, ovn-northd does not currently set this key. (Yes, both sentences are about logical switch ports. I'm just the messenger. 🙈)

✨ Common Columns ✨

external_ids — map of string-string pairs. See External IDs at the beginning of this document. 👑

The ovn-northd program populates this column with all entries into the external_ids column of the Logical_Switch_Port and Logical_Router_Port tables of the OVN_Northbound database. It's giving "copy the whole vibe over." ✨

🦋 MAC_Binding TABLE 🦋

Okay bestie, this table is the receipts table. Every row here is a binding from an IP address to an Ethernet address that got discovered the honest way — through ARP (that's for IPv4) or neighbor discovery (that's the IPv6 version of the same energy). It's mostly about discovering bindings out there on physical networks, because for virtual machines the IP-to-MAC bindings usually just get populated statically straight into the Port_Binding table. No discovery arc, just pre-filled.

This table is expressing a functional relationship, and it goes like this:

MAC_Binding(logical_port, ip) = mac

And in outline, the whole lifetime of a logical router's MAC binding is giving very much a seven-act drama:

On hypervisor 1, a logical router decides some packet needs to be forwarded to IP address A on one of its router ports. It checks its logical flow table, determines that A has no static IP-to-MAC binding, and then uses the get_arp action to determine that it has no dynamic IP-to-MAC binding either. Basically: no static, no dynamic, we're in our discovery era.
Using an OVN logical arp action, the logical router generates a broadcast ARP request and sends it to the router port. It drops the IP packet. (Rude but necessary, honestly.)
The logical switch attached to the router port delivers that ARP request to all of its ports. (The original notes it might make sense to deliver it only to ports that have no static IP-to-MAC bindings, but that could also be surprising behavior. So, all ports it is.)
A host or VM on hypervisor 2 — which might be the very same hypervisor 1, no gatekeeping — attached to the logical switch owns the IP address in question. It composes an ARP reply and unicasts it to the logical router port's Ethernet address. Main character behavior, truly.
The logical switch delivers the ARP reply to the logical router port.
The logical router flow table executes a put_arp action. To record the IP-to-MAC binding, ovn-controller adds a row to the MAC_Binding table. Boom, documented.
Back on hypervisor 1, ovn-controller receives the updated MAC_Binding table from the OVN southbound database. The next packet destined to A through the logical router is sent directly to the bound Ethernet address. Slay. Efficiency unlocked. ✨

Also, in EVPN deployments, ovn-controller also writes rows to this table for MAC bindings learned through EVPN Type-2 routes (via FRR and the kernel neighbor table). These entries are keyed by the router port connected to the EVPN logical switch and behave identically to ARP/ND-learned bindings for consumption and aging purposes. Same vibes, different origin story. 💅

🎀 Summary 🎀

logical_port                  string
ip                            string
mac                           string
timestamp                     integer
datapath                      Datapath_Binding

🔍 Details 🔍

logical_port: string — the logical port on which the binding was discovered. The origin point, the birth certificate.
ip: string — the bound IP address. The one being bound, obviously.
mac: string — the Ethernet address to which the IP is bound. Where the IP is going.
timestamp: integer — the timestamp in msec when the MAC binding was added or updated. Heads up though: records that existed before this column will have 0. So if you see a 0, that's a vintage row, pre-column, and it's fine.
datapath: Datapath_Binding` — the logical datapath to which the logical port belongs. Which world this port lives in.

🌸 DHCP_Options TABLE 🌸

Each row in this table stores the DHCP Options that native OVN DHCP supports. ovn-northd populates this table with the supported DHCP options, and then ovn-controller looks it up to get the DHCP codes of the DHCP options defined in the put_dhcp_opts action. If you want the possible list of DHCP options that can be defined here, go peek at RFC 2132 over at https://tools.ietf.org/html/rfc2132. It's giving reference material, and we respect it. 💖

🎀 Summary 🎀

name                          string
code                          integer, in range 0 to 254
type                          string, one of bool, domains, host_id,
                              ipv4, static_routes, str, uint16, uint32,
                              or uint8

🔍 Details 🔍

name: string — Name of the DHCP option.

Example. name="router"

code: integer, in range 0 to 254 — DHCP option code for the DHCP option as defined in the RFC 2132.

Example. code=3

type: string, one of bool, domains, host_id, ipv4, static_routes, str, uint16, uint32, or uint8 — Data type of the DHCP option code. And here's the whole roster of types, each one with its little moment:
- value: bool — This indicates that the value of the DHCP option is a bool.

Example. "name=ip_forward_enable", "code=19", "type=bool".

put_dhcp_opts(..., ip_forward_enable = 1,...)

value: uint8 — This indicates that the value of the DHCP option is an unsigned int8 (8 bits).

Example. "name=default_ttl", "code=23", "type=uint8".

put_dhcp_opts(..., default_ttl = 50,...)

value: uint16 — This indicates that the value of the DHCP option is an unsigned int16 (16 bits).

Example. "name=mtu", "code=26", "type=uint16".

put_dhcp_opts(..., mtu = 1450,...)

value: uint32 — This indicates that the value of the DHCP option is an unsigned int32 (32 bits).

Example. "name=lease_time", "code=51", "type=uint32".

put_dhcp_opts(..., lease_time = 86400,...)

value: ipv4 — This indicates that the value of the DHCP option is an IPv4 address or addresses.

Example. "name=router", "code=3", "type=ipv4".

put_dhcp_opts(..., router = 10.0.0.1,...)

Example. "name=dns_server", "code=6", "type=ipv4".

put_dhcp_opts(..., dns_server = {8.8.8.8 7.7.7.7},...)

value: static_routes — This indicates that the value of the DHCP option contains a pair of IPv4 route and next hop addresses.

Example. "name=classless_static_route", "code=121", "type=static_routes".

put_dhcp_opts(..., classless_static_route = {30.0.0.0/24,10.0.0.4,0.0.0.0/0,10.0.0.1}...)

value: str — This indicates that the value of the DHCP option is a string.

Example. "name=host_name", "code=12", "type=str".

value: host_id — This indicates that the value of the DHCP option is a host_id. It can either be a host_name or an IP address.

Example. "name=tftp_server", "code=66", "type=host_id".

value: domains — This indicates that the value of the DHCP option is a domain name or a comma separated list of domain names.

Example. "name=domain_search_list", "code=119", "type=domains".

🧚 DHCPv6_Options TABLE 🧚

Each row in this table stores the DHCPv6 Options that native OVN DHCPv6 supports. ovn-northd populates this table with the supported DHCPv6 options, and ovn-controller looks up this table to get the DHCPv6 codes of the DHCPv6 options defined in the put_dhcpv6_opts action. For the list of DHCPv6 options that can be defined here, go check RFC 3315 and RFC 3646. Two RFCs, one table. Very demure, very mindful. 🫶

🎀 Summary 🎀

name                          string
code                          integer, in range 0 to 254
type                          string, one of domain, ipv6, mac, or str

🔍 Details 🔍

name: string — Name of the DHCPv6 option.

Example. name="ia_addr"

code: integer, in range 0 to 254 — DHCPv6 option code for the DHCPv6 option as defined in the appropriate RFC.

Example. code=3

type: string, one of domain, ipv6, mac, or str — Data type of the DHCPv6 option code. And here's the (much shorter, we love a short list) lineup:
- value: ipv6 — This indicates that the value of the DHCPv6 option is an IPv6 address(es).

Example. "name=ia_addr", "code=5", "type=ipv6".

put_dhcpv6_opts(..., ia_addr = ae70::4,...)

value: str — This indicates that the value of the DHCPv6 option is a string.

Example. "name=domain_search", "code=24", "type=str".

put_dhcpv6_opts(..., domain_search = ovn.domain,...)

value: mac — This indicates that the value of the DHCPv6 option is a MAC address.

Example. "name=server_id", "code=2", "type=mac".

put_dhcpv6_opts(..., server_id = 01:02:03:04L05:06,...)

🔌 Connection TABLE 🔌

Okay bestie, this table is literally the blueprint for how your OVSDB client talks to an Open vSwitch database. Configuration for a database connection to an Open vSwitch database (OVSDB) client.

This table primarily configures the Open vSwitch database server (ovsdb-server). ✨

The Open vSwitch database server can initiate and maintain active connections to remote clients. It can also listen for database connections. Both vibes. Iconic.

🌸 Summary: 🌸

💖 Core Features:

target — string (must be unique within table)
read_only — boolean
role — string

🫶 Client Failure Detection and Handling:

max_backoff — optional integer, at least 1,000
inactivity_probe — optional integer

⭐ Status:

is_connected — boolean
status : last_error — optional string
status : state — optional string, one of ACTIVE, BACKOFF, CONNECTING, IDLE, or VOID
status : sec_since_connect — optional string, containing an integer, at least 0
status : sec_since_disconnect — optional string, containing an integer, at least 0
status : locks_held — optional string
status : locks_waiting — optional string
status : locks_lost — optional string
status : n_connections — optional string, containing an integer, at least 2
status : bound_port — optional string, containing an integer

🌈 Common Columns:

external_ids — map of string-string pairs
other_config — map of string-string pairs

✨ Details: ✨

👑 Core Features:

💅 `target`: string (must be unique within table)

Connection methods for clients. Say it with me: how are we connecting, bestie?

The following connection methods are currently supported:

🔒 `ssl:host[:port]`

The specified SSL/TLS port on the given host, which can either be a DNS name (if built with unbound library) or an IP address. A valid SSL configuration must be provided when this form is used, this configuration can be specified via command-line options or the SSL table.

If port is not specified, it defaults to 6640.

Heads up: SSL/TLS support is an optional feature that is not always built as part of OVN or Open vSwitch. So it's giving "maybe, if you're lucky." 🙈

🌐 `tcp:host[:port]`

The specified TCP port on the given host, which can either be a DNS name (if built with unbound library) or an IP address (IPv4 or IPv6). If host is an IPv6 address, wrap it in square brackets, e.g. tcp:[::1]:6640.

If port is not specified, it defaults to 6640.

🎀 `pssl:[port][:host]`

Listens for SSL/TLS connections on the specified TCP port. Specify 0 for port to have the kernel automatically choose an available port. If host, which can either be a DNS name (if built with unbound library) or an IP address, is specified, then connections are restricted to the resolved or specified local IP address (either IPv4 or IPv6 address). If host is an IPv6 address, wrap in square brackets, e.g. pssl:6640:[::1]. If host is not specified then it listens only on IPv4 (but not IPv6) addresses. A valid SSL/TLS configuration must be provided when this form is used, this can be specified either via command-line options or the SSL table.

If port is not specified, it defaults to 6640.

Again, real talk: SSL/TLS support is an optional feature that is not always built as part of OVN or Open vSwitch. 💀

🦋 `ptcp:[port][:host]`

Listens for connections on the specified TCP port. Specify 0 for port to have the kernel automatically choose an available port. If host, which can either be a DNS name (if built with unbound library) or an IP address, is specified, then connections are restricted to the resolved or specified local IP address (either IPv4 or IPv6 address). If host is an IPv6 address, wrap it in square brackets, e.g. ptcp:6640:[::1]. If host is not specified then it listens only on IPv4 addresses.

If port is not specified, it defaults to 6640.

When multiple clients are configured, the target values must be unique. Duplicate target values yield unspecified results. Not "close enough" — UNIQUE. Periodt. 👑

💖 `read_only`: boolean

true to restrict these connections to read-only transactions, false to allow them to modify the database.

🌸 `role`: string

String containing role name for this connection entry.

🫶 Client Failure Detection and Handling:

🧚 `max_backoff`: optional integer, at least 1,000

Maximum number of milliseconds to wait between connection attempts. Default is implementation-specific.

🍓 `inactivity_probe`: optional integer

Maximum number of milliseconds of idle time on connection to the client before sending an inactivity probe message. If Open vSwitch does not communicate with the client for the specified number of seconds, it will send a probe. If a response is not received for the same additional amount of time, Open vSwitch assumes the connection has been broken and attempts to reconnect. Default is implementation-specific. A value of 0 disables inactivity probes. (zero = silence, no probing, we're just vibing.)

⭐ Status:

Key-value pair of is_connected is always updated. Other key-value pairs in the status columns may be updated depends on the target type.

When target specifies a connection method that listens for inbound connections (e.g. ptcp: or punix:), both n_connections and is_connected may also be updated while the remaining key-value pairs are omitted.

On the other hand, when target specifies an outbound connection, all key-value pairs may be updated, except the above-mentioned two key-value pairs associated with inbound connection targets. They are omitted. Inbound gets two, outbound gets the rest. The math is mathing. 🔥

💜 `is_connected`: boolean

true if currently connected to this client, false otherwise.

🙈 `status : last_error`: optional string

A human-readable description of the last error on the connection to the manager; i.e. strerror(errno). This key will exist only if an error has occurred.

🎀 `status : state`: optional string, one of `ACTIVE`, `BACKOFF`, `CONNECTING`, `IDLE`, or `VOID`

The state of the connection to the manager:

VOID — Connection is disabled.
BACKOFF — Attempting to reconnect at an increasing period.
CONNECTING — Attempting to connect.
ACTIVE — Connected, remote host responsive.
IDLE — Connection is idle. Waiting for response to keep-alive.

These values may change in the future. They are provided only for human consumption.

⭐ `status : sec_since_connect`: optional string, containing an integer, at least 0

The amount of time since this client last successfully connected to the database (in seconds). Value is empty if client has never successfully been connected.

🌈 `status : sec_since_disconnect`: optional string, containing an integer, at least 0

The amount of time since this client last disconnected from the database (in seconds). Value is empty if client has never disconnected.

🔒 `status : locks_held`: optional string

Space-separated list of the names of OVSDB locks that the connection holds. Omitted if the connection does not hold any locks.

🦋 `status : locks_waiting`: optional string

Space-separated list of the names of OVSDB locks that the connection is currently waiting to acquire. Omitted if the connection is not waiting for any locks.

💀 `status : locks_lost`: optional string

Space-separated list of the names of OVSDB locks that the connection has had stolen by another OVSDB client. Omitted if no locks have been stolen from this connection. Stolen?? by another client?? the audacity.

🌸 `status : n_connections`: optional string, containing an integer, at least 2

When target specifies a connection method that listens for inbound connections (e.g. ptcp: or pssl:) and more than one connection is actually active, the value is the number of active connections. Otherwise, this key-value pair is omitted.

🎀 `status : bound_port`: optional string, containing an integer

When target is ptcp: or pssl:, this is the TCP port on which the OVSDB server is listening. (This is particularly useful when target specifies a port of 0, allowing the kernel to choose any available port.) Lowkey the most useful one when you let the kernel pick. 🫶

🌈 Common Columns:

The overall purpose of these columns is described under Common Columns at the beginning of this document.

external_ids — map of string-string pairs
other_config — map of string-string pairs

🔐 SSL TABLE

okay bestie so this table is literally the SSL/TLS configuration for ovn-sb database access. it's giving secure handshake energy fr fr. 💅

📋 Summary

private_key — string
certificate — string
ca_cert — string
bootstrap_ca_cert — boolean
ssl_protocols — string
ssl_ciphers — string
ssl_ciphersuites — string

Common Columns:

external_ids — map of string-string pairs

🔍 Details

private_key: string — the name of a PEM file holding the private key that acts as the switch's identity for SSL/TLS connections to the controller. it's the lil glow-up that proves who you are. ✨
certificate: string — the name of a PEM file containing a certificate, signed by the certificate authority (CA) that the controller and manager use, which certifies the switch's private key and identifies a trustworthy switch. basically your verified badge. 👑
ca_cert: string — the name of a PEM file containing the CA certificate used to verify that the switch is connected to a trustworthy controller. no catfishing allowed. 🙈
bootstrap_ca_cert: boolean — if it's set to true, then Open vSwitch will attempt to obtain the CA certificate from the controller on its very first SSL/TLS connection and save it to the named PEM file. If it succeeds, it will immediately drop the connection and reconnect, and from then on all SSL/TLS connections must be authenticated by a certificate signed by the CA certificate thus obtained.

⚠️ not me warning you: this option exposes the SSL/TLS connection to a man-in-the-middle attack obtaining the initial CA certificate. It may still be useful for bootstrapping, but like, be aware bestie. 💀

ssl_protocols: string — a range, or a comma- or space-delimited list, of the SSL/TLS protocols to enable for SSL/TLS connections.

Supported protocols include TLSv1.2 and TLSv1.3. Ranges can be provided in a form of two protocol names separated with a dash (TLSv1.2-TLSv1.3), or as a single protocol name with a plus sign (TLSv1.2+). The value can be a list of protocols or exactly one range. The range is a preferred way of specifying protocols and the configuration always behaves as if the range between the minimum and the maximum specified version is provided, i.e., if the value is set to TLSv1.X,TLSv1.(X+2), the TLSv1.(X+1) will also be enabled as if it was a range. Regardless of order, the highest protocol supported by both sides will be chosen when making the connection.

The default when this option is omitted is TLSv1.2+.

ssl_ciphers: string — list of ciphers (in OpenSSL cipher string format) to be supported for SSL/TLS connections with TLSv1.2. The default when this option is omitted is DEFAULT:@SECLEVEL=2.
ssl_ciphersuites: string — list of ciphersuites (in OpenSSL ciphersuites string format) to be supported for SSL/TLS connections with TLSv1.3 and later. Default value from OpenSSL will be used when this option is omitted.

Common Columns

The overall purpose of these columns is described under Common Columns at the beginning of this document.

external_ids: map of string-string pairs

🌐 DNS TABLE

Each row in this table stores the DNS records. The OVN action dns_lookup uses this table for DNS resolution. it's the glow-up phonebook of the whole setup, no cap. 🦋

📋 Summary

records — map of string-string pairs
datapaths — set of 1 or more Datapath_Bindings
options : ovn-owned — optional string

Common Columns:

external_ids — map of string-string pairs

🔍 Details

records: map of string-string pairs — key-value pair of DNS records with DNS query name as the key and a string of IP address(es) separated by comma or space as the value. ovn-northd stores the DNS query name in all lowercase in order to facilitate case-insensitive lookups. lowercase girlies stay winning. 💅

Example: "vm1.ovn.org" = "10.0.0.4 aef0::4"

datapaths: set of 1 or more Datapath_Bindings — the DNS records defined in the column records will be applied only to the DNS queries originating from the datapaths defined in this column. like a guest list, but for datapaths. 🎀
options : ovn-owned: optional string — this column indicates that all the Domains in this table are owned by OVN, and all DNS queries for those domains will be answered locally by either an IP address or DNS rejection.

Common Columns

external_ids: map of string-string pairs — See External IDs at the beginning of this document.

🛂 RBAC_Role TABLE

Role table for role-based access controls. it's giving bouncer at the club — nobody gets in without the right perms. ✨

📋 Summary

name — string
permissions — map of string-weak reference to RBAC_Permission pairs

🔍 Details

name: string — the role name, corresponding to the role column in the Connection table. your official name tag fr. 🏷️
permissions: map of string-weak reference to RBAC_Permission pairs — a mapping of table names to rows in the RBAC_Permission table. who's allowed where, iykyk.

🔑 RBAC_Permission TABLE

Permissions table for role-based access controls. the actual list of rules behind the bouncer energy. 👑

📋 Summary

table — string
authorization — set of strings
insert_delete — boolean
update — set of strings

🔍 Details

table: string — name of table to which this row applies.
authorization: set of strings — set of strings identifying columns and column:key pairs to be compared with client ID. At least one match is required in order to be authorized. A zero-length string is treated as a special value indicating all clients should be considered authorized. like, everyone's on the list, periodt. 💖
insert_delete: boolean — when "true", row insertions and authorized row deletions are permitted. adding and yeeting, but legally. 🔥
update: set of strings — set of strings identifying columns and column:key pairs that authorized clients are allowed to modify.

🚪 Gateway_Chassis TABLE

Association of Port_Binding rows of type chassisredirect to a Chassis. The traffic going out through a specific chassisredirect port will be redirected to a chassis, or a set of them in high availability configurations. it's the traffic redirect bestie</bestie> — sorry, traffic redirect bestie. 🫶

📋 Summary

name — string (must be unique within table)
chassis — optional weak reference to Chassis
priority — integer, in range 0 to 32,767
options — map of string-string pairs

Common Columns:

external_ids — map of string-string pairs

🔍 Details

name: string (must be unique within table) — name of the Gateway_Chassis.

A suggested, but not required naming convention is ${port_name}_${chassis_name}.

chassis: optional weak reference to Chassis — the Chassis to which we send the traffic.
priority: integer, in range 0 to 32,767 — this is the priority the specific Chassis among all Gateway_Chassis belonging to the same Port_Binding. highest priority = main character energy. 👑
options: map of string-string pairs — reserved for future use. mysterious, iconic, keeping us guessing. 🙈

Common Columns

The overall purpose of these columns is described under Common Columns at the beginning of this document.

external_ids: map of string-string pairs

🔁 HA_Chassis TABLE

📋 Summary

chassis — optional weak reference to Chassis
priority — integer, in range 0 to 32,767

Common Columns:

external_ids — map of string-string pairs

🔍 Details

chassis: optional weak reference to Chassis — the Chassis which provides the HA functionality.
priority: integer, in range 0 to 32,767 — priority of the HA chassis. Chassis with highest priority will be the active chassis in the HA chassis group. first place wins the crown. 👑

Common Columns

external_ids: map of string-string pairs — See External IDs at the beginning of this document.

👯 HA_Chassis_Group TABLE

Table representing a group of chassis which can provide High availability services. Each chassis in the group is represented by the table HA_Chassis. The HA chassis with highest priority will be the active chassis of this group. If the active chassis failover is detected, the HA chassis with the next higher priority takes over the responsibility of providing the HA. If ha_chassis_group column of the table Port_Binding references this table, then this HA chassis group provides the gateway functionality and redirects the gateway traffic to the active chassis of this group. it's the squad — one main character at a time, and the understudy is always ready. 💅✨

📋 Summary

name — string (must be unique within table)
ha_chassis — set of HA_Chassises
ref_chassis — set of weak reference to Chassis

Common Columns:

external_ids — map of string-string pairs

🔍 Details

name: string (must be unique within table) — name of the HA_Chassis_Group. Name should be unique. one name, one group, no clones. 🎀
ha_chassis: set of HA_Chassises — a list of HA_Chassis which belongs to this group.
ref_chassis: set of weak reference to Chassis — the set of Chassis that reference this HA chassis group. To determine the correct Chassis, find the chassisredirect type Port_Binding that references this HA_Chassis_Group. This Port_Binding is derived from some particular logical router. Starting from that LR, find the set of all logical switches and routers connected to it, directly or indirectly, across router ports that link one LRP to another or to a LSP. For each LSP in these logical switches, find the corresponding Port_Binding and add its bound Chassis (if any) to ref_chassis. it's a whole investigation arc, bestie — follow the trail, collect the chassis. 🕵️‍♀️

Common Columns

external_ids: map of string-string pairs — See External IDs at the beginning of this document.

🎀 Controller_Event TABLE 🎀

Bestie, this is the lil' table where ovn-controller spills the tea about CMS-related events. Heads up though, and this is IMPORTANT: there's no guarantee a given event gets written exactly once in the db. So it's on the CMS to squash those duplicated lines or filter out duplicated events. No cap, it's just how it is. 💅

✨ Summary ✨

event_type — string, must be empty_lb_backends
event_info — map of string-string pairs
chassis — optional weak reference to Chassis
seq_num — integer

🔍 Details 🔍

event_type: string, must be empty_lb_backends — the event type that occurred.
event_info: map of string-string pairs — key-value pairs used to pass event info along to the CMS. The possible values are:
- vip — the VIP reported for the empty_lb_backends event
- protocol — the transport protocol reported for the empty_lb_backends event
- load_balancer — UUID of the load balancer reported for the empty_lb_backends event
chassis: optional weak reference to Chassis — this column is a Chassis record, and it identifies the chassis that has managed a given event. 🦋
seq_num: integer — event sequence number. It's a global counter for controller generated events, and the CMS can use it to detect possible duplication of the same event. Detective work, but make it database. 🔎

🌈 IP_Multicast TABLE 🌈

IP Multicast configuration options. For now it's only applicable to IGMP — that's the whole vibe rn. 💜

✨ Summary ✨

datapath — weak reference to Datapath_Binding (must be unique within table)
enabled — optional boolean
querier — optional boolean
table_size — optional integer
idle_timeout — optional integer
query_interval — optional integer
seq_no — integer
Querier configuration options:
- eth_src — string
- ip4_src — string
- ip6_src — string
- query_max_resp — optional integer

🔍 Details 🔍

datapath: weak reference to Datapath_Binding (must be unique within table) — the Datapath_Binding entry that these configuration options are defined for.
enabled: optional boolean — turns multicast snooping on/off. Default: disabled.
querier: optional boolean — turns multicast querying on/off. If it's enabled, then multicast querying is enabled by default. 👑
table_size: optional integer — caps how many multicast groups can be learned. Default: 2048 groups per datapath.
idle_timeout: optional integer — configures the idle timeout (in seconds) for IP multicast groups if multicast snooping is enabled. Default: 300 seconds.
query_interval: optional integer — configures the interval (in seconds) for sending multicast queries if snooping and querier are both enabled. Default: idle_timeout/2 seconds.
seq_no: integer — ovn-controller reads this value and flushes all learned multicast groups the moment it notices that seq_no was changed. Fresh start energy. ✨

💫 Querier configuration options 💫

The ovn-controller process that runs on OVN hypervisor nodes uses the following columns to figure out field values in IGMP/MLD queries that it originates:

eth_src: string — source Ethernet address.
ip4_src: string — source IPv4 address.
ip6_src: string — source IPv6 address.
query_max_resp: optional integer — the value (in seconds) used as the "max-response" field in multicast queries. Default: 1 second.

🦋 IGMP_Group TABLE 🦋

Holds learned IGMP groups, indexed by address/datapath/chassis. Organized. Focused. Iconic. 💅

✨ Summary ✨

address — string
protocol — string
datapath — optional weak reference to Datapath_Binding
chassis — optional weak reference to Chassis
ports — set of weak reference to Port_Bindings
chassis_name — string

🔍 Details 🔍

address: string — destination IPv4 address for the IGMP group.
protocol: string — the group protocol version, either IGMPv1,v2,v3 or MLDv1,v2.
datapath: optional weak reference to Datapath_Binding — the datapath this IGMP group belongs to.
chassis: optional weak reference to Chassis — the chassis this IGMP group belongs to.
ports: set of weak reference to Port_Bindings — the destination port bindings for this IGMP group.
chassis_name: string — the chassis that inserted this record. This column is used for RBAC purposes only, so don't read anything else into it bestie.

🫶 Service_Monitor TABLE 🫶

Okay so every single row in this table configures monitoring a service for its liveness. The service can be an IPv4 TCP or UDP service. ovn-controller periodically sends out service monitor packets and updates the status of the service. And here's the fun cross-deployment bit: if the service monitor is not local, then ovn-ic creates a record about it in the SBDB database, after which another OVN deployment creates a record about the Service Monitor in its SBDB, and the status is propagated back to the initial record in the original availability zone. Group chat across availability zones, fr fr. 🌈

ovn-northd uses this feature to implement the load balancer health check feature offered to the CMS through the northbound database. ✨

✨ Summary ✨

Configuration:

type — optional string, one of load-balancer, logical-switch-port, or network-function
ip — string
mac — string
protocol — optional string, one of icmp, tcp, or udp
port — integer, in range 0 to 65,535
logical_input_port — string
logical_port — string
src_mac — string
src_ip — string
chassis_name — string
remote — boolean
ic_learned — boolean
options : interval — optional string, containing an integer
options : timeout — optional string, containing an integer
options : success_count — optional string, containing an integer
options : failure_count — optional string, containing an integer

Status Reporting:

status — optional string, one of error, offline, or online

Common Columns:

external_ids — map of string-string pairs

🔍 Details 🔍

🎀 Configuration 🎀

ovn-northd sets these columns and values to configure the service monitor.

type: optional string, one of load-balancer, logical-switch-port, or network-function — the type of the service. Supported values are "load-balancer", "network-function", and "logical-switch-port".
ip: string — destination IP used in monitor packets. For load-balancer service this is the IP of the service to be monitored. For network-function service this IP is used to send probe packets through the associated Network Function port pair.
mac: string — destination MAC address used in monitor packets. This is applicable only for network-function services.
protocol: optional string, one of icmp, tcp, or udp — the protocol of the service. For type load-balancer, supported protocols are tcp and udp. For type "network-function", supported protocol is icmp, and the health probe is done by injecting an icmp echo request packet into the inport of the Network_Function and then monitoring the same packet coming out of the outport. For type "logical-switch-port", supported protocols are tcp, udp and icmp. 🔥
port: integer, in range 0 to 65,535 — the TCP or UDP port of the service.
logical_input_port: string — this is applicable only for network-function type. The VIF of the logical port on which monitor packets have to be sent. The ovn-controller that binds this logical_port monitors the service by sending periodic monitor packets.
logical_port: string — the VIF of the logical port on which the service is running. The ovn-controller that binds this logical_port monitors the service by sending periodic monitor packets. For load-balancer this is the port to which monitor packets are sent and from which response packets are received. For network-function this is the port from which the forwarded monitor packets are received.
src_mac: string — source Ethernet address to use in the service monitor packet.
src_ip: string — source IPv4 or IPv6 address to use in the service monitor packet.
chassis_name: string — the name of the chassis where the logical port is bound.
remote: boolean — set to true if backend locates on remote ovn deployment. 🛰️
ic_learned: boolean — set to true if the service monitor was propagated from another OVN deployment via ovn-ic management.
options : interval: optional string, containing an integer — the interval, in seconds, between service monitor checks.
options : timeout: optional string, containing an integer — the time, in seconds, after which the service monitor check times out.
options : success_count: optional string, containing an integer — the number of successful checks after which the service is considered online. 💖
options : failure_count: optional string, containing an integer — the number of failure checks after which the service is considered offline. 😭

🩺 Status Reporting 🩺

The ovn-controller on the chassis that hosts the logical_port updates this column to report the service's status.

status: optional string, one of error, offline, or online

For TCP service, ovn-controller sends a SYN to the service and expects an ACK response to consider the service to be online.

For UDP service, ovn-controller sends a UDP packet to the service and doesn't expect any reply. If it receives an ICMP reply, then it considers the service to be offline.

For ICMP service, ovn-controller sends an ICMP Echo Request and expects an ICMP Echo Reply to consider service to be online. If no reply is received or if an ICMP error message is received, the service is considered offline.

🧚 Common Columns 🧚

external_ids: map of string-string pairs — See External IDs at the beginning of this document.

💖 Load_Balancer TABLE 💖

Okay bestie, every single row in here? It's a load balancer. That's it. That's the vibe. ✨

🌸 Summary 🌸

name — string
vips — map of string-string pairs
protocol — optional string, one of sctp, tcp, or udp
datapaths — set of Datapath_Bindings
datapath_group — optional Logical_DP_Group
ls_datapath_group — optional Logical_DP_Group
lr_datapath_group — optional Logical_DP_Group
Load_Balancer options:
- options : hairpin_snat_ip — optional string
Common Columns:
- external_ids — map of string-string pairs

🔍 Details 🔍

name: string

A name for the load balancer. And listen — this name has no special meaning or purpose other than to provide convenience for human interaction with the ovn-nb database. It's just a little nickname so humans can tell things apart, that's literally all it does. 💅

vips: map of string-string pairs

A map of virtual IP addresses (and an optional port number with : as a separator) associated with this load balancer and their corresponding endpoint IP addresses (and optional port numbers with : as separators) separated by commas. Yes, commas. Multiple endpoints. Slay. 🎀

protocol: optional string, one of sctp, tcp, or udp

Valid protocols are tcp, udp, or sctp. This column is useful when a port number is provided as part of the vips column. If this column is empty and a port number is provided as part of vips column, OVN assumes the protocol to be tcp. (Not me defaulting to tcp, but okay, iconic behavior honestly. 🙈)

datapaths: set of Datapath_Bindings

Datapaths to which this load balancer applies to.

datapath_group: optional Logical_DP_Group

Deprecated. 😭 The group of datapaths to which this load balancer applies to. This means that the same load balancer applies to all datapaths in a group.

ls_datapath_group: optional Logical_DP_Group

The group of datapaths to which this load balancer applies to. This means that the same load balancer applies to all datapaths in a group. (Yes bestie, it's giving déjà vu, but this one is the not-deprecated one. 👑)

lr_datapath_group: optional Logical_DP_Group

The group of logical router datapaths to which this load balancer applies to. This means that the same load balancer applies to all datapaths in a group.

🎀 Load_Balancer options 🎀

options : hairpin_snat_ip: optional string

IP to be used as source IP for packets that have been hair-pinned after load balancing. This value is automatically populated by ovn-northd. So like, don't stress about setting it yourself, the daemon's got it. 🫶

💜 Common Columns 💜

external_ids: map of string-string pairs

See External IDs at the beginning of this document. Go scroll, bestie. ⭐

🦋 BFD TABLE 🦋

Contains BFD parameter for ovn-controller bfd configuration. Bidirectional Forwarding Detection, if you were wondering — the "are you still there??" of networking. 😭

✨ Summary ✨

Configuration:
- src_port — integer, in range 49,152 to 65,535
- disc — integer
- logical_port — string
- dst_ip — string
- min_tx — integer
- min_rx — integer
- detect_mult — integer
- chassis_name — string
- options — map of string-string pairs
- external_ids — map of string-string pairs
Status Reporting:
- status — string, one of admin_down, down, init, or up

🔍 Details 🔍

🌈 Configuration 🌈

src_port: integer, in range 49,152 to 65,535

udp source port used in bfd control packets. The source port MUST be in the range 49152 through 65535 (RFC5881 section 4). Like, MUST must. The RFC said so, not me. 💀

disc: integer

A unique, nonzero discriminator value generated by the transmitting system, used to demultiplex multiple BFD sessions between the same pair of systems. Zero? Not invited to the party. 🙅

logical_port: string

OVN logical port when BFD engine is running.

dst_ip: string

BFD peer IP address.

min_tx: integer

This is the minimum interval, in milliseconds, that the local system would like to use when transmitting BFD Control packets, less any jitter applied. The value zero is reserved. (Reserved = hands off, that seat's taken. 🪑)

min_rx: integer

This is the minimum interval, in milliseconds, between received BFD Control packets that this system is capable of supporting, less any jitter applied by the sender. If this value is zero, the transmitting system does not want the remote system to send any periodic BFD Control packets. So zero is literally you going "pls stop texting me" but for control packets. 😭

detect_mult: integer

Detection time multiplier. The negotiated transmit interval, multiplied by this value, provides the Detection Time for the receiving system in Asynchronous mode. Math girlies rise. 🧮

chassis_name: string

The name of the chassis where the logical port is bound.

options: map of string-string pairs

Reserved for future use. (Mystery box. Don't open it. 🎁)

external_ids: map of string-string pairs

See External IDs at the beginning of this document.

💫 Status Reporting 💫

status: string, one of admin_down, down, init, or up

BFD port logical states. Possible values are:

admin_down
down
init
up

🌸 FDB TABLE 🌸

This table is primarily used to learn the MACs observed on a VIF (or a localnet port with 'localnet_learn_fdb' enabled) which belongs to a Logical_Switch_Port record in OVN_Northbound whose port security is disabled and 'unknown' address set. If port security is disabled on a Logical_Switch_Port record, OVN should allow traffic with any source mac from the VIF. This table will be used to deliver a packet to the VIF, If a packet's eth.dst is learnt.

Heads up bestie: no port security + 'unknown' address set = OVN lets basically anything through from that VIF, and this table is what remembers who's who so it can actually deliver stuff back. Forwarding database behavior, lowkey iconic. 🔥

✨ Summary ✨

mac — string
dp_key — integer, in range 1 to 16,777,215
port_key — integer, in range 1 to 16,777,215
timestamp — integer

🔍 Details 🔍

mac: string

The learnt mac address. 👀

dp_key: integer, in range 1 to 16,777,215

The key of the datapath on which this FDB was learnt.

port_key: integer, in range 1 to 16,777,215

The key of the port binding on which this FDB was learnt.

timestamp: integer

The timestamp in msec when the FDB was added or updated. Records that existed before this column will have 0. (Old records said "no thoughts, head empty, zero." 🫠)

💅 Static_MAC_Binding TABLE 💅

Each record represents a Static_MAC_Binding entry for a logical router. Hand-typed MAC bindings, no learning, no drama. ✨

✨ Summary ✨

logical_port — string
ip — string
mac — string
override_dynamic_mac — boolean
datapath — Datapath_Binding

🔍 Details 🔍

logical_port: string

The logical router port for the binding.

ip: string

The bound IP address.

mac: string

The Ethernet address to which the IP is bound.

override_dynamic_mac: boolean

Override dynamically learnt MACs. So this static one wins the argument. Periodt. 👑

datapath: Datapath_Binding

The logical datapath to which the logical router port belongs.

🌈 Chassis_Template_Var TABLE 🌈

Each record represents the set of template variable instantiations for a given chassis and is populated by ovn-northd from the contents of the OVN_Northbound.Chassis_Template_Var table. Yes, it's a mirror situation. 🪞

✨ Summary ✨

chassis — string (must be unique within table)
variables — map of string-string pairs

🔍 Details 🔍

chassis: string (must be unique within table)

The chassis this set of variable values applies to.

Unique within table, bestie. One row per chassis. No duplicates, we don't do that here. 💖

variables: map of string-string pairs

The set of variable values for a given chassis.

👑 Advertised_Route TABLE 👑

Each record represents a route that should be exported from ovn to the outside network fabric. It is populated by ovn-northd based on the addresses, routes and NAT Entries of a OVN_Northbound.Logical_Router_Port. It's giving "announcing yourself to the neighborhood." 📣

✨ Summary ✨

datapath — Datapath_Binding
logical_port — Port_Binding
ip_prefix — string
tracked_port — optional Port_Binding
external_ids — map of string-string pairs

🔍 Details 🔍

datapath: Datapath_Binding

The datapath belonging to the OVN_Northbound.Logical_Router that this route is valid for.

logical_port: Port_Binding

This is the Port_Binding that the router will send packets out that are received for the below prefix.

ip_prefix: string

IP prefix of this route (e.g. 192.168.100.0/24). Look at that, a whole example, we love a concrete example. 🍓

tracked_port: optional Port_Binding

In combination with a host ip_prefix this tracks the port OVN will forward the packets for this destination to. If set the ip_prefix will always contain a /32 (for ipv4) or /128 (for ipv6) prefix. An announcing chassis can use this information to check if this destination is local and adjust the route priorities based on that.

external_ids: map of string-string pairs

See External IDs at the beginning of this document.

The following keys control distributed Load_Balancer routes:

source — ovn-northd sets this to lb on routes derived from Load_Balancer VIPs. It is absent on other routes. The controller applies LB-specific handling when this key and distributed-lb=true are both present.
distributed-lb — Set to true by ovn-northd when the route belongs to a Load Balancer whose options:distributed option is enabled. The health gate, administrative enable flag and status table apply only to routes carrying this key.
health-checks — For a health-checked distributed Load_Balancer route, ovn-northd records each relevant backend as protocol,IP,port. When more than one backend is relevant the tuples are separated by semicolons. ovn-controller looks up matching Service_Monitor rows. When a shared route (same VIP IP and backend LSP) has at least one contributor without a health check, the key is absent so the controller does not gate the route.
enabled — Administrative enable flag for routes carrying distributed-lb=true. A value of false withdraws the route regardless of Service_Monitor health. An absent key is treated as enabled. A privileged administrative writer can use this key to withdraw a route.

Real talk: enabled=false pulls the route no matter what the Service_Monitor says about health. And if the key's just... not there? Then it counts as enabled. If you're a privileged administrative writer, this is your withdraw-the-route button. Use it with intention. 🫶

✨ Learned_Route TABLE ✨

Okay bestie, every single record in here is a route that got learned by OVN using some dynamic routing logic that lives outside of OVN. It's populated by ovn-controller with the routes it learns locally, so think of it as the receipts folder for "where did this route come from, bestie?" 🦋

🌸 Summary 🌸

datapath — Datapath_Binding
logical_port — Port_Binding
ip_prefix — string
nexthop — string
external_ids — map of string-string pairs

💖 Details 💖

datapath: Datapath_Binding — the datapath that belongs to the OVN_Northbound.Logical_Router this route is valid for. it's giving "this route belongs to that router, no cap". 👑
logical_port: Port_Binding — this is the Port_Binding that the route was learned on. the origin story, fr fr.
ip_prefix: string — the IP prefix of this route, like 192.168.100.0/24. the whole vibe of the route in one string. ✨
nexthop: string — this is the nexthop IP we learned from outside of OVN. outsider info, main character energy. 💅
external_ids: map of string-string pairs — see External IDs at the beginning of this document. go check it, iykyk. 🎀

🫶 ECMP_Nexthop TABLE 🫶

Every record here is an active next-hop for ECMP routes that were created with the --ecmp-symmetric-reply option, and that ovn-northd commits to the OVS connection tracker. The ECMP_Nexthop table is used by ovn-controller to track active ct entries and to flush the stale ones — like a lil cleanup crew for your connection tracker, obsessed. 🧹✨

🌈 Summary 🌈

nexthop — string
port — Port_Binding
datapath — Datapath_Binding
mac — string
external_ids — map of string-string pairs

💜 Details 💜

nexthop: string — the nexthop IP address for this ECMP route. and listen, the nexthop IP address should be the IP address of a connected router port, or the IP address of an external device used as the nexthop for the given destination. no random IPs pls. 🙈
port: Port_Binding — the reference to the Port_Binding table for the port used to connect to the configured next-hop. it's giving "this is the port that does the thing". 🦋
datapath: Datapath_Binding — the reference to the Datapath_Binding table for the datapath where the port used to connect to the configured next-hop is running. yes, it's a whole chain of references, we love a connected queen. 👑
mac: string — nexthop mac address. short and iconic. 💅
external_ids: map of string-string pairs — see External IDs at the beginning of this document. 💖

🎀 ACL_ID TABLE 🎀

Each record here is an identifier that ovn-northd needs to synchronize with instances of ovn-controller. the UUID of each record corresponds directly with an ACL record in the northbound database — so it's a 1:1 situation, bestie, no middlemen. 🔥

⭐ Summary ⭐

id — integer, in range 0 to 32,767

💖 Details 💖

id: integer, in range 0 to 32,767 — an identifier corresponding to a northbound allow-established ACL. that's the whole range, respect the range. 🫶

🦋 Advertised_MAC_Binding TABLE 🦋

Each record here is an ip/mac binding that the OVN_Northbound.Logical_Switch is announcing outside the network fabric — but only if EVPN is enabled on the datapath. yes, conditional queen. no EVPN, no announcement. periodt. ✨

🌸 Summary 🌸

datapath — Datapath_Binding
logical_port — Port_Binding
ip — string
mac — string
external_ids — map of string-string pairs

💜 Details 💜

datapath: Datapath_Binding — the datapath corresponding to the OVN_Northbound.Logical_Switch this ip/mac binding belongs to. it knows where it came from. 🎀
logical_port: Port_Binding — this is the Port_Binding this ip/mac binding belongs to. the port it's riding for, fr fr. 💅
ip: string — announced IP, like 192.168.100.1. out here telling the whole network. 📣
mac: string — announced mac address. matching set with the IP above, obviously. 👑
external_ids: map of string-string pairs — see External IDs at the beginning of this document. last one, bestie, go read it. 🫶

and that's the WHOLE ovn-sb schema, start to finish!! you literally read every single table and i'm so proud of you. 💖

This page is from Open vSwitch 26.09.1, DB Schema 21.13.0, and it's the ovn-sb(5) manual page — so if you ever need to cite it, that's the source and version, bestie. now go forth and query some tables, you absolute icon. 🌈👑💅

📦 where this page comes from

fedora 44: ovn 26.09.0-33.fc44 · Apache-2.0 AND LGPL-2.1-only AND SISSL
💖 girlified by deepseek-ai/DeepSeek-V4.1-Flash on 2026-10-18: a language model's rewrite of the original, under its terms

ovn-sb(5)

💖 NAME 💖

✨ Database Structure ✨

🦋 Physical network 🦋

🌈 Logical Network 🌈

💅 Logical-physical bindings 💅

🍓 MAC bindings 🍓

🌸 Common Columns 🌸

👑 TABLE SUMMARY 👑

💖 SB_Global TABLE 💖

✨ Summary: ✨

🌸 Details: 🌸

⭐ Status:

🦋 Common Columns:

💜 Common options:

🌈 Options for configuring BFD:

🧚 Options for configuring ovn-sbctl:

🌟 Connection Options:

🎀 Security Configurations:

👑 Chassis TABLE 👑

🌸 Summary 🌸

💖 Details 💖

name: string (must be unique within table)

hostname: string

nb_cfg: integer

other_config : ovn-bridge-mappings: optional string

other_config : datapath-type: optional string

other_config : iface-types: optional string

other_config : ovn-cms-options: optional string

other_config : is-interconn: optional string

other_config : is-remote: optional string

transport_zones: set of strings

other_config : ovn-chassis-mac-mappings: optional string

🫶 Common Columns 🫶

✨ Encapsulation Configuration ✨

🎀 Gateway Configuration 🎀

🦋 Chassis_Private TABLE 🦋

🌸 Summary 🌸

💖 Details 💖

name: string (must be unique within table)

chassis: optional weak reference to Chassis

nb_cfg: integer

nb_cfg_timestamp: integer

🫶 Common Columns 🫶

💖 Encap TABLE 💖

Summary:

Details:

🌸 Address_Set TABLE 🌸

Summary:

Details:

🦋 Port_Group TABLE 🦋

Summary:

Details:

✨ Logical_Flow TABLE ✨

Architectural Logical Life Cycle of a Packet

Pipeline Stages

Summary:

Details:

✨ Symbols ✨

🔥 Relational operators 🔥

🍓 Constants 🍓

🌈 Miscellaneous 🌈

🦋 Symbols 🦋

🎀 actions: string 🎀

🎀 more actions, bestie, we're still going 🎀

reject { action; ... }; 🚫

trigger_event; 🎀

igmp; 📡

bind_vport(V, P); 🔗

handle_svc_check(P); 💓

handle_dhcpv6_reply; 📨

R = select(N1[=W1], N2[=W2], ...);

R = select(values=(N1[=W1], N2[=W2], ...); hash_fields="field1,field2,..."); 🎲

handle_dhcpv6_reply; 📬

R = chk_lb_hairpin(); 💇‍♀️

R = chk_lb_hairpin_reply(); ↩️

R = ct_snat_to_vip; 🔄

R = check_in_port_sec(); 🛡️

R = check_out_port_sec(); 🚪

commit_ecmp_nh(ipv6); 🧭

`name`: `string` (must be unique within table)

`hostname`: `string`

`nb_cfg`: `integer`

`other_config : ovn-bridge-mappings`: optional `string`

`other_config : datapath-type`: optional `string`

`other_config : iface-types`: optional `string`

`other_config : ovn-cms-options`: optional `string`

`other_config : is-interconn`: optional `string`

`other_config : is-remote`: optional `string`

`transport_zones`: set of `strings`

`other_config : ovn-chassis-mac-mappings`: optional `string`

`name`: `string` (must be unique within table)

`chassis`: optional weak reference to `Chassis`

`nb_cfg`: `integer`

`nb_cfg_timestamp`: `integer`

🎀 `actions`: string 🎀

`reject { action; ... };` 🚫

`trigger_event;` 🎀

`igmp;` 📡

`bind_vport(V, P);` 🔗

`handle_svc_check(P);` 💓

`handle_dhcpv6_reply;` 📨

`R = select(N1[=W1], N2[=W2], ...);`

`R = select(values=(N1[=W1], N2[=W2], ...); hash_fields="field1,field2,...");` 🎲

`handle_dhcpv6_reply;` 📬

`R = chk_lb_hairpin();` 💇‍♀️

`R = chk_lb_hairpin_reply();` ↩️

`R = ct_snat_to_vip;` 🔄

`R = check_in_port_sec();` 🛡️

`R = check_out_port_sec();` 🚪

`commit_ecmp_nh(ipv6);` 🧭

`R = check_ecmp_nh_mac();` 🔍

`R = check_ecmp_nh();` 🔎

`commit_lb_aff(vip, backend, proto, timeout);` 💞

`R = chk_lb_aff();` 🕵️‍♀️

`R = ct_nw_dst();` 🧠

`R = ct_ip6_dst();` 🌐

`R = ct_tp_dst();` 🔌

`R = ct_state_save();` 💾

`sample(probability=packets, ...)` 📊

tunnel_key: integer, in range `32,768` to `65,535`

filter: string, one of `both`, `from-lport`, or `to-lport`

type: string, one of `erspan`, `gre`, `local`, or `lport`

unit: string, either `kbps` or `pktps`