ovn-ic-sb(5)

📦
version 26.09.0 · 18 versions
, in fedora 44

🌸 ovn-ic-sb 🌸

the ovn-ic-sb(5) page, bestie — straight out of the Open vSwitch Manual. This is the OVN_IC_Southbound database schema and yes she is a whole vibe, let's get into it 💅

✨ NAME ✨

ovn-ic-sb — the OVN_IC_Southbound database schema. That's her. That's the name. Iconic behavior honestly 🎀

🦋 DESCRIPTION 🦋

okay so listen. This database holds configuration and state for interconnecting different OVN deployments. The content of the database is populated and used by the ovn-ic program in each OVN deployment, and it is not supposed to be directly used by CMS or end user. Like, hands off, she's not for you personally 🙈

The OVN Interconnection Southbound database is shared by ovn-ic program in each OVN deployment. It contains interconnection information from all related OVN deployments, and it's used as the intermediate store for each OVN deployment to exchange the information. The ovn-ic program in each deployment is the one responsible for syncing the data between this database and its own northbound and southbound databases. she's the group chat that keeps everyone in the loop, fr fr 💬

🧚 Database Structure

The OVN Interconnection Southbound database contains classes of data with different properties, as described in the sections below. different flavors, same girl ✨

🌈 Availability Zone Specific Information

These tables contain objects that are availability zone specific. Each object is owned and populated by one availability zone, and read by other availability zones. it's giving "I made this, but you can look" 👑

The Availability_Zone, Gateway, Encap and Port_Binding tables are the availability zone specific tables.

🌍 Global Information

The data that does not belong to any specific availability zone but is common for all availability zones. everyone's business, no gatekeeping 🫶

The Datapath_Binding table contains the common datapath binding information.

💜 Common Columns

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

  • external_ids: map of string-string pairs — key-value pairs for use by ovn-ic.

📋 TABLE SUMMARY 📋

The following list summarizes the purpose of each of the tables in the OVN_IC_Southbound database. Each table is described in more detail on a later page. (later page!! we love a multi-part reveal 💖)

  • IC_SB_Global — IC Southbound configuration
  • Availability_Zone — Availability Zone Information
  • Gateway — Interconnection Gateway Information
  • Encap — Encapsulation Types
  • Datapath_Binding — Transit Switch Datapath Bindings
  • Port_Binding — Transit Port Bindings
  • Route — Route
  • Connection — OVSDB client connections.
  • SSL — SSL configuration.
  • Service_Monitor — Service_Monitor configuration.
  • Address_Set — Address Sets

👑 IC_SB_Global TABLE 👑

Interconnection Southbound configuration. This table must have exactly one row. one row. singular. do not test her. 😭

Summary:

Status:
  nb_ic_cfg                   integer
Common Columns:
  external_ids                map of string-string pairs
  options                     map of string-string pairs
Connection Options:
  connections                 set of Connections
  ssl                         optional SSL

Details:

Status:

This column allows a client to track the overall configuration state of the system. she's the vibe check for the whole config 🫶

  • nb_ic_cfg: integer — Sequence number for the configuration. When a CMS or ovn-ic-nbctl updates the Interconnect northbound database, it increments the nb_ic_cfg column in the NB_IC_Global table in the Interconnect northbound database. When OVN-ICs updates the southbound database to bring it up to date with these changes, one OVN-IC updates this column to the same value. it's a little "we're all caught up ✨" handshake.

Common Columns:

  • external_ids: map of string-string pairs — See External IDs at the beginning of this document.
  • options: map of string-string pairs — that's the whole entry. no notes. 💀

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.

🦋 Availability_Zone TABLE 🦋

Each row in this table represents an Availability Zone. Each OVN deployment is considered an availability zone from the OVN control plane perspective, with its own central components, such as northbound and southbound databases and the ovn-northd daemon. every deployment is the main character of its own zone, no cap 👑

Summary:

name                          string (must be unique within table)
nb_ic_cfg                     integer

Details:

  • name: string (must be unique within table) — A name that uniquely identifies the availability zone. must be unique, so don't be out here duplicating, bestie 🙈
  • nb_ic_cfg: integer — This column is used by the OVN-IC to inform that this IC instance is aligned with the changes in INB.

🚪 Gateway TABLE 🚪

Each row in this table represents an interconnection gateway chassis in an availability zone.

Summary:

name                          string (must be unique within table)
availability_zone             Availability_Zone
hostname                      string
Common Columns:
  external_ids                map of string-string pairs
Encapsulation Configuration:
  encaps                      set of 1 or more Encaps

Details:

  • name: string (must be unique within table) — The name of the gateway. See the name column of the OVN Southbound database's Chassis table.
  • availability_zone: Availability_Zone — The availability zone that the gateway belongs to.
  • hostname: string — The hostname of the gateway.

💜 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 gateways.

  • encaps: set of 1 or more Encaps — Points to supported encapsulation configurations to transmit logical dataplane packets to this gateway. Each entry is an Encap record that describes the configuration. See the encaps column of the OVN Southbound database's Chassis table.

🎁 Encap TABLE 🎁

The encaps column in the Gateway table refers to rows in this table to identify how OVN may transmit logical dataplane packets to this gateway.

Summary:

type                          string, either geneve or vxlan
options                       map of string-string pairs
ip                            string
gateway_name                  string

Details:

  • type: string, either geneve or vxlan — The encapsulation to use to transmit packets to this gateway. See the type column of the OVN Southbound database's Encap table.
  • options: map of string-string pairs — Options for configuring the encapsulation, which may be type specific. See the options column of the OVN Southbound database's Encap table.
  • ip: string — The IPv4 address of the encapsulation tunnel endpoint.
  • gateway_name: string — The name of the gateway that created this encap.

🛤️ Datapath_Binding TABLE 🛤️

Each row in this table represents a logical datapath for a transit logical switch configured in the OVN Interconnection Northbound database's Transit_Switch table.

Summary:

transit_switch                string
type                          optional string, either transit-router or
                              transit-switch
nb_ic_uuid                    optional uuid
tunnel_key                    integer, in range 1 to 16,777,215
Common Columns:
  external_ids                map of string-string pairs

Details:

  • transit_switch: string — The name of the transit logical switch or router that is configured in the OVN Interconnection Northbound database's Transit_Switch or Transit_Router table. Note: the name of transit router is stored in the same column due to backward compatibility. legacy support ate and left no crumbs 💅
  • type: optional string, either transit-router or transit-switch — Can be one of transit-switch or transit-router.
  • nb_ic_uuid: optional uuid — This is the UUID of the corresponding northbound IC logical datapath represented by this southbound Datapath_Binding.
  • tunnel_key: integer, in range 1 to 16,777,215 — The tunnel key value to which the logical datapath is bound. The key can be generated by any ovn-ic but the same key is shared by all availability zones so that the logical datapaths can be peered across them. A tunnel key for transit switch datapath binding must be globally unique. no dupes allowed, she said what she said ✋

For more information about the meanings of a tunnel key, see the tunnel_key column of the OVN Southbound database's Datapath_Binding table.

💜 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

🌸 Port_Binding TABLE 🌸

Okay bestie, this one is so important. Every single row in here is basically making a promise: it binds a logical port on the transit switch to a physical gateway and a tunnel key. And every port on the transit switch belongs to one specific availability zone. That's the whole vibe. No cap. ✨

💅 Summary 💅

🎀 Core Features 🎀

  • transit_switch — string
  • logical_port — string (must be unique within table)
  • availability_zone — Availability_Zone
  • encap — optional weak reference to Encap
  • gateway — string
  • tunnel_key — integer, in range 1 to 32,767
  • address — string
  • type — optional string, either transit-router-port or transit-switch-port
  • nb_ic_uuid — optional uuid

🦋 Common Columns 🦋

  • external_ids — map of string-string pairs

🔍 Details 🔍

✨ Core Features ✨

  • transit_switch — string. The name of the transit switch that the corresponding logical port belongs to. Like, which switch are we even on, bestie? This is how you find out. 🛤️
  • logical_port — string (must be unique within table). A logical port, taken from name in the OVN_Northbound database's Logical_Switch_Port table. Heads up: the logical port name has to be unique across all availability zones. All of them. Every single one. 💀
  • availability_zone — Availability_Zone. The availability zone that the port belongs to. Its home, its little AZ apartment. 🏠
  • encap — optional weak reference to Encap. Points to supported encapsulation configurations to transmit logical dataplane packets to this gateway. Each entry is an Encap record that describes the configuration. 📦
  • gateway — string. The name of the gateway that this port is physically located. Physically!! As in, real hardware somewhere. 🖥️
  • 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 key can be generated by any ovn-ic, but the same key is shared by all availability zones so that the packets can go through the datapath pipelines of different availability zones. It's giving teamwork honestly. 🤝

The tunnel ID must be unique within the scope of a logical datapath. That part is not optional, bestie.

For more information about tunnel key, see tunnel_key column of the OVN Southbound database's Port_Binding table. Go read that too, iykyk. 📚

  • address — string. The Ethernet address and IP addresses used by the corresponding logical router port peering with the transit switch port. It's a string combined with the value of mac column followed by the values in networks column in Logical_Router_Port table. So like, mac first, then the networks. Don't mix up the order. 🎀
  • type — optional string, either transit-router-port or transit-switch-port. Can be one of switch-port or router-port. 👑
  • nb_ic_uuid — optional uuid. This is the UUID of the corresponding northbound IC logical datapath represented by this southbound Datapath_Binding. The little paper trail linking north to south. 🧾

💜 Common Columns 💜

  • external_ids — map of string-string pairs. See External IDs at the beginning of this document. (Yes, go look, it's up there. 🙈)

🌈 Route TABLE 🌈

Every row in this table represents a route advertised. That's it, that's the whole job. A little announcement to the world: hey, this route exists. 📣

💫 Summary 💫

🔥 Core Features 🔥

  • transit_switch — string
  • availability_zone — Availability_Zone
  • route_table — string
  • ip_prefix — string
  • nexthop — string
  • origin — string, one of connected-dynamic, connected, loadbalancer, or static

🍓 Common Columns 🍓

  • external_ids — map of string-string pairs

🧚 Options 🧚

  • options — map of string-string pairs
  • options : override-connected — optional string, either true or false

🌟 Details 🌟

💖 Core Features 💖

  • transit_switch — string. The name of the transit switch, upon which the route is advertised. That's the stage the route is performing on. 🎤
  • availability_zone — Availability_Zone. The availability zone that has advertised the route. Like, who said it? This column. 🗣️
  • route_table — string. Route table within which this route was created. Empty value means <main> routing table.

Okay so here's the lore: routes for directly-connected networks will be learned to <main> routing table, and if Logical Routers have more than one Transit Switch, which interconnects them, directly-connected routes will be added via each transit switch port and configured as ECMP routes. Additionally, these routes will be advertised to other AZ and learned into route table that has the same name in the remote logical router. When learned, these routes are automatically marked with the override-connected option, giving them higher priority than any local connected route with same prefix in that route table. This enables policy-based routing scenarios where traffic processed within a specific route table can be forcibly forwarded to remote AZ even when local connected route exists. Forcibly forwarded. It's that serious. 🔥

Static routes within route tables will be advertised and learned only if interconnecting transit switch's LRPs will have same value in options:route_table as NB route_table or ICSB route_table value respectively. Matching values or it's not happening, periodt. ✋

  • ip_prefix — string. IP prefix of this route (e.g. 192.168.100.0/24). 🎯
  • nexthop — string. Nexthop IP address for this route. Where you're headed next, babe. ➡️
  • origin — string, one of connected-dynamic, connected, loadbalancer, or static. Can be one of connected, static, connected-dynamic or loadbalancer. Here's the breakdown, bestie:
    • Routes to directly-connected subnets — LRP's CIDRs — are inserted to OVN IC SB DB with connected value in origin.
    • Static routes are inserted to OVN IC SB DB with static value.
    • Routes for LB VIPs are inserted in OVN IC SB DB with loadbalancer value.
    • Routes learned from dynamic routing are inserted in OVN IC SB DB with connected-dynamic value.

Next, when route is learned to another AZ NB DB by ovn-ic, route origin is synced to options:origin. So it travels with its receipts. 🧾✨

🦄 Common Columns 🦄

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

🎀 Options 🎀

  • options — map of string-string pairs. This column provides general key/value settings. The supported options are described individually below. 👇
  • options : override-connected — optional string, either true or false. This option is a copy of its Northbound DB counterpart.

For connected routes this option is set to true if there is a route table associated with given connected route, i.e. route_table is not empty. Empty route_table? Then nope, not true. Simple as that. 💅

🌸 Connection TABLE 🌸

So this table is literally the blueprint for how you connect to an Open vSwitch database (OVSDB) client. It's giving networking matchmaker energy. 💖

Fun fact bestie: this table is mostly out here configuring the Open vSwitch database server itself (ovsdb-server). The OVSDB server can be the one to initiate and maintain active connections to remote clients, and it can also just sit there and listen for database connections like the main character it is. 👑

✨ Summary ✨

Core Features:

  • target — string (must be unique within table)

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.

The following connection methods are currently supported, bestie:

  • 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/TLS configuration must be provided when this form is used, and that config can be specified via command-line options or the SSL table.

If port is not specified, it defaults to 6640.

Real talk: SSL/TLS support is an optional feature that is not always built as part of OVN or Open vSwitch. 💀
  • 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, and this can be specified either via command-line options or the SSL table.

If port is not specified, it defaults to 6640.

Again, not to be dramatic but 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 it being the chaos agent, fr fr.

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

💖 Status

Okay so the tea here: the key-value pair of is_connected is always updated. The other key-value pairs in the status columns may be updated, and it 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. Those two are omitted. Slay, that's just how it works. ✨

  • 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.
Heads up bestie: 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. Rude of them tbh. 😤
  • 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.) ✨

🎀 Common Columns

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

  • external_ids: map of string-string pairs
  • other_config: map of string-string pairs

💅 SSL TABLE 💅

Okay bestie, this one is literally the SSL/TLS glow-up for ovn-sb database access. It's how you tell the switch who it is and who it trusts. ✨

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 — Name of a PEM file holding the private key that's used as the switch's identity for SSL/TLS connections to the controller. It's giving "who am I" energy fr.
  • certificate: string — Name of a PEM file with a certificate inside, signed by the certificate authority (CA) that the controller and manager use. This cert certifies the switch's private key, and it's what identifies a trustworthy switch. 💖
  • ca_cert: string — Name of a PEM file with the CA certificate, used to verify that the switch is actually connected to a trustworthy controller. Vibe check on the other end, basically. 🫶
  • bootstrap_ca_cert: boolean — If you set this to true, Open vSwitch will attempt to grab the CA certificate from the controller on its very first SSL/TLS connection and save it into the named PEM file. If it works, it immediately drops the connection and reconnects — and from then on, every SSL/TLS connection has to be authenticated by a certificate signed by the CA cert it just obtained.
⚠️ Bestie listen. This option exposes the SSL/TLS connection to a man-in-the-middle attack that can obtain the initial CA certificate. It may still be useful for bootstrapping, but like... know what you're doing. 🙈
  • 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 given as 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 the preferred way to specify protocols, and the config always behaves as if the range between the minimum and maximum specified version was provided — i.e., if the value is set to TLSv1.X,TLSv1.(X+2), then TLSv1.(X+1) will also be enabled as if it was a range. Regardless of order, the highest protocol supported by both sides gets 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. The default value from OpenSSL is 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 — yeah, that one. Standard issue. ✨

🌸 Service_Monitor TABLE 🌸

Summary:

       type                          optional string, must be load-balancer
       ip                            string
       protocol                      optional string, either tcp or udp
       port                          integer, in range 0 to 65,535
       logical_port                  string
       src_ip                        string
       src_mac                       string
       status                        optional string, one of error, offline, or
                                     online
       target_availability_zone      string
       source_availability_zone      string
       options                       map of string-string pairs
       external_ids                  map of string-string pairs

Details:

  • **type: optional string, must be load-balancer** — The type of the service. Only the value "load-balancer"` is supported. That's the whole menu, bestie. 🎀
  • ip: string — IP of the service that's being monitored. Copy from SBDB record.
  • protocol: optional string, either tcp or udp — The protocol of the service. Copy from the source Southbound Database record.
  • port: integer, in range 0 to 65,535 — The TCP or UDP port of the service. Copy from the source Southbound Database record.
  • logical_port: string — The VIF of the logical port that the service is running on. The ovn-controller that binds this logical_port monitors the service by sending periodic monitor packets. Copy from the source Southbound Database record. 🦋
  • src_ip: string — Source IPv4 or IPv6 address to use in the service monitor packet. Copy from the source Southbound Database record.
  • src_mac: string — Source Ethernet address to use in the service monitor packet. Copy from the Southbound Database record.
  • status: optional string, one of error, offline, or online — The health status of the service monitor, synchronized from the target Southbound Database. Vibe check: are you online or not. 💀
  • target_availability_zone: string — The Availability Zone where the monitored service endpoint is located.
  • source_availability_zone: string — The Availability Zone that initiated this monitor entry in ICSB and retains ownership for lifecycle management. She's the main character of this entry's whole life, no cap. 👑
  • options: map of string-string pairs — Same as in Table Service_Monitor in SBDB. Copy from source SBDB record.
  • external_ids: map of string-string pairs — Same as in Table Service_Monitor in SBDB. Copy from source SBDB record.

💖 Address_Set TABLE 💖

Each row in this table represents an advertised Address_Set. The combination of name and availability_zone is unique: each availability zone may advertise at most one address set with a given name. If multiple availability zones advertise address sets with the same name, a learning availability zone will merge the addresses from all of them into a single Northbound Address_Set entry. Group project that actually works. ✨

Summary:

       name                          string
       addresses                     set of strings
       availability_zone             Availability_Zone
       Common Columns:
         external_ids                map of string-string pairs

Details:

  • name: string — A name for the address set. Names are ASCII and must match [a-zA-Z_.][a-zA-Z_.0-9]*. So like, no wild chaos characters bestie. 🌸
  • addresses: set of strings — The set of addresses in string form.
  • availability_zone: Availability_Zone — The availability zone that has advertised the Address_Set.

Common Columns:

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

And that's the whole page, bestie!! 🎉 You just read the entirety of ovn-ic-sb(5) and honestly? Iconic behaviour. 💅

This was served up by Open vSwitch 26.09.1, riding on DB Schema 2.7.0, and it's the ovn-ic-sb(5) manual page. 🎀 Go forth and configure your southbound database like the main character you are. 🫶✨

📦 where this page comes from