ovn-controller8

The chassis name to use in the Chassis table. Changing the system-id while ovn-controller is running is not directly supported. Users have two options: either first gracefully stop ovn-controller or manually delete the stale Chassis and Chassis_Private records after changing the system-id. Note that the chassis name can also be provided via the system-id-override file in the local OVN "etc" directory or via the -n command-line option. The following precedence is used: first, the command-line option is read; if not present, the system-id-override file is read; if not present, then the name configured in the database is used.

The hostname to use in the Chassis table.

The integration bridge to which logical ports are attached. The default is br-int. If this bridge does not exist when ovn-controller starts, it will be created automatically with the default configuration suggested in ovn-architecture(7). When more than one controllers are running on the same host, external_ids:ovn-bridge-CHASSIS_NAME should be set for each of them, pointing to a unique bridge. This is required to avoid controllers stepping on each others’ feet.

This configuration is optional. If set, then the datapath type of the integration bridge will be set to the configured value. If this option is not set, then ovn-controller will not modify the existing datapath-type of the integration bridge.

The OVN database that this system should connect to for its configuration, in one of the same forms documented above for the ovs-database.

A boolean value that tells if ovn-controller should monitor all records of tables in the OVN_Southbound. If this option is set to false, ovn-controller will conditionally monitor only the records that are needed for the local chassis.

It is more efficient to set it to true in use cases where the chassis would anyway need to monitor most of the records in the OVN_Southbound database, which would save the overhead of conditions processing, especially for server side. Typically, set it to true for environments where all workloads need to be reachable from each other.

NOTE: for efficiency and scalability in common scenarios ovn-controller unconditionally monitors all sub-ports (ports with parent_port set) regardless of the ovn-monitor-all value.

Default value is false.

The inactivity probe interval of the connection to the OVN database, in milliseconds. If the value is zero, it disables the connection keepalive feature.

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

The encapsulation type that a chassis should use to connect to this node. Multiple encapsulation types may be specified with a comma-separated list. Each listed encapsulation type will be paired with ovn-encap-ip.

Supported tunnel types for connecting hypervisors and gateways are geneve, vxlan, and stt.

stt tunnel type is deprecated.

Due to the limited amount of metadata in vxlan, the capabilities and performance of connected gateways and hypervisors will be reduced versus other tunnel formats.

The IP address that a chassis should use to connect to this node using encapsulation types specified by external_ids:ovn-encap-type. Multiple encapsulation IPs may be specified with a comma-separated list.

In scenarios where multiple encapsulation IPs are present, distinct tunnels are established for each remote chassis. These tunnels are differentiated by setting unique options:local_ip and options:remote_ip values in the tunnel interface. When transmitting a packet to a remote chassis, the selection of local_ip is guided by the Interface:external_ids:encap-ip from the local OVSDB, corresponding to the VIF originating the packet, if specified. The Interface:external_ids:encap-ip setting of the VIF is also populated to the Port_Binding table in the OVN SB database via the encap column. Consequently, when a remote chassis needs to send a packet to a port-binding associated with this VIF, it utilizes the tunnel with the appropriate options:remote_ip that matches the ip in Port_Binding:encap. This mechanism is particularly beneficial for chassis with multiple physical interfaces designated for tunneling, where each interface is optimized for handling specific traffic associated with particular VIFs.

When ovn-encap-ip contains multiple IPs, this field indicates the default one.

indicates the DF flag handling of the encapulation. Set to true to set the DF flag for new data paths or false to clear the DF flag.

A list of key-value pairs that map a physical network name to a local ovs bridge that provides connectivity to that network. An example value mapping two physical network names to two ovs bridges would be: physnet1:br-eth0,physnet2:br-eth1.

ovn-encap-csum indicates that encapsulation checksums can be transmitted and received with reasonable performance. It is a hint to senders transmitting data to this chassis that they should use checksums to protect OVN metadata. Set to true to enable or false to disable. Depending on the capabilities of the network interface card, enabling encapsulation checksum may incur performance loss. In such cases, encapsulation checksums can be disabled.

ovn-encap-tos indicates the value to be applied to OVN tunnel interface’s option:tos as specified in the Open_vSwitch database Interface table. Please refer to Open VSwitch Manual for details.

A list of options that will be consumed by the CMS Plugin and which specific to this particular chassis. An example would be: cms_option1,cms_option2:foo.

The transport zone(s) that this chassis belongs to. Transport zones is a way to group different chassis so that tunnels are only formed between members of the same group(s). Multiple transport zones may be specified with a comma-separated list. For example: tz1,tz2,tz3.

If not set, the Chassis will be considered part of a default transport zone.

A list of key-value pairs that map a chassis specific mac to a physical network name. An example value mapping two chassis macs to two physical network names would be: physnet1:aa:bb:cc:dd:ee:ff,physnet2:a1:b2:c3:d4:e5:f6. These are the macs that ovn-controller will replace a router port mac with, if packet is going from a distributed router port on vlan type logical switch.

The boolean flag indicates if the chassis is used as an interconnection gateway.

The boolean flag indicates if ovn-controller needs to check ovn-northd version. If this flag is set to true and the ovn-northd’s version (reported in the Southbound database) doesn’t match with the ovn-controller’s internal version, then it will stop processing the southbound and local Open vSwitch database changes. The default value is considered false if this option is not defined.

The time, in milliseconds, to wait before clearing flows in OVS after OpenFlow connection/reconnection during ovn-controller initialization. The purpose of this wait is to give time for ovn-controller to compute the new flows before clearing existing ones, to avoid data plane down time during ovn-controller restart/upgrade at large scale environments where recomputing the flows takes more than a few seconds or even longer. It is difficult for ovn-controller to determine when the new flows computing is completed, because of the dynamics in the cloud environments, which is why this configuration is provided for users to adjust based on the scale of the environment. By default, it is 0, which means clearing existing flows without waiting. Not setting the value, or setting it too small, may result in data plane down time during upgrade/restart, while setting it too big may result in unnecessary extra control plane latency of applying new changes of CMS during upgrade/restart. In most cases, a slightly bigger value is not harmful, because the extra control plane latency happens only once during the OpenFlow connection. To get a reasonable range of the value setting, it is recommended to run the below commands on a node in the target environment and then set this configuration to twice the value of Maximum shown in the output of the second command.

The boolean flag indicates if ovn-controller should enable/disable the logical flow in-memory cache it uses when processing Southbound database logical flow changes. By default caching is enabled.

When used, this configuration value determines the maximum number of logical flow cache entries ovn-controller may create when the logical flow cache is enabled. By default the size of the cache is unlimited.

When used, this configuration value determines the maximum size of the logical flow cache (in KB) ovn-controller may create when the logical flow cache is enabled. By default the size of the cache is unlimited.

When used, this configuration value sets the minimum number of entries in the logical flow cache starting with which automatic memory trimming is performed. By default this is set to 10000 entries.

When used, this configuration value sets the percentage from the high watermark number of entries in the logical flow cache under which automatic memory trimming is performed. E.g., if the trim watermark percentage is set to 50%, automatic memory trimming happens only when the number of entries in the logical flow cache gets reduced to less than half of the last measured high watermark. By default this is set to 50.

When used, this configuration value specifies the time, in milliseconds, since the last logical flow cache operation after which ovn-controller performs memory trimming regardless of how many entries there are in the cache. By default this is set to 30000 (30 seconds).

When used, this configuration value specifies the maximum timeout (in seconds) between two consecutive GARP packets sent by ovn-controller. ovn-controller by default sends just 4 GARP packets with an exponential backoff timeout. Setting external_ids:garp-max-timeout-sec allows to cap for the exponential backoff used by ovn-controller to send GARPs packets.

When used, this configuration value specifies the maximum timeout (in seconds) between two consecutive ARP/ND packets sent by ovn-controller to resolve ECMP nexthop mac address. ovn-controller by default continuously sends ARP/ND packets. Setting external_ids:arp-nd-max-timeout-sec allows to cap for the exponential backoff used by ovn-controller to send ARPs/NDs packets.

Connection to the OVN management bridge in OvS. It defaults to unix:br-int.mgmt when not specified.

The inactivity probe interval of the connection to the OVN management bridge, in milliseconds. It defaults to zero. If the value is zero, it disables the inactivity probe.

This setting works together with the Northbound dynamic-routing-port-name option on Logical_Router_Ports. See the ovn-nb(5) for more details.

This value is read from local OVS integration bridge row of Bridge table and populated in other_config:datapath-type of the Chassis table in the OVN_Southbound database.

This value is populated in external_ids:iface-types of the Chassis table in the OVN_Southbound database.

These values provide the SSL/TLS configuration used for connecting to the OVN southbound database server when an SSL/TLS connection type is configured via external_ids:ovn-remote. Note that this SSL/TLS configuration can also be provided via command-line options, the configuration in the database takes precedence if both are present.

The presence of this key identifies a tunnel port within the integration bridge as one created by ovn-controller to reach a remote chassis. Its value is the chassis ID of the remote chassis.

The presence of this key identifies a minimum and maximum values for ct-zone ids dynamically selected by ovn-controller (boundaries are included in the range). Minimum value is 1 while maximum value is 65535.

Logical ports and gateway routers are assigned a connection tracking zone by ovn-controller for stateful services. To keep state across restarts of ovn-controller, these keys are stored in the integration bridge’s Bridge table. The name contains a prefix of ct-zone- followed by the name of the logical port or gateway router’s zone key. The value for this key identifies the zone used for this port.

The presence of this key identifies a patch port as one created by ovn-controller to connect the integration bridge and another bridge to implement a localnet logical port. Its value is the name of the logical port with type set to localnet that the port implements. See external_ids:ovn-bridge-mappings, above, for more information.

Each localnet logical port is implemented as a pair of patch ports, one in the integration bridge, one in a different bridge, with the same external_ids:ovn-localnet-port value.

The presence of this key identifies a patch port as one created by ovn-controller to connect the integration bridge and another bridge to implement a l2gateway logical port. Its value is the name of the logical port with type set to l2gateway that the port implements. See external_ids:ovn-bridge-mappings, above, for more information.

Each l2gateway logical port is implemented as a pair of patch ports, one in the integration bridge, one in a different bridge, with the same external_ids:ovn-l2gateway-port value.

This key identifies a patch port as one created by ovn-controller to implement a l3gateway logical port. Its value is the name of the logical port with type set to l3gateway. This patch port is similar to the OVN logical patch port, except that l3gateway port can only be bound to a particular chassis.

This key identifies a patch port as one created by ovn-controller to implement an OVN logical patch port within the integration bridge. Its value is the name of the OVN logical patch port that it implements.

This key represents the timestamp (in milliseconds) at which ovn-controller process was started.

This key represents the last known OVN_Southbound.SB_Global.nb_cfg value for which all flows have been successfully installed in OVS.

This key represents the timestamp (in milliseconds) of the last known OVN_Southbound.SB_Global.nb_cfg value for which all flows have been successfully installed in OVS.

This key is set after all openflow operations corresponding to the OVS interface have been processed by ovs-vswitchd. At the same time a timestamp, in milliseconds since the epoch, is stored in external_ids:ovn-installed-ts.

Upon startup, ovn-controller creates a row in this table to represent its own chassis. Upon graceful termination, e.g. with ovs-appctl -t ovn-controller exit (but not SIGTERM), ovn-controller removes its row.

Upon startup, ovn-controller creates a row or rows in this table that represent the tunnel encapsulations by which its chassis can be reached, and points its Chassis row to them. Upon graceful termination, ovn-controller removes these rows.

At runtime, ovn-controller sets the chassis columns of ports that are resident on its chassis to point to its Chassis row, and, conversely, clears the chassis column of ports that point to its Chassis row but are no longer resident on its chassis. The chassis column has a weak reference type, so when ovn-controller gracefully exits and removes its Chassis row, the database server automatically clears any remaining references to that row.

At runtime, ovn-controller updates the MAC_Binding table as instructed by put_arp and put_nd logical actions. These changes persist beyond the lifetime of ovn-controller.

Causes ovn-controller to gracefully terminate.

Lists each local logical port and its connection tracking zone.

Lists each meter table entry and its local meter id.

Lists each group table entry and its local group id.

Injects microflow into the connected Open vSwitch instance. microflow must contain an ingress logical port (inport argument) that is present on the Open vSwitch instance.

The microflow argument describes the packet whose forwarding is to be simulated, in the syntax of an OVN logical expression, as described in ovn-sb(5), to express constraints. The parser understands prerequisites; for example, if the expression refers to ip4.src, there is no need to explicitly state ip4 or eth.type == 0x800.

Show OVN SBDB connection status for the chassis.

Trigger a full compute iteration in ovn-controller based on the contents of the Southbound database and local OVS database.

This command is intended to use only in the event of a bug in the incremental processing engine in ovn-controller to avoid inconsistent states. It should therefore be used with care as full recomputes are cpu intensive.

Reset southbound database cluster status when databases are destroyed and rebuilt.

If all databases in a clustered southbound database are removed from disk, then the stored index of all databases will be reset to zero. This will cause ovn-controller to be unable to read or write to the southbound database, because it will always detect the data as stale. In such a case, run this command so that ovn-controller will reset its local index so that it can interact with the southbound database again.

This command is used to delay ovn-controller updating the nb_cfg back to OVN_Southbound database. This is useful when ovn-nbctl --wait=hv is used to measure end-to-end latency in a large scale environment. See ovn-nbctl(8) for more details.

Flushes the ovn-controller logical flow cache.

Displays logical flow cache statistics: enabled/disabled, per cache type entry counts.

Display ovn-controller engine counters. For each engine node the following counters have been added:

Display the ovn-controller engine counter(s) for the specified engine_node_name. counter_name is optional and can be one of recompute, compute or cancel.

Reset ovn-controller engine counters.