ovsdb

title: ovsdb(5)

summary: Open vSwitch Database (File Formats)

text:
# ovsdb(5)

## NAME
ovsdb - Open vSwitch Database (File Formats)

## DESCRIPTION
OVSDB, the Open vSwitch Database, is a database system whose network protocol is specified by RFC 7047. The RFC does not specify an on-disk storage format. The OVSDB implementation in Open vSwitch implements two storage formats: one for standalone (and active-backup) databases, and the other for clustered databases. This manpage documents both of these formats.

Most users do not need to be concerned with this specification. Instead, to manipulate OVSDB files, refer to ovsdb-tool(1). For an introduction to OVSDB as a whole, read ovsdb(7).

OVSDB files explicitly record changes that are implied by the database schema. For example, the OVSDB “garbage collection” feature means that when a client removes the last reference to a garbage-collected row, the database server automatically removes that row. The database file explicitly records the deletion of the garbage-collected row, so that the reader does not need to infer it.

OVSDB files do not include the values of ephemeral columns.

Standalone and clustered database files share the common structure described here. They are text files encoded in UTF-8 with LF (U+000A) line ends, organized as append-only series of records. Each record consists of 2 lines of text.

The first line in each record has the format OVSDB <magic> <length> <hash>, where <magic> is JSON for standalone databases or CLUSTER for clustered databases, <length> is a positive decimal integer, and <hash> is a SHA-1 checksum expressed as 40 hexadecimal digits. Words in the first line must be separated by exactly one space.

The second line must be exactly length bytes long (including the LF) and its SHA-1 checksum (including the LF) must match hash exactly. The line’s contents must be a valid JSON object as specified by RFC 4627. Strings in the JSON object must be valid UTF-8. To ensure that the second line is exactly one line of text, the OVSDB implementation expresses any LF characters within a JSON string as \n. For the same reason, and to save space, the OVSDB implementation does not “pretty print” the JSON object with spaces and LFs. (The OVSDB implementation tolerates LFs when reading an OVSDB database file, as long as length and hash are correct.)

### JSON Notation
We use notation from RFC 7047 here to describe the JSON data in records. In addition to the notation defined there, we add the following:

<raw-uuid>

A 36-character JSON string that contains a UUID in the format described by RFC 4122, e.g. "550e8400-e29b-41d4-a716-446655440000"

### Standalone Format
The first record in a standalone database contains the JSON schema for the database, as specified in RFC 7047. Only this record is mandatory (a standalone file that contains only a schema represents an empty database).

The second and subsequent records in a standalone database are transaction records. Each record may have the following optional special members, which do not have any semantics but are often useful to administrators looking through a database log with ovsdb-tool show-log:

"_date": <integer>

The time at which the transaction was committed, as an integer number of milliseconds since the Unix epoch. Early versions of OVSDB counted seconds instead of milliseconds; these can be detected by noticing that their values are less than 2**32. OVSDB always writes a _date member.

"_comment": <string>

A JSON string that specifies the comment provided in a transaction comment operation. If a transaction has multiple comment operations, OVSDB concatenates them into a single _comment member, separated by a new-line. OVSDB only writes a _comment member if it would be a nonempty string.

Each of these records also has one or more additional members, each of which maps from the name of a database table to a <table-txn>:

<table-txn>

A JSON object that describes the effects of a transaction on a database table. Its names are <raw-uuid>s for rows in the table and its values are <row-txn>s.

<row-txn>

Either null, which indicates that the transaction deleted this row, or a JSON object that describes how the transaction inserted or modified the row, whose names are the names of columns and whose values are <value>s that give the column’s new value. For new rows, the OVSDB implementation omits columns whose values have the default values for their types defined in RFC 7047 section 5.2.1; for modified rows, the OVSDB implementation omits columns whose values are unchanged.

### Clustered Format
The clustered format has the following additional notation:

<uint64>

A JSON integer that represents a 64-bit unsigned integer. The OVS JSON implementation only supports integers in the range -2**63 through 2**63-1, so 64-bit unsigned integer values from 2**63 through 2**64-1 are expressed as negative numbers.

<address>

A JSON string that represents a network address to support clustering, in the <protocol>:<ip>:<port> syntax described in ovsdb-tool(1).

<servers>

A JSON object whose names are <raw-uuid>s that identify servers and whose values are <address>es that specify those servers’ addresses.

<cluster-txn>

A JSON array with two elements:

1.

The first element is either a <database-schema> or null. A <database-schema> element is always present in the first record of a clustered database to indicate the database’s initial schema. If it is not null in a later record, it indicates a change of schema for the database.

2.

The second element is either a transaction record in the format described under Standalone Format above, or null.

When a schema is present, the transaction record is relative to an empty database. That is, a schema change effectively resets the database to empty and the transaction record represents the full database contents. This allows readers to be ignorant of the full semantics of schema change.

The first record in a clustered database contains the following members, all of which are required, except prev_election_timer:

"server_id": <raw-uuid>

The server’s own UUID, which must be unique within the cluster.

"local_address": <address>

The address on which the server listens for connections from other servers in the cluster.

"name": <id>

The database schema name. It is only important when a server is in the process of joining a cluster: a server will only join a cluster if the name matches. (If the database schema name were unique, then we would not also need a cluster ID.)

"cluster_id": <raw-uuid>

The cluster’s UUID. The all-zeros UUID is not a valid cluster ID.

"prev_term": <uint64> and "prev_index": <uint64>

The Raft term and index just before the beginning of the log.

"prev_servers": <servers>

The set of one or more servers in the cluster at index “prev_index” and term “prev_term”. It might not include this server, if it was not the initial server in the cluster.

"prev_election_timer": <uint64>

The election base time before the beginning of the log. If not exist, the default value 1000 ms is used as if it exists this record.

"prev_data": <json-value> and "prev_eid": <raw-uuid>

A snapshot of the data in the database at index “prev_index” and term “prev_term”, and the entry ID for that data. The snapshot must contain a schema.

The second and subsequent records, if present, in a clustered database represent changes to the database, to the cluster state, or both. There are several types of these records. The most important types of records directly represent persistent state described in the Raft specification:

Entry

A Raft log entry.

Term

The start of a new term.

Vote

The server’s vote for a leader in the current term.

The following additional types of records aid debugging and troubleshooting, but they do not affect correctness.

Leader

Identifies a newly elected leader for the current term.

Commit Index

An update to the server’s commit_index.

Note

A human-readable description of some event.

The table below identifies the members that each type of record contains. “yes” indicates that a member is required, “?” that it is optional, blank that it is forbidden, and [1] that data and eid must be either both present or both absent.

member

Entry

Term

Vote

Leader

Commit Index

Note

comment

?

?

?

?

?

?

term

yes

yes

yes

yes

index

yes

servers

?

election_timer

?

data

[1]

eid

[1]

vote

yes

leader

yes

commit_index

yes

note

yes

The members are:

"comment": <string>

A human-readable string giving an administrator more information about the reason a record was emitted.

"term": <uint64>

The term in which the activity occurred.

"index": <uint64>

The index of a log entry.

"servers": <servers>

Server configuration in a log entry.

"election_timer": <uint64>

Leader election timeout base value in a log entry.

"data": <json-value>

The data in a log entry.

"eid": <raw-uuid>

Entry ID in a log entry.

"vote": <raw-uuid>

The server ID for which this server voted.

"leader": <raw-uuid>

The server ID of the server. Emitted by both leaders and followers when a leader is elected.

"commit_index": <uint64>

Updated commit_index value.

"note": <string>

One of a few special strings indicating important events. The currently defined strings are:

"transfer leadership"

This server transferred leadership to a different server (with details included in comment).

"left"

This server finished leaving the cluster. (This lets subsequent readers know that the server is not part of the cluster and should not attempt to connect to it.)

### Joining a Cluster
In addition to general format for a clustered database, there is also a special case for a database file created by ovsdb-tool join-cluster. Such a file contains exactly one record, which conveys the information passed to the join-cluster command. It has the following members:

"server_id": <raw-uuid> and "local_address": <address> and "name": <id>

These have the same semantics described above in the general description of the format.

"cluster_id": <raw-uuid>

This is provided only if the user gave the --cid option to join-cluster. It has the same semantics described above.

"remote_addresses"; [<address>*]

One or more remote servers to contact for joining the cluster.

When the server successfully joins the cluster, the database file is replaced by one described in Clustered Format.

## AUTHOR
The Open vSwitch Development Community

## COPYRIGHT
2016-2024, The Open vSwitch Development Community


ovsdb-server

package: openvswitch

title: ovsdb-server(5)

summary: _Server database schema

text:
# ovsdb-server(5)

## NAME
ovsdb-server - _Server database schema

Every ovsdb-server (version 2.9 or later) always hosts an instance of this schema, which holds information on the status and configuration of the server itself. This database is read-only. This manpage describes the schema for this database.

## TABLE SUMMARY
The following list summarizes the purpose of each of the tables in the _Server database. Each table is described in more detail on a later page.

Table

Purpose

Database

Databases.

## Database TABLE
This table describes the databases hosted by the database server, with one row per database. As its database configuration and status changes, the server automatically and immediately updates the table to match.

The OVSDB protocol specified in RFC 7047 does not provide a way for an OVSDB client to find out about some kinds of configuration changes, such as about databases added or removed while a client is connected to the server, or databases changing between read/write and read-only due to a transition between active and backup roles. This table provides a solution: clients can monitor the table’s contents to find out about important changes.

Traditionally, ovsdb-server disconnects all of its clients when a significant configuration change occurs, because this prompts a well-written client to reassess what is available from the server when it reconnects. Because this table provides an alternative and more efficient way to find out about those changes, OVS 2.9 also introduces the set_db_change_aware RPC, documented in ovsdb-server(7), to allow clients to suppress this disconnection behavior.

When a database is removed from the server, in addition to Database table updates, the server sends canceled messages, as described in RFC 7047 section 4.1.4, in reply to outstanding transactions for the removed database. The server also cancels any outstanding monitoring initiated by monitor or monitor_cond requested on the removed database, sending the monitor_canceled RPC described in ovsdb-server(7). Only clients that disable disconnection with set_db_change_aware receive these messages.

Clients can use the _uuid column in this table as a generation number. The server generates a fresh _uuid every time it adds a database, so that removing and then re-adding a database to the server causes its row _uuid to change.

### Summary:
name

string

model

string, one of clustered, relay, or standalone

schema

optional string

connected

boolean

Clustered Databases:

leader

boolean

cid

optional uuid

sid

optional uuid

index

optional integer

### Details:
name: string

The database’s name, as specified in its schema.

model: string, one of clustered, relay, or standalone

The storage model: standalone for a standalone or active-backup database, clustered for a clustered database, relay for a relay database.

schema: optional string

The database schema, as a JSON string. In the case of a clustered database, this is empty until it finishes joining its cluster. In the case of a relay database, this is empty until it connects to the relay source.

connected: boolean

True if the database is connected to its storage. A standalone database is always connected. A clustered database is connected if the server is in contact with a majority of its cluster. A relay database is connected if the server is in contact with the relay source, i.e. is connected to the server it syncs from. An unconnected database cannot be modified and its data might be unavailable or stale.

Clustered Databases:

These columns are most interesting and in some cases only relevant for clustered databases, that is, those where the model column is clustered.

leader: boolean

True if the database is the leader in its cluster. For a standalone or active-backup database, this is always true. For a relay database, this is always false.

cid: optional uuid

The cluster ID for this database, which is the same for all of the servers that host this particular clustered database. For a standalone, active-backup or relay database, this is empty.

sid: optional uuid

The server ID for this database, different for each server that hosts a particular clustered database. A server that hosts more than one clustered database will have a different sid in each one. For a standalone, active-backup or relay database, this is empty.

index: optional integer

For a clustered database, the index of the log entry currently exposed to clients. For a given server, this increases monotonically. When a client switches from one server to another in a cluster, it can ensure that it never sees an older snapshot of data by avoiding servers that have index less than the largest value they have already observed.

For a standalone, active-backup or relay database, this is empty.


ovsdb.local-config

title: ovsdb.local-config(5)

summary: Local_Config database schema

text:
# ovsdb.local-config(5)

## NAME
Local_Config - Local_Config database schema

This database is for local configuration of an ovsdb-server. The database is meant to be unique, even among multiple clustered db servers, so that configuration that is local to that server can be configured separately (e.g. Connection information).

## TABLE SUMMARY
The following list summarizes the purpose of each of the tables in the Local_Config database. Each table is described in more detail on a later page.

Table

Purpose

Config

ovsdb-server configuration

Connection

OVSDB client connections.

## Config TABLE
The root local configuration table for an ovsdb-server. This table must have exactly one row.

### Summary:
Connection Options:

connections

set of Connections

### Details:
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.

## Connection TABLE
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.

### 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

Connection Parameters:

other_config : dscp

optional string, containing an integer

Configuration:

external_ids

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:

ssl:host[:port]

The specified SSL port on the host at 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.

SSL support is an optional feature that is not always built as part of Open vSwitch.

tcp:host[:port]

The specified TCP port on the host at the given host, which can either be a DNS name (if built with unbound library) or an IP address. 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 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 IPaddress (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 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.

SSL support is an optional feature that is not always built as part of 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.

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.

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.

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.

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

Connection Parameters:

other_config : dscp: optional string, containing an integer

The Differentiated Service Code Point (DSCP) is specified using 6 bits in the Type of Service (TOS) field in the IP header. DSCP provides a mechanism to classify the network traffic and provide Quality of Service (QoS) on IP networks. The DSCP value specified here is used when establishing the connection between the manager and the Open vSwitch. If no value is specified, a default value of 48 is chosen. Valid DSCP values must be in the range 0 to 63.

Configuration:

External configuration options

external_ids: map of string-string pairs

External client-defined key-value pairs


vtep

package: openvswitch-vtep

title: vtep(5)

summary: hardware_vtep database schema

text:
# vtep(5)

## NAME
vtep - hardware_vtep database schema

This schema specifies relations that a VTEP can use to integrate physical ports into logical switches maintained by a network virtualization controller such as NSX.

Glossary:

VTEP

VXLAN Tunnel End Point, an entity which originates and/or terminates VXLAN tunnels.

HSC

Hardware Switch Controller.

NVC

Network Virtualization Controller, e.g. NSX.

VRF

Virtual Routing and Forwarding instance.

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

other_config: map of string-string pairs

Key-value pairs for configuring rarely used or proprietary features.

Some tables do not have other_config column because no key-value pairs have yet been defined for them.

## TABLE SUMMARY
The following list summarizes the purpose of each of the tables in the hardware_vtep database. Each table is described in more detail on a later page.

Table

Purpose

Global

Top-level configuration.

Manager

OVSDB management connection.

Physical_Switch

A physical switch.

Tunnel

A tunnel created by a physical switch.

Physical_Port

A port within a physical switch.

Logical_Binding_Stats

Statistics for a VLAN on a physical port bound to a logical network.

Logical_Switch

A layer-2 domain.

Ucast_Macs_Local

Unicast MACs (local)

Ucast_Macs_Remote

Unicast MACs (remote)

Mcast_Macs_Local

Multicast MACs (local)

Mcast_Macs_Remote

Multicast MACs (remote)

Logical_Router

A logical L3 router.

Arp_Sources_Local

ARP source addresses for logical routers

Arp_Sources_Remote

ARP source addresses for logical routers

Physical_Locator_Set

Physical_Locator_Set configuration.

Physical_Locator

Physical_Locator configuration.

ACL_entry

ACL_entry configuration.

ACL

ACL configuration.

## Global TABLE
Top-level configuration for a hardware VTEP. There must be exactly one record in the Global table.

### Summary:
switches

set of Physical_Switchs

Database Configuration:

managers

set of Managers

Common Column:

other_config

map of string-string pairs

### Details:
switches: set of Physical_Switchs

The physical switch or switches managed by the VTEP.

When a physical switch integrates support for this VTEP schema, which is expected to be the most common case, this column should point to one Physical_Switch record that represents the switch itself. In another possible implementation, a server or a VM presents a VTEP schema front-end interface to one or more physical switches, presumably communicating with those physical switches over a proprietary protocol. In that case, this column would point to one Physical_Switch for each physical switch, and the set might change over time as the front-end server comes to represent a differing set of switches.

Database Configuration:

These columns primarily configure the database server (ovsdb-server), not the hardware VTEP itself.

managers: set of Managers

Database clients to which the database server should connect or to which it should listen, along with options for how these connection should be configured. See the Manager table for more information.

Common Column:

The overall purpose of this column is described under Common Column at the beginning of this document.

other_config: map of string-string pairs

## Manager TABLE
Configuration for a database connection to an Open vSwitch Database (OVSDB) client.

The database server can initiate and maintain active connections to remote clients. It can also listen for database connections.

### 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

Connection Parameters:

other_config : dscp

optional string, containing an integer

### Details:
Core Features:

target: string (must be unique within table)

Connection method for managers.

The following connection methods are currently supported:

ssl:host[:port]

The specified SSL port (default: 6640) on the given host, which can either be a DNS name (if built with unbound library) or an IP address.

SSL key and certificate configuration happens outside the database.

tcp:host[:port]

The specified TCP port (default: 6640) on the given host, which can either be a DNS name (if built with unbound library) or an IP address.

pssl:[port][:host]

Listens for SSL connections on the specified TCP port (default: 6640). 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.

ptcp:[port][:host]

Listens for connections on the specified TCP port (default: 6640). 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.

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 the Open vSwitch database 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, the database server assumes the connection has been broken and attempts to reconnect. Default is implementation-specific. A value of 0 disables inactivity probes.

Status:

is_connected: boolean

true if currently connected to this manager, 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 manager last successfully connected to the database (in seconds). Value is empty if manager has never successfully connected.

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

The amount of time since this manager last disconnected from the database (in seconds). Value is empty if manager 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.

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.

When multiple connections are active, status columns and key-value pairs (other than this one) report the status of one arbitrarily chosen connection.

Connection Parameters:

Additional configuration for a connection between the manager and the database server.

other_config : dscp: optional string, containing an integer

The Differentiated Service Code Point (DSCP) is specified using 6 bits in the Type of Service (TOS) field in the IP header. DSCP provides a mechanism to classify the network traffic and provide Quality of Service (QoS) on IP networks. The DSCP value specified here is used when establishing the connection between the manager and the database server. If no value is specified, a default value of 48 is chosen. Valid DSCP values must be in the range 0 to 63.

## Physical_Switch TABLE
A physical switch that implements a VTEP.

### Summary:
ports

set of Physical_Ports

tunnels

set of Tunnels

Network Status:

management_ips

set of strings

tunnel_ips

set of strings

Identification:

name

string (must be unique within table)

description

string

Error Notification:

switch_fault_status : mac_table_exhaustion

none

switch_fault_status : tunnel_exhaustion

none

switch_fault_status : lr_switch_bindings_fault

none

switch_fault_status : lr_static_routes_fault

none

switch_fault_status : lr_creation_fault

none

switch_fault_status : lr_support_fault

none

switch_fault_status : unspecified_fault

none

switch_fault_status : unsupported_source_node_replication

none

Common Column:

other_config

map of string-string pairs

### Details:
ports: set of Physical_Ports

The physical ports within the switch.

tunnels: set of Tunnels

Tunnels created by this switch as instructed by the NVC.

Network Status:

management_ips: set of strings

IPv4 or IPv6 addresses at which the switch may be contacted for management purposes.

tunnel_ips: set of strings

IPv4 or IPv6 addresses on which the switch may originate or terminate tunnels.

This column is intended to allow a Manager to determine the Physical_Switch that terminates the tunnel represented by a Physical_Locator.

Identification:

name: string (must be unique within table)

Symbolic name for the switch, such as its hostname.

description: string

An extended description for the switch, such as its switch login banner.

Error Notification:

An entry in this column indicates to the NVC that this switch has encountered a fault. The switch must clear this column when the fault has been cleared.

switch_fault_status : mac_table_exhaustion: none

Indicates that the switch has been unable to process MAC entries requested by the NVC due to lack of table resources.

switch_fault_status : tunnel_exhaustion: none

Indicates that the switch has been unable to create tunnels requested by the NVC due to lack of resources.

switch_fault_status : lr_switch_bindings_fault: none

Indicates that the switch has been unable to create the logical router interfaces requested by the NVC due to conflicting configurations or a lack of hardware resources.

switch_fault_status : lr_static_routes_fault: none

Indicates that the switch has been unable to create the static routes requested by the NVC due to conflicting configurations or a lack of hardware resources.

switch_fault_status : lr_creation_fault: none

Indicates that the switch has been unable to create the logical router requested by the NVC due to conflicting configurations or a lack of hardware resources.

switch_fault_status : lr_support_fault: none

Indicates that the switch does not support logical routing.

switch_fault_status : unspecified_fault: none

Indicates that an error has occurred in the switch but that no more specific information is available.

switch_fault_status : unsupported_source_node_replication: none

Indicates that the requested source node replication mode cannot be supported by the physical switch; this specifically means in this context that the physical switch lacks the capability to support source node replication mode. This error occurs when a controller attempts to set source node replication mode for one of the logical switches that the physical switch is keeping context for. An NVC that observes this error should take appropriate action (for example reverting the logical switch to service node replication mode). It is recommended that an NVC be proactive and test for support of source node replication by using a test logical switch on vtep physical switch nodes and then trying to change the replication mode to source node on this logical switch, checking for error. The NVC could remember this capability per vtep physical switch. Using mixed replication modes on a given logical switch is not recommended. Service node replication mode is considered a basic requirement since it only requires sending a packet to a single transport node, hence it is not expected that a switch should report that service node mode cannot be supported.

Common Column:

The overall purpose of this column is described under Common Column at the beginning of this document.

other_config: map of string-string pairs

## Tunnel TABLE
A tunnel created by a Physical_Switch.

### Summary:
local

Physical_Locator

remote

Physical_Locator

Bidirectional Forwarding Detection (BFD):

BFD Local Configuration:

bfd_config_local : bfd_dst_mac

optional string

bfd_config_local : bfd_dst_ip

optional string

BFD Remote Configuration:

bfd_config_remote : bfd_dst_mac

optional string

bfd_config_remote : bfd_dst_ip

optional string

BFD Parameters:

bfd_params : enable

optional string, either true or false

bfd_params : min_rx

optional string, containing an integer, at least 1

bfd_params : min_tx

optional string, containing an integer, at least 1

bfd_params : decay_min_rx

optional string, containing an integer

bfd_params : forwarding_if_rx

optional string, either true or false

bfd_params : cpath_down

optional string, either true or false

bfd_params : check_tnl_key

optional string, either true or false

BFD Status:

bfd_status : enabled

optional string, either true or false

bfd_status : state

optional string, one of admin_down, down, init, or up

bfd_status : forwarding

optional string, either true or false

bfd_status : diagnostic

optional string

bfd_status : remote_state

optional string, one of admin_down, down, init, or up

bfd_status : remote_diagnostic

optional string

bfd_status : info

optional string

### Details:
local: Physical_Locator

Tunnel end-point local to the physical switch.

remote: Physical_Locator

Tunnel end-point remote to the physical switch.

Bidirectional Forwarding Detection (BFD):

BFD, defined in RFC 5880, allows point to point detection of connectivity failures by occasional transmission of BFD control messages. VTEPs are expected to implement BFD.

BFD operates by regularly transmitting BFD control messages at a rate negotiated independently in each direction. Each endpoint specifies the rate at which it expects to receive control messages, and the rate at which it’s willing to transmit them. An endpoint which fails to receive BFD control messages for a period of three times the expected reception rate will signal a connectivity fault. In the case of a unidirectional connectivity issue, the system not receiving BFD control messages will signal the problem to its peer in the messages it transmits.

A hardware VTEP is expected to use BFD to determine reachability of devices at the end of the tunnels with which it exchanges data. This can enable the VTEP to choose a functioning service node among a set of service nodes providing high availability. It also enables the NVC to report the health status of tunnels.

In many cases the BFD peer of a hardware VTEP will be an Open vSwitch instance. The Open vSwitch implementation of BFD aims to comply faithfully with the requirements put forth in RFC 5880. Open vSwitch does not implement the optional Authentication or ``Echo Mode’’ features.

BFD Local Configuration:

The HSC writes the key-value pairs in the bfd_config_local column to specify the local configurations to be used for BFD sessions on this tunnel.

bfd_config_local : bfd_dst_mac: optional string

Set to an Ethernet address in the form xx:xx:xx:xx:xx:xx to set the MAC expected as destination for received BFD packets. The default is 00:23:20:00:00:01.

bfd_config_local : bfd_dst_ip: optional string

Set to an IPv4 address to set the IP address that is expected as destination for received BFD packets. The default is 169.254.1.0.

BFD Remote Configuration:

The bfd_config_remote column is the remote counterpart of the bfd_config_local column. The NVC writes the key-value pairs in this column.

bfd_config_remote : bfd_dst_mac: optional string

Set to an Ethernet address in the form xx:xx:xx:xx:xx:xx to set the destination MAC to be used for transmitted BFD packets. The default is 00:23:20:00:00:01.

bfd_config_remote : bfd_dst_ip: optional string

Set to an IPv4 address to set the IP address used as destination for transmitted BFD packets. The default is 169.254.1.1.

BFD Parameters:

The NVC sets up key-value pairs in the bfd_params column to enable and configure BFD.

bfd_params : enable: optional string, either true or false

True to enable BFD on this Tunnel. If not specified, BFD will not be enabled by default.

bfd_params : min_rx: optional string, containing an integer, at least 1

The shortest interval, in milliseconds, at which this BFD session offers to receive BFD control messages. The remote endpoint may choose to send messages at a slower rate. Defaults to 1000.

bfd_params : min_tx: optional string, containing an integer, at least 1

The shortest interval, in milliseconds, at which this BFD session is willing to transmit BFD control messages. Messages will actually be transmitted at a slower rate if the remote endpoint is not willing to receive as quickly as specified. Defaults to 100.

bfd_params : decay_min_rx: optional string, containing an integer

An alternate receive interval, in milliseconds, that must be greater than or equal to bfd_params:min_rx. The implementation should switch from bfd_params:min_rx to bfd_params:decay_min_rx when there is no obvious incoming data traffic at the tunnel, to reduce the CPU and bandwidth cost of monitoring an idle tunnel. This feature may be disabled by setting a value of 0. This feature is reset whenever bfd_params:decay_min_rx or bfd_params:min_rx changes.

bfd_params : forwarding_if_rx: optional string, either true or false

When true, traffic received on the Tunnel is used to indicate the capability of packet I/O. BFD control packets are still transmitted and received. At least one BFD control packet must be received every 100 * bfd_params:min_rx amount of time. Otherwise, even if traffic is received, the bfd_params:forwarding will be false.

bfd_params : cpath_down: optional string, either true or false

Set to true to notify the remote endpoint that traffic should not be forwarded to this system for some reason other than a connectivity failure on the interface being monitored. The typical underlying reason is ``concatenated path down,’’ that is, that connectivity beyond the local system is down. Defaults to false.

bfd_params : check_tnl_key: optional string, either true or false

Set to true to make BFD accept only control messages with a tunnel key of zero. By default, BFD accepts control messages with any tunnel key.

BFD Status:

The VTEP sets key-value pairs in the bfd_status column to report the status of BFD on this tunnel. When BFD is not enabled, with bfd_params:enable, the HSC clears all key-value pairs from bfd_status.

bfd_status : enabled: optional string, either true or false

Set to true if the BFD session has been successfully enabled. Set to false if the VTEP cannot support BFD or has insufficient resources to enable BFD on this tunnel. The NVC will disable the BFD monitoring on the other side of the tunnel once this value is set to false.

bfd_status : state: optional string, one of admin_down, down, init, or up

Reports the state of the BFD session. The BFD session is fully healthy and negotiated if UP.

bfd_status : forwarding: optional string, either true or false

Reports whether the BFD session believes this Tunnel may be used to forward traffic. Typically this means the local session is signaling UP, and the remote system isn’t signaling a problem such as concatenated path down.

bfd_status : diagnostic: optional string

A diagnostic code specifying the local system’s reason for the last change in session state. The error messages are defined in section 4.1 of [RFC 5880].

bfd_status : remote_state: optional string, one of admin_down, down, init, or up

Reports the state of the remote endpoint’s BFD session.

bfd_status : remote_diagnostic: optional string

A diagnostic code specifying the remote system’s reason for the last change in session state. The error messages are defined in section 4.1 of [RFC 5880].

bfd_status : info: optional string

A short message providing further information about the BFD status (possibly including reasons why BFD could not be enabled).

## Physical_Port TABLE
A port within a Physical_Switch.

### Summary:
vlan_bindings

map of integer-Logical_Switch pairs, key in range 0 to 4,095

acl_bindings

map of integer-ACL pairs, key in range 0 to 4,095

vlan_stats

map of integer-Logical_Binding_Stats pairs, key in range 0 to 4,095

Identification:

name

string

description

string

Error Notification:

port_fault_status : invalid_vlan_map

none

port_fault_status : invalid_ACL_binding

none

port_fault_status : unspecified_fault

none

Common Column:

other_config

map of string-string pairs

### Details:
vlan_bindings: map of integer-Logical_Switch pairs, key in range 0 to 4,095

Identifies how VLANs on the physical port are bound to logical switches. If, for example, the map contains a (VLAN, logical switch) pair, a packet that arrives on the port in the VLAN is considered to belong to the paired logical switch. A value of zero in the VLAN field means that untagged traffic on the physical port is mapped to the logical switch.

acl_bindings: map of integer-ACL pairs, key in range 0 to 4,095

Attach Access Control Lists (ACLs) to the physical port. The column consists of a map of VLAN tags to ACLs. If the value of the VLAN tag in the map is 0, this means that the ACL is associated with the entire physical port. Non-zero values mean that the ACL is to be applied only on packets carrying that VLAN tag value. Switches will not necessarily support matching on the VLAN tag for all ACLs, and unsupported ACL bindings will cause errors to be reported. The binding of an ACL to a specific VLAN and the binding of an ACL to the entire physical port should not be combined on a single physical port. That is, a mix of zero and non-zero keys in the map is not recommended.

vlan_stats: map of integer-Logical_Binding_Stats pairs, key in range 0 to 4,095

Statistics for VLANs bound to logical switches on the physical port. An implementation that fully supports such statistics would populate this column with a mapping for every VLAN that is bound in vlan_bindings. An implementation that does not support such statistics or only partially supports them would not populate this column or partially populate it, respectively. A value of zero in the VLAN field refers to untagged traffic on the physical port.

Identification:

name: string

Symbolic name for the port. The name ought to be unique within a given Physical_Switch, but the database is not capable of enforcing this.

description: string

An extended description for the port.

Error Notification:

An entry in this column indicates to the NVC that the physical port has encountered a fault. The switch must clear this column when the error has been cleared.

port_fault_status : invalid_vlan_map: none

Indicates that a VLAN-to-logical-switch mapping requested by the controller could not be instantiated by the switch because of a conflict with local configuration.

port_fault_status : invalid_ACL_binding: none

Indicates that an error has occurred in associating an ACL with a port.

port_fault_status : unspecified_fault: none

Indicates that an error has occurred on the port but that no more specific information is available.

Common Column:

The overall purpose of this column is described under Common Column at the beginning of this document.

other_config: map of string-string pairs

## Logical_Binding_Stats TABLE
Reports statistics for the Logical_Switch with which a VLAN on a Physical_Port is associated.

### Summary:
Statistics:

packets_from_local

integer

bytes_from_local

integer

packets_to_local

integer

bytes_to_local

integer

### Details:
Statistics:

These statistics count only packets to which the binding applies.

packets_from_local: integer

Number of packets sent by the Physical_Switch.

bytes_from_local: integer

Number of bytes in packets sent by the Physical_Switch.

packets_to_local: integer

Number of packets received by the Physical_Switch.

bytes_to_local: integer

Number of bytes in packets received by the Physical_Switch.

## Logical_Switch TABLE
A logical Ethernet switch, whose implementation may span physical and virtual media, possibly crossing L3 domains via tunnels; a logical layer-2 domain; an Ethernet broadcast domain.

### Summary:
Per Logical-Switch Tunnel Key:

tunnel_key

optional integer

Replication Mode:

replication_mode

optional string, either service_node or source_node

Identification:

name

string (must be unique within table)

description

string

Common Column:

other_config

map of string-string pairs

### Details:
Per Logical-Switch Tunnel Key:

Tunnel protocols tend to have a field that allows the tunnel to be partitioned into sub-tunnels: VXLAN has a VNI, GRE and STT have a key, CAPWAP has a WSI, and so on. We call these generically ``tunnel keys.’’ Given that one needs to use a tunnel key at all, there are at least two reasonable ways to assign their values:

•

Per Logical_Switch+Physical_Locator pair. That is, each logical switch may be assigned a different tunnel key on every Physical_Locator. This model is especially flexible.

In this model, Physical_Locator carries the tunnel key. Therefore, one Physical_Locator record will exist for each logical switch carried at a given IP destination.

•

Per Logical_Switch. That is, every tunnel associated with a particular logical switch carries the same tunnel key, regardless of the Physical_Locator to which the tunnel is addressed. This model may ease switch implementation because it imposes fewer requirements on the hardware datapath.

In this model, Logical_Switch carries the tunnel key. Therefore, one Physical_Locator record will exist for each IP destination.

tunnel_key: optional integer

This column is used only in the tunnel key per Logical_Switch model (see above), because only in that model is there a tunnel key associated with a logical switch.

For vxlan_over_ipv4 encapsulation, when the tunnel key per Logical_Switch model is in use, this column is the VXLAN VNI that identifies a logical switch. It must be in the range 0 to 16,777,215.

Replication Mode:

For handling L2 broadcast, multicast and unknown unicast traffic, packets can be sent to all members of a logical switch referenced by a physical switch. There are different modes to replicate the packets. The default mode of replication is to send the traffic to a service node, which can be a hypervisor, server or appliance, and let the service node handle replication to other transport nodes (hypervisors or other VTEP physical switches). This mode is called service node replication. An alternate mode of replication, called source node replication involves the source node sending to all other transport nodes. Hypervisors are always responsible for doing their own replication for locally attached VMs in both modes. Service node replication mode is the default and considered a basic requirement because it only requires sending the packet to a single transport node.

replication_mode: optional string, either service_node or source_node

This optional column defines the replication mode per Logical_Switch. There are 2 valid values, service_node and source_node. If the column is not set, the replication mode defaults to service_node.

Identification:

name: string (must be unique within table)

Symbolic name for the logical switch.

description: string

An extended description for the logical switch, such as its switch login banner.

Common Column:

The overall purpose of this column is described under Common Column at the beginning of this document.

other_config: map of string-string pairs

## Ucast_Macs_Local TABLE
Mapping of unicast MAC addresses to tunnels (physical locators). This table is written by the HSC, so it contains the MAC addresses that have been learned on physical ports by a VTEP.

### Summary:
MAC

string

logical_switch

Logical_Switch

locator

Physical_Locator

ipaddr

string

### Details:
MAC: string

A MAC address that has been learned by the VTEP.

logical_switch: Logical_Switch

The Logical switch to which this mapping applies.

locator: Physical_Locator

The physical locator to be used to reach this MAC address. In this table, the physical locator will be one of the tunnel IP addresses of the appropriate VTEP.

ipaddr: string

The IP address to which this MAC corresponds. Optional field for the purpose of ARP supression.

## Ucast_Macs_Remote TABLE
Mapping of unicast MAC addresses to tunnels (physical locators). This table is written by the NVC, so it contains the MAC addresses that the NVC has learned. These include VM MAC addresses, in which case the physical locators will be hypervisor IP addresses. The NVC will also report MACs that it has learned from other HSCs in the network, in which case the physical locators will be tunnel IP addresses of the corresponding VTEPs.

### Summary:
MAC

string

logical_switch

Logical_Switch

locator

Physical_Locator

ipaddr

string

### Details:
MAC: string

A MAC address that has been learned by the NVC.

logical_switch: Logical_Switch

The Logical switch to which this mapping applies.

locator: Physical_Locator

The physical locator to be used to reach this MAC address. In this table, the physical locator will be either a hypervisor IP address or a tunnel IP addresses of another VTEP.

ipaddr: string

The IP address to which this MAC corresponds. Optional field for the purpose of ARP supression.

## Mcast_Macs_Local TABLE
Mapping of multicast MAC addresses to tunnels (physical locators). This table is written by the HSC, so it contains the MAC addresses that have been learned on physical ports by a VTEP. These may be learned by IGMP snooping, for example. This table also specifies how to handle unknown unicast and broadcast packets.

### Summary:
MAC

string

logical_switch

Logical_Switch

locator_set

Physical_Locator_Set

ipaddr

string

### Details:
MAC: string

A MAC address that has been learned by the VTEP.

The keyword unknown-dst is used as a special ``Ethernet address’’ that indicates the locations to which packets in a logical switch whose destination addresses do not otherwise appear in Ucast_Macs_Local (for unicast addresses) or Mcast_Macs_Local (for multicast addresses) should be sent.

logical_switch: Logical_Switch

The Logical switch to which this mapping applies.

locator_set: Physical_Locator_Set

The physical locator set to be used to reach this MAC address. In this table, the physical locator set will be contain one or more tunnel IP addresses of the appropriate VTEP(s).

ipaddr: string

The IP address to which this MAC corresponds. Optional field for the purpose of ARP supression.

## Mcast_Macs_Remote TABLE
Mapping of multicast MAC addresses to tunnels (physical locators). This table is written by the NVC, so it contains the MAC addresses that the NVC has learned. This table also specifies how to handle unknown unicast and broadcast packets.

Multicast packet replication may be handled by a service node, in which case the physical locators will be IP addresses of service nodes. If the VTEP supports replication onto multiple tunnels, using source node replication, then this may be used to replicate directly onto VTEP-hypervisor or VTEP-VTEP tunnels.

### Summary:
MAC

string

logical_switch

Logical_Switch

locator_set

Physical_Locator_Set

ipaddr

string

### Details:
MAC: string

A MAC address that has been learned by the NVC.

The keyword unknown-dst is used as a special ``Ethernet address’’ that indicates the locations to which packets in a logical switch whose destination addresses do not otherwise appear in Ucast_Macs_Remote (for unicast addresses) or Mcast_Macs_Remote (for multicast addresses) should be sent.

logical_switch: Logical_Switch

The Logical switch to which this mapping applies.

locator_set: Physical_Locator_Set

The physical locator set to be used to reach this MAC address. In this table, the physical locator set will be either a set of service nodes when service node replication is used or the set of transport nodes (defined as hypervisors or VTEPs) participating in the associated logical switch, when source node replication is used. When service node replication is used, the VTEP should send packets to one member of the locator set that is known to be healthy and reachable, which could be determined by BFD. When source node replication is used, the VTEP should send packets to all members of the locator set.

ipaddr: string

The IP address to which this MAC corresponds. Optional field for the purpose of ARP supression.

## Logical_Router TABLE
A logical router, or VRF. A logical router may be connected to one or more logical switches. Subnet addresses and interface addresses may be configured on the interfaces.

### Summary:
switch_binding

map of string-Logical_Switch pairs

static_routes

map of string-string pairs

acl_binding

map of string-ACL pairs

Identification:

name

string (must be unique within table)

description

string

Error Notification:

LR_fault_status : invalid_ACL_binding

none

LR_fault_status : unspecified_fault

none

Common Column:

other_config

map of string-string pairs

### Details:
switch_binding: map of string-Logical_Switch pairs

Maps from an IPv4 or IPv6 address prefix in CIDR notation to a logical switch. Multiple prefixes may map to the same switch. By writing a 32-bit (or 128-bit for v6) address with a /N prefix length, both the router’s interface address and the subnet prefix can be configured. For example, 192.68.1.1/24 creates a /24 subnet for the logical switch attached to the interface and assigns the address 192.68.1.1 to the router interface.

static_routes: map of string-string pairs

One or more static routes, mapping IP prefixes to next hop IP addresses.

acl_binding: map of string-ACL pairs

Maps ACLs to logical router interfaces. The router interfaces are indicated using IP address notation, and must be the same interfaces created in the switch_binding column. For example, an ACL could be associated with the logical router interface with an address of 192.68.1.1 as defined in the example above.

Identification:

name: string (must be unique within table)

Symbolic name for the logical router.

description: string

An extended description for the logical router.

Error Notification:

An entry in this column indicates to the NVC that the HSC has encountered a fault in configuring state related to the logical router.

LR_fault_status : invalid_ACL_binding: none

Indicates that an error has occurred in associating an ACL with a logical router port.

LR_fault_status : unspecified_fault: none

Indicates that an error has occurred in configuring the logical router but that no more specific information is available.

Common Column:

The overall purpose of this column is described under Common Column at the beginning of this document.

other_config: map of string-string pairs

## Arp_Sources_Local TABLE
MAC address to be used when a VTEP issues ARP requests on behalf of a logical router.

A distributed logical router is implemented by a set of VTEPs (both hardware VTEPs and vswitches). In order for a given VTEP to populate the local ARP cache for a logical router, it issues ARP requests with a source MAC address that is unique to the VTEP. A single per-VTEP MAC can be re-used across all logical networks. This table contains the MACs that are used by the VTEPs of a given HSC. The table provides the mapping from MAC to physical locator for each VTEP so that replies to the ARP requests can be sent back to the correct VTEP using the appropriate physical locator.

### Summary:
src_mac

string

locator

Physical_Locator

### Details:
src_mac: string

The source MAC to be used by a given VTEP.

locator: Physical_Locator

The Physical_Locator to use for replies to ARP requests from this MAC address.

## Arp_Sources_Remote TABLE
MAC address to be used when a remote VTEP issues ARP requests on behalf of a logical router.

This table is the remote counterpart of Arp_sources_local. The NVC writes this table to notify the HSC of the MACs that will be used by remote VTEPs when they issue ARP requests on behalf of a distributed logical router.

### Summary:
src_mac

string

locator

Physical_Locator

### Details:
src_mac: string

The source MAC to be used by a given VTEP.

locator: Physical_Locator

The Physical_Locator to use for replies to ARP requests from this MAC address.

## Physical_Locator_Set TABLE
A set of one or more Physical_Locators.

This table exists only because OVSDB does not have a way to express the type ``map from string to one or more Physical_Locator records.’’

### Summary:
locators

immutable set of 1 or more Physical_Locators

### Details:
locators: immutable set of 1 or more Physical_Locators

## Physical_Locator TABLE
Identifies an endpoint to which logical switch traffic may be encapsulated and forwarded.

The vxlan_over_ipv4 encapsulation, the only encapsulation defined so far, can use either tunnel key model described in the ``Per Logical-Switch Tunnel Key’’ section in the Logical_Switch table. When the tunnel key per Logical_Switch model is in use, the tunnel_key column in the Logical_Switch table is filled with a VNI and the tunnel_key column in this table is empty; in the key-per-tunnel model, the opposite is true. The former model is older, and thus likely to be more widely supported. See the ``Per Logical-Switch Tunnel Key’’ section in the Logical_Switch table for further discussion of the model.

### Summary:
encapsulation_type

immutable string, must be vxlan_over_ipv4

dst_ip

immutable string

tunnel_key

optional integer

### Details:
encapsulation_type: immutable string, must be vxlan_over_ipv4

The type of tunneling encapsulation.

dst_ip: immutable string

For vxlan_over_ipv4 encapsulation, the IPv4 address of the VXLAN tunnel endpoint.

We expect that this column could be used for IPv4 or IPv6 addresses in encapsulations to be introduced later.

tunnel_key: optional integer

This column is used only in the tunnel key per Logical_Switch+Physical_Locator model (see above).

For vxlan_over_ipv4 encapsulation, when the Logical_Switch+Physical_Locator model is in use, this column is the VXLAN VNI. It must be in the range 0 to 16,777,215.

## ACL_entry TABLE
Describes the individual entries that comprise an Access Control List.

Each entry in the table is a single rule to match on certain header fields. While there are a large number of fields that can be matched on, most hardware cannot match on arbitrary combinations of fields. It is common to match on either L2 fields (described below in the L2 group of columns) or L3/L4 fields (the L3/L4 group of columns) but not both. The hardware switch controller may log an error if an ACL entry requires it to match on an incompatible mixture of fields.

### Summary:
sequence

integer

L2 fields:

source_mac

optional string

dest_mac

optional string

ethertype

optional string

L3/L4 fields:

source_ip

optional string

source_mask

optional string

dest_ip

optional string

dest_mask

optional string

protocol

optional integer

source_port_min

optional integer

source_port_max

optional integer

dest_port_min

optional integer

dest_port_max

optional integer

tcp_flags

optional integer

tcp_flags_mask

optional integer

icmp_type

optional integer

icmp_code

optional integer

direction

string, either egress or ingress

action

string, either deny or permit

Error Notification:

acle_fault_status : invalid_acl_entry

none

acle_fault_status : unspecified_fault

none

### Details:
sequence: integer

The sequence number for the ACL entry for the purpose of ordering entries in an ACL. Lower numbered entries are matched before higher numbered entries.

L2 fields:

source_mac: optional string

Source MAC address, in the form xx:xx:xx:xx:xx:xx

dest_mac: optional string

Destination MAC address, in the form xx:xx:xx:xx:xx:xx

ethertype: optional string

Ethertype in hexadecimal, in the form 0xAAAA

L3/L4 fields:

source_ip: optional string

Source IP address, in the form xx.xx.xx.xx for IPv4 or appropriate colon-separated hexadecimal notation for IPv6.

source_mask: optional string

Mask that determines which bits of source_ip to match on, in the form xx.xx.xx.xx for IPv4 or appropriate colon-separated hexadecimal notation for IPv6.

dest_ip: optional string

Destination IP address, in the form xx.xx.xx.xx for IPv4 or appropriate colon-separated hexadecimal notation for IPv6.

dest_mask: optional string

Mask that determines which bits of dest_ip to match on, in the form xx.xx.xx.xx for IPv4 or appropriate colon-separated hexadecimal notation for IPv6.

protocol: optional integer

Protocol number in the IPv4 header, or value of the "next header" field in the IPv6 header.

source_port_min: optional integer

Lower end of the range of source port values. The value specified is included in the range.

source_port_max: optional integer

Upper end of the range of source port values. The value specified is included in the range.

dest_port_min: optional integer

Lower end of the range of destination port values. The value specified is included in the range.

dest_port_max: optional integer

Upper end of the range of destination port values. The value specified is included in the range.

tcp_flags: optional integer

Integer representing the value of TCP flags to match. For example, the SYN flag is the second least significant bit in the TCP flags. Hence a value of 2 would indicate that the "SYN" flag should be set (assuming an appropriate mask).

tcp_flags_mask: optional integer

Integer representing the mask to apply when matching TCP flags. For example, a value of 2 would imply that the "SYN" flag should be matched and all other flags ignored.

icmp_type: optional integer

ICMP type to be matched.

icmp_code: optional integer

ICMP code to be matched.

direction: string, either egress or ingress

Direction of traffic to match on the specified port, either "ingress" (toward the logical switch or router) or "egress" (leaving the logical switch or router).

action: string, either deny or permit

Action to take for this rule, either "permit" or "deny".

Error Notification:

An entry in this column indicates to the NVC that the ACL could not be configured as requested. The switch must clear this column when the error has been cleared.

acle_fault_status : invalid_acl_entry: none

Indicates that an ACL entry requested by the controller could not be instantiated by the switch, e.g. because it requires an unsupported combination of fields to be matched.

acle_fault_status : unspecified_fault: none

Indicates that an error has occurred in configuring the ACL entry but no more specific information is available.

## ACL TABLE
Access Control List table. Each ACL is constructed as a set of entries from the ACL_entry table. Packets that are not matched by any entry in the ACL are allowed by default.

### Summary:
acl_entries

set of 1 or more ACL_entrys

acl_name

string (must be unique within table)

Error Notification:

acl_fault_status : invalid_acl

none

acl_fault_status : resource_shortage

none

acl_fault_status : unspecified_fault

none

### Details:
acl_entries: set of 1 or more ACL_entrys

A set of references to entries in the ACL_entry table.

acl_name: string (must be unique within table)

A human readable name for the ACL, which may (for example) be displayed on the switch CLI.

Error Notification:

An entry in this column indicates to the NVC that the ACL could not be configured as requested. The switch must clear this column when the error has been cleared.

acl_fault_status : invalid_acl: none

Indicates that an ACL requested by the controller could not be instantiated by the switch, e.g., because it requires an unsupported combination of fields to be matched.

acl_fault_status : resource_shortage: none

Indicates that an ACL requested by the controller could not be instantiated by the switch due to a shortage of resources (e.g. TCAM space).

acl_fault_status : unspecified_fault: none

Indicates that an error has occurred in configuring the ACL but no more specific information is available.


opieaccess

package: opie

title: opieaccess(5)

summary: OPIE database of trusted networks

text:
# opieaccess(5)

## NAME
[/etc/]opieaccess - OPIE database of trusted networks

## DESCRIPTION
The opieaccess file contains a list of networks that are considered trusted by the system as far as security against passive attacks is concerned. Users from networks so trusted will be able to log in using OPIE responses, but not be required to do so, while users from networks that are not trusted will always be required to use OPIE responses (the default behavior). This trust allows a site to have a more gentle migration to OPIE by allowing it to be non-mandatory for "inside" networks while allowing users to choose whether they with to use OPIE to protect their passwords or not.

The entire notion of trust implemented in the opieaccess file is a major security hole because it opens your system back up to the same passive attacks that the OPIE system is designed to protect you against. The opieaccess support in this version of OPIE exists solely because we believe that it is better to have it so that users who don't want their accounts broken into can use OPIE than to have them prevented from doing so by users who don't want to use OPIE. In any environment, it should be considered a transition tool and not a permanent fixture. When it is not being used as a transition tool, a version of OPIE that has been built without support for the opieaccess file should be built to prevent the possibility of an attacker using this file as a means to circumvent the OPIE software.

The opieaccess file consists of lines containing three fields separated by spaces (tabs are properly interpreted, but spaces should be used instead) as follows:

```
Field	Description
action	"permit" or "deny" non-OPIE logins
address	Address of the network to match
mask	Mask of the network to match
```

Subnets can be controlled by using the appropriate address and mask. Individual hosts can be controlled by using the appropriate address and a mask of 255.255.255.255. If no rules are matched, the default is to deny non-OPIE logins.

## SEE ALSO
opie(4), opiekeys(5), opiepasswd(1), opieinfo(1), opiesu(1), opielogin(1), opieftpd(8)

## AUTHOR
Bellcore's S/Key was written by Phil Karn, Neil M. Haller, and John S. Walden of Bellcore. OPIE was created at NRL by Randall Atkinson, Dan McDonald, and Craig Metz.

S/Key is a trademark of Bell Communications Research (Bellcore).

## CONTACT
OPIE is discussed on the Bellcore "S/Key Users" mailing list. To join, send an email request to:

skey-users-request@thumper.bellcore.com


opiekeys

title: opiekeys(5)

summary: OPIE database of user key information

text:
# opiekeys(5)

## NAME
[/etc/]opiekeys - OPIE database of user key information

## DESCRIPTION
The opiekeys file contains user information used by the OPIE software to authenticate users. The opiekeys file is backwards compatible with the S/Key /etc/skeykeys database file, but only if the hashing algorithm (MD4 and MD5) is the same between S/Key and OPIE (i.e., MD5 OPIE cannot use MD4 S/Key keys). The opiekeys file consists of six fields separated by spaces (tabs are properly interpreted, but spaces should be used instead) as follows:

```
Field   	Description
name    	User's login name.
sequence	User's sequence number.
seed    	User's seed.
key     	User's last response (hex).
date    	Last change date.
time    	Last change time.
```

## SEE ALSO
opie(4), opiekeys(5), opiepasswd(1), opieinfo(1), opiesu(1), opielogin(1), opieftpd(8)

## AUTHOR
Bellcore's S/Key was written by Phil Karn, Neil M. Haller, and John S. Walden of Bellcore. OPIE was created at NRL by Randall Atkinson, Dan McDonald, and Craig Metz.

S/Key is a trademark of Bell Communications Research (Bellcore).

## CONTACT
OPIE is discussed on the Bellcore "S/Key Users" mailing list. To join, send an email request to:

skey-users-request@thumper.bellcore.com


oroborusrc

package: oroborus

title: oroborusrc(5)

summary: oroborus(1) configuration file.

text:
# oroborusrc(5)

## NAME
oroborusrc - oroborus(1) configuration file.

## DESCRIPTION
The Oroborusrc is the main configuration file for oroborus(1).

You can have an /usr/share/oroborus/defaults for the global configuration of oroborus(1) andan $HOME/.oroborusrc for a per user configuration of oroborus(1).

## SEE ALSO
oroborus(1) deskmenu(1) desklaunch(1) keylaunch(1) idesk(1) dfm(1)

## AUTHOR
This manual page was written by Stefan Pfetzing <dreamind@dreamind.de>.


ostree.repo

package: ostree

title: ostree.repo(5)

text:
# ostree.repo(5)

## NAME
ostree.repo - OSTree repository configuration and layout

## DESCRIPTION
An OSTree repository is structurally similar to a git repository; it is a content-addressed object store containing filesystem trees. However, unlike git, ostree is designed to store operating system binaries. It records the Unix uid and gid, permissions, as well as extended attributes.

A repository can be in one of three modes; bare, which is designed as a hard link source for operating system checkouts, bare-user, which is like bare but works on systems that run as non-root as well as non-root containers, and archive-z2, which is designed for static HTTP servers.

There is a system repository located at /ostree/repo. If no repository is specified -- either by a command-line option or the OSTREE_REPO environment variable -- the ostree as well as many API calls will use it by default.

## COMPONENTS OF A REPOSITORY
The only user-editable component is the config file. For more information, see ostree.repo-config(5).

## SEE ALSO
ostree(1), ostree.repo-config(1)


ostree.repo-config

title: ostree.repo-config(5)

summary: OSTree repository configuration

text:
# ostree.repo-config(5)

## NAME
ostree.repo-config - OSTree repository configuration

## DESCRIPTION
The config file in an OSTree repository is a "keyfile" in the XDG Desktop Entry Specification[1] format. It has several global flags, as well as zero or more remote entries which describe how to access remote repositories.

See ostree.repo(5) for more information about OSTree repositories.

## [CORE] SECTION OPTIONS
Repository-global options. The following entries are defined:

mode

One of bare, bare-user, bare-user-only, or archive-z2 (note that archive is used everywhere else.)

repo_version

Currently, this must be set to 1.

auto-update-summary

Boolean value controlling whether or not to automatically update the summary file after any ref is added, removed, or updated. Other modifications which may render a summary file stale (like static deltas, or collection IDs) do not currently trigger an auto-update.

commit-update-summary

This option is deprecated. Use auto-update-summary instead, for which this option is now an alias.

fsync

Boolean value controlling whether or not to ensure files are on stable storage when performing operations such as commits, pulls, and checkouts. Defaults to true. If you disable fsync, OSTree will no longer be robust against kernel crashes or power loss.

You might choose to disable this for local development repositories, under the assumption they can be recreated from source. Similarly, you could disable for a mirror where you could re-pull.

For the system repository, you might choose to disable fsync if you have uninterruptable power supplies and a well tested kernel.

per-object-fsync

By default, OSTree will batch fsync() after writing everything; however, this can cause latency spikes for other processes which are also invoking fsync(). Turn on this boolean to reduce potential latency spikes, at the cost of slowing down OSTree updates. You most likely want this on by default for "background" OS updates.

min-free-space-percent

Integer percentage value (0-99) that specifies a minimum percentage of total space (in blocks) in the underlying filesystem to keep free. The default value is 3, which is enforced when neither this option nor min-free-space-size are set. If min-free-space-size is set to a non-zero value, min-free-space-percent is ignored. Note that, min-free-space-percent is not enforced on metadata objects. It is assumed that metadata objects are relatively small in size compared to content objects and thus kept outside the scope of this option.

min-free-space-size

Value (in power-of-2 MB, GB or TB) that specifies a minimum space in the underlying filesystem to keep free. Examples of acceptable values: 500MB (524 288 000 bytes), 1GB (1 073 741 824 bytes), 1TB (1 099 511 627 776 bytes). If this option is set to a non-zero value, and min-free-space-percent is also set, this option takes priority. Note that, min-free-space-size is not enforced on metadata objects. It is assumed that metadata objects are relatively small in size compared to content objects and thus kept outside the scope of this option.

add-remotes-config-dir

Boolean value controlling whether new remotes will be added in the remotes configuration directory. Defaults to true for system ostree repositories. When this is false, remotes will be added in the repository's config file. This only applies to repositories that use a remotes configuration directory such as system ostree repositories, which use /etc/ostree/remotes.d. Non-system repositories do not use a remotes configuration directory unless one is specified when the repository is opened.

payload-link-threshold

An integer value that specifies a minimum file size for creating a payload link. By default it is disabled.

collection-id

A reverse DNS domain name under your control, which enables peer to peer distribution of refs in this repository. See the --collection-id section in ostree-init(1)

locking

Boolean value controlling whether or not OSTree does repository locking internally. This uses file locks and is hence for multiple process exclusion (e.g. Flatpak and OSTree writing to the same repository separately). This is enabled by default since 2018.5.

lock-timeout-secs

Integer value controlling the number of seconds to block while attempting to acquire a lock (see above). A value of -1 means block indefinitely. The default value is 300. This timeout is now regarded as a mistake; because it's likely to cause flakes. It's recommended to set it to -1, and have timeouts at a higher application level if desired.

default-repo-finders

Semicolon separated default list of finders (sources for refs) to use when pulling. This can be used to disable pulling from mounted filesystems, peers on the local network, or the Internet. However note that it only applies when a set of finders isn't explicitly specified, either by a consumer of libostree API or on the command line. Possible values: config, lan, and mount (or any combination thereof). If unset, this defaults to config;mount; (since the LAN finder is costly).

no-deltas-in-summary

Boolean value controlling whether OSTree should skip putting an index of available deltas in the summary file. Defaults to false. Since 2020.7 OSTree can use delta indexes outside the summary file, making the summary file smaller (especially for larger repositories). However by default we still create the index in the summary file to make older clients work. If you know all clients will be 2020.7 later you can enable this to save network bandwidth.

## [REMOTE NAME"] SECTION OPTIONS"
Describes a remote repository location.

url

Must be present; declares URL for accessing metadata and content for remote. See also contenturl. The supported schemes are documented below.

contenturl

Declares URL for accessing content (filez, static delta parts). When specified, url is used just for metadata: summary, static delta "superblocks".

branches

A list of strings. Represents the default configured branches to fetch from the remote when no specific branches are requested during a pull operation.

proxy

A string value, if given should be a URL for a HTTP proxy to use for access to this repository.

gpg-verify

A boolean value, defaults to true. Controls whether or not OSTree will require commits to be signed by a known GPG key. For more information, see the ostree(1) manual under GPG.

gpg-verify-summary

A boolean value, defaults to false. Controls whether or not OSTree will check if the summary is signed by a known GPG key. For more information, see the ostree(1) manual under GPG.

tls-permissive

A boolean value, defaults to false. By default, server TLS certificates will be checked against the system certificate store. If this variable is set, any certificate will be accepted.

tls-client-cert-path

Path to file for client-side certificate, to present when making requests to this repository.

tls-client-key-path

Path to file containing client-side certificate key, to present when making requests to this repository.

tls-ca-path

Path to file containing trusted anchors instead of the system CA database.

http2

A boolean value, defaults to true. By default, libostree will use HTTP2; setting this to false will disable it. May be useful to work around broken servers.

unconfigured-state

If set, pulls from this remote will fail with the configured text. This is intended for OS vendors which have a subscription process to access content.

custom-backend

If set, pulls from this remote via libostree will fail with an error that mentions the value. It is recommended to make this a software identifier token (e.g. "examplecorp-fetcher"), not freeform text ("ExampleCorp Fetcher"). This is intended to be used by higher level software that wants to fetch ostree commits via some other mechanism, while still reusing the core libostree infrastructure around e.g. signatures.

## [SYSROOT] SECTION OPTIONS
Options for the sysroot, which contains the OSTree repository, deployments, and stateroots. The following entries are defined:

readonly

A boolean value. If this is set to true, then the /sysroot mount point is mounted read-only. This is configured a legacy repository configuration and the equivalent option in ostree/prepare-root.conf should be used instead - see ostree-prepare-root(1).

bootloader

Configure the bootloader that OSTree uses when deploying the sysroot. This may take the values bootloader=none, bootloader=auto, bootloader=grub2, bootloader=syslinux, bootloader=uboot or bootloader=zipl. Default is auto. If none, then OSTree will generate only BLS (Boot Loader Specification) fragments in sysroot/boot/loader/entries/ for the deployment.

If auto, then in addition to generating BLS fragments, OSTree will dynamically check for the existence of grub2, uboot, and syslinux bootloaders. If one of the bootloaders is found, then OSTree will generate a config for the bootloader found. For example, grub2-mkconfig is run for the grub2 case.

A specific bootloader type may also be explicitly requested by choosing grub2, syslinux, uboot or zipl.

bls-append-except-default

A semicolon separated string list of key-value pairs. For example: bls-append-except-default=key1=value1;key2=value2. These key-value pairs will be injected into the generated BLS fragments of the non-default deployments. In other words, the BLS fragment of the default deployment will be unaffected by bls-append-except-default.

bootprefix

A boolean value; defaults to false. If set to true, the bootloader entries generated will include /boot as a prefix. This will likely be turned on by default in the future.

## [EX-INTEGRITY] SECTION OPTIONS
The "ex-" prefix here signifies experimental options. The ex-integrity section contains options related to system integrity. Information about experimental options is canonically found in upstream tracking issues.

## /ETC/OSTREE/REMOTES.D
In addition to the /ostree/repo/config file, remotes may also be specified in /etc/ostree/remotes.d. The remote configuration file must end in .conf; files whose name does not end in .conf will be ignored.

## REPOSITORY URL/CONTENTURL
Originally, OSTree had just a url option for remotes. Since then, the contenturl option was introduced. Both of these support file, http, and https schemes.

Additionally, both of these can be prefixed with the string mirrorlist=, which instructs the client that the target url is a "mirrorlist" format, which is a plain text file of newline-separated URLs. Earlier URLs will be given precedence.

Note that currently, the tls-ca-path and tls-client-cert-path options apply to every HTTP request, even when contenturl and/or mirrorlist are in use. This may change in the future to only apply to metadata (i.e. url, not contenturl) fetches.

## PER-REMOTE GPG KEYRINGS AND VERIFICATION
OSTree supports a per-remote GPG keyring, as well as a gpgkeypath option. For more information see ostree(1). in the section GPG verification.

## PER-REMOTE HTTP COOKIES
Some content providers may want to control access to remote repositories via HTTP cookies. The ostree remote add-cookie and ostree remote delete-cookie commands will update a per-remote lookaside cookie jar, named $remotename.cookies.txt.

## SEE ALSO
ostree(1), ostree.repo(5)

## NOTES
1.

XDG Desktop Entry Specification

http://standards.freedesktop.org/desktop-entry-spec/latest/


ovn-ic-nb

package: ovn

title: ovn-ic-nb(5)

summary: OVN_IC_Northbound database schema

text:
# ovn-ic-nb(5)

## NAME
ovn-ic-nb - OVN_IC_Northbound database schema

This database is the interface for cloud management system (CMS), such as OpenStack, to configure OVN interconnection settings. The CMS produces almost all of the contents of the database. The ovn-ic program monitors the database contents, transforms it, and stores it into the OVN_IC_Southbound database.

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

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

external_ids: map of string-string pairs

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

## TABLE SUMMARY
The following list summarizes the purpose of each of the tables in the OVN_IC_Northbound database. Each table is described in more detail on a later page.

Table

Purpose

IC_NB_Global

IC Northbound configuration

Transit_Switch

Transit logical switch

SSL

SSL configuration.

Connection

OVSDB client connections.

## IC_NB_Global TABLE
Northbound configuration for OVN interconnection. This table must have exactly one row.

### Summary:
Common Columns:

external_ids

map of string-string pairs

Common options:

options

map of string-string pairs

Connection Options:

connections

set of Connections

ssl

optional SSL

### Details:
Common Columns:

external_ids: map of string-string pairs

See External IDs at the beginning of this document.

Common options:

options: map of string-string pairs

This column provides general key/value settings. The supported options are described individually below.

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

## Transit_Switch TABLE
Each row represents one transit logical switch for interconnection between different OVN deployments (availability zones).

### Summary:
Naming:

name

string (must be unique within table)

Common Columns:

other_config

map of string-string pairs

external_ids

map of string-string pairs

### Details:
Naming:

name: string (must be unique within table)

A name that uniquely identifies the transit logical switch.

Common Columns:

other_config: map of string-string pairs

external_ids: map of string-string pairs

See External IDs at the beginning of this document.

## SSL TABLE
SSL configuration for ovn-nb database access.

### Summary:
private_key

string

certificate

string

ca_cert

string

bootstrap_ca_cert

boolean

ssl_protocols

string

ssl_ciphers

string

Common Columns:

external_ids

map of string-string pairs

### Details:
private_key: string

Name of a PEM file containing the private key used as the switch’s identity for SSL connections to the controller.

certificate: string

Name of a PEM file containing a certificate, signed by the certificate authority (CA) used by the controller and manager, that certifies the switch’s private key, identifying a trustworthy switch.

ca_cert: string

Name of a PEM file containing the CA certificate used to verify that the switch is connected to a trustworthy controller.

bootstrap_ca_cert: boolean

If set to true, then Open vSwitch will attempt to obtain the CA certificate from the controller on its first SSL connection and save it to the named PEM file. If it is successful, it will immediately drop the connection and reconnect, and from then on all SSL connections must be authenticated by a certificate signed by the CA certificate thus obtained. This option exposes the SSL connection to a man-in-the-middle attack obtaining the initial CA certificate. It may still be useful for bootstrapping.

ssl_protocols: string

List of SSL protocols to be enabled for SSL connections. The default when this option is omitted is TLSv1,TLSv1.1,TLSv1.2.

ssl_ciphers: string

List of ciphers (in OpenSSL cipher string format) to be supported for SSL connections. The default when this option is omitted is HIGH:!aNULL:!MD5.

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

## Connection TABLE
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.

### 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:

ssl:host[:port]

The specified SSL port on the host at 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.

SSL support is an optional feature that is not always built as part of Open vSwitch.

tcp:host[:port]

The specified TCP port on the host at the given host, which can either be a DNS name (if built with unbound library) or an IP address. 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 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 IPaddress (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 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.

SSL support is an optional feature that is not always built as part of 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.

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:

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.

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.

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.

external_ids: map of string-string pairs

other_config: map of string-string pairs