- routing table and if Logical Routers have more than one Transit
+ routing table and if Logical Routers have more than one Transit
Switch, which interconnects them, directly-connected routes will
be added via each transit switch port and configured as ECMP
routes.
Static routes within route tables will be advertised and learned
- only if interconnecting transit switch’s LRPs will have same
- value in options:route_table as NB route_table or ICSB route_ta‐
+ only if interconnecting transit switch’s LRPs will have same
+ value in options:route_table as NB route_table or ICSB route_ta‐
ble value respectively.
ip_prefix: string
@@ -327,7 +345,7 @@ Route TABLE
origin: string, either connected or static
Can be one of connected or static. Routes to directly-connected
- subnets - LRP’s CIDRs are inserted to OVN IC SB DB with con‐
+ subnets - LRP’s CIDRs are inserted to OVN IC SB DB with con‐
nected value in origin. Static routes are inserted to OVN IC SB
DB with static value. Next when route is learned to another AZ
NB DB by ovn-ic, route origin is synced to options:origin.
@@ -383,9 +401,9 @@ Connection TABLE
The following connection methods are currently supported:
ssl:host[:port]
- The specified SSL port on the given host, which can
- either be a DNS name (if built with unbound library) or
- an IP address. A valid SSL configuration must be provided
+ The specified SSL port on the given host, which can ei‐
+ ther 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 speci‐
fied via command-line options or the SSL table.
@@ -395,9 +413,9 @@ Connection TABLE
built as part of Open vSwitch.
tcp:host[:port]
- The specified TCP port on the given host, which can
- either be a DNS name (if built with unbound library) or
- an IP address (IPv4 or IPv6). If host is an IPv6 address,
+ The specified TCP port on the given host, which can ei‐
+ ther be a DNS name (if built with unbound library) or an
+ IP address (IPv4 or IPv6). If host is an IPv6 address,
wrap it in square brackets, e.g. tcp:[::1]:6640.
If port is not specified, it defaults to 6640.
@@ -406,42 +424,42 @@ Connection TABLE
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
+ DNS name (if built with unbound library) or an IP ad‐
+ dress, is specified, then connections are restricted to
the resolved or specified local IP address (either IPv4
or IPv6 address). If host is an IPv6 address, wrap in
square brackets, e.g. pssl:6640:[::1]. If host is not
- specified then it listens only on IPv4 (but not IPv6)
- addresses. A valid SSL configuration must be provided
- when this form is used, this can be specified either via
- command-line options or the SSL table.
+ specified then it listens only on IPv4 (but not IPv6) ad‐
+ dresses. A valid SSL configuration must be provided when
+ this form is used, this can be specified either via com‐
+ mand-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
+ 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. Spec‐
+ Listens for connections on the specified TCP port. Spec‐
ify 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.
+ specified, then connections are restricted to the re‐
+ solved 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
+ 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.
+ Maximum number of milliseconds to wait between connection at‐
+ tempts. Default is implementation-specific.
inactivity_probe: optional integer
Maximum number of milliseconds of idle time on connection to the
@@ -472,10 +490,10 @@ Connection TABLE
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
+ 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,
+ status : state: optional string, one of ACTIVE, BACKOFF, CONNECTING,
IDLE, or VOID
The state of the connection to the manager:
@@ -494,13 +512,13 @@ Connection TABLE
These values may change in the future. They are provided only
for human consumption.
- status : sec_since_connect: optional string, containing an integer, at
+ 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,
+ 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 dis‐
@@ -521,11 +539,11 @@ Connection TABLE
nection 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
+ 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 con‐
- nection is actually active, the value is the number of active
+ When target specifies a connection method that listens for in‐
+ bound connections (e.g. ptcp: or pssl:) and more than one con‐
+ nection 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
@@ -542,7 +560,6 @@ Connection TABLE
external_ids: map of string-string pairs
other_config: map of string-string pairs
-
SSL TABLE
SSL configuration for ovn-sb database access.
@@ -564,27 +581,27 @@ SSL TABLE
certificate: string
Name of a PEM file containing a certificate, signed by the cer‐
tificate authority (CA) used by the controller and manager, that
- certifies the switch’s private key, identifying a trustworthy
+ 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
+ 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 bootstrap‐
+ 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 im‐
+ mediately 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 bootstrap‐
ping.
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.
+ List of SSL protocols to be enabled for SSL connections. The de‐
+ fault when this option is omitted is TLSv1,TLSv1.1,TLSv1.2.
ssl_ciphers: string
List of ciphers (in OpenSSL cipher string format) to be sup‐
@@ -598,6 +615,4 @@ SSL TABLE
external_ids: map of string-string pairs
-
-
-Open vSwitch 22.12.90 DB Schema 1.1.1 ovn-ic-sb(5)
+Open vSwitch 24.03.90 DB Schema 1.2.0 ovn-ic-sb(5)
diff --git a/src/static/support/dist-docs/ovn-ic-sbctl.8 b/src/static/support/dist-docs/ovn-ic-sbctl.8
index 806add34..d5a8dc3c 100644
--- a/src/static/support/dist-docs/ovn-ic-sbctl.8
+++ b/src/static/support/dist-docs/ovn-ic-sbctl.8
@@ -1,6 +1,6 @@
'\" p
.\" -*- nroff -*-
-.TH "ovn-ic-sbctl" 8 "ovn-ic-sbctl" "OVN 22\[char46]12\[char46]90" "OVN Manual"
+.TH "ovn-ic-sbctl" 8 "ovn-ic-sbctl" "OVN 24\[char46]03\[char46]90" "OVN Manual"
.fp 5 L CR \\" Make fixed-width font available as \\fL.
.de TQ
. br
diff --git a/src/static/support/dist-docs/ovn-ic-sbctl.8.html b/src/static/support/dist-docs/ovn-ic-sbctl.8.html
index d5aef46d..6b5642f4 100644
--- a/src/static/support/dist-docs/ovn-ic-sbctl.8.html
+++ b/src/static/support/dist-docs/ovn-ic-sbctl.8.html
@@ -1,7 +1,5 @@
-ovn-ic-sbctl(8) OVN Manual ovn-ic-sbctl(8)
-
-
+ovn-ic-sbctl(8) OVN Manual ovn-ic-sbctl(8)
NAME
ovn-ic-sbctl - Open Virtual Network interconnection southbound db man‐
@@ -19,7 +17,7 @@
already been initialized, this command has no effect.
show [availability_zone]
- Prints a brief overview of the database contents. If availabil‐
+ Prints a brief overview of the database contents. If availabil
ity_zone is provided, only records related to that availability
zone are shown.
@@ -32,17 +30,17 @@
Each of these commands has a table parameter to identify a table within
the database. Many of them also take a record parameter that identifies
- a particular record within a table. The record parameter may be the
- UUID for a record, which may be abbreviated to its first 4 (or more)
- hex digits, as long as that is unique. Many tables offer additional
- ways to identify records. Some commands also take column parameters
+ a particular record within a table. The record parameter may be the
+ UUID for a record, which may be abbreviated to its first 4 (or more)
+ hex digits, as long as that is unique. Many tables offer additional
+ ways to identify records. Some commands also take column parameters
that identify a particular field within the records in a table.
For a list of tables and their columns, see ovn-ic-sb(5) or see the ta‐
ble listing from the --help option.
Record names must be specified in full and with correct capitalization,
- except that UUIDs may be abbreviated to their first 4 (or more) hex
+ except that UUIDs may be abbreviated to their first 4 (or more) hex
digits, as long as that is unique within the table. Names of tables and
columns are not case-sensitive, and - and _ are treated interchange‐
ably. Unique abbreviations of table and column names are acceptable,
@@ -54,7 +52,7 @@
defined basic types, and their representations, are:
integer
- A decimal integer in the range -2**63 to 2**63-1, inclu‐
+ A decimal integer in the range -2**63 to 2**63-1, inclu‐
sive.
real A floating-point number.
@@ -62,10 +60,10 @@
Boolean
True or false, written true or false, respectively.
- string An arbitrary Unicode string, except that null bytes are
- not allowed. Quotes are optional for most strings that
- begin with an English letter or underscore and consist
- only of letters, underscores, hyphens, and periods. How‐
+ string An arbitrary Unicode string, except that null bytes are
+ not allowed. Quotes are optional for most strings that
+ begin with an English letter or underscore and consist
+ only of letters, underscores, hyphens, and periods. How‐
ever, true and false and strings that match the syntax of
UUIDs (see below) must be enclosed in double quotes to
distinguish them from other basic types. When double
@@ -80,44 +78,44 @@
same ovs-vsctl invocation.
Multiple values in a single column may be separated by spaces or a sin‐
- gle comma. When multiple values are present, duplicates are not
- allowed, and order is not important. Conversely, some database columns
+ gle comma. When multiple values are present, duplicates are not al‐
+ lowed, and order is not important. Conversely, some database columns
can have an empty set of values, represented as [], and square brackets
may optionally enclose other non-empty sets or single values as well.
A few database columns are ``maps’’ of key-value pairs, where the key
and the value are each some fixed database type. These are specified in
- the form key=value, where key and value follow the syntax for the col‐
- umn’s key type and value type, respectively. When multiple pairs are
- present (separated by spaces or a comma), duplicate keys are not
- allowed, and again the order is not important. Duplicate values are
- allowed. An empty map is represented as {}. Curly braces may optionally
- enclose non-empty maps as well (but use quotes to prevent the shell
- from expanding other-config={0=x,1=y} into other-config=0=x other-con‐
+ the form key=value, where key and value follow the syntax for the col‐
+ umn’s key type and value type, respectively. When multiple pairs are
+ present (separated by spaces or a comma), duplicate keys are not al‐
+ lowed, and again the order is not important. Duplicate values are al‐
+ lowed. An empty map is represented as {}. Curly braces may optionally
+ enclose non-empty maps as well (but use quotes to prevent the shell
+ from expanding other-config={0=x,1=y} into other-config=0=x other-con‐‐
fig=1=y, which may not have the desired effect).
Database Command Syntax
- [--if-exists] [--columns=column[,column]...] list table
+ [--if-exists] [--columns=column[,column]...] list table
[record]...
Lists the data in each specified record. If no records
are specified, lists all the records in table.
If --columns is specified, only the requested columns are
- listed, in the specified order. Otherwise, all columns
+ listed, in the specified order. Otherwise, all columns
are listed, in alphabetical order by column name.
- Without --if-exists, it is an error if any specified
- record does not exist. With --if-exists, the command
- ignores any record that does not exist, without producing
+ Without --if-exists, it is an error if any specified
+ record does not exist. With --if-exists, the command ig‐
+ nores any record that does not exist, without producing
any output.
- [--columns=column[,column]...] find table [col‐
+ [--columns=column[,column]...] find table [col
umn[:key]=value]...
Lists the data in each record in table whose column
equals value or, if key is specified, whose column con‐
tains a key with the specified value. The following oper‐
- ators may be used where = is written in the syntax sum‐
+ ators may be used where = is written in the syntax sum‐
mary:
= != gt;>gt; = >gt;>gt;=
@@ -128,26 +126,26 @@
Consider column[:key] and value as sets of ele‐
ments. Identical sets are considered equal. Other‐
- wise, if the sets have different numbers of ele‐
- ments, then the set with more elements is consid‐
- ered to be larger. Otherwise, consider a element
+ wise, if the sets have different numbers of ele‐
+ ments, then the set with more elements is consid‐
+ ered to be larger. Otherwise, consider a element
from each set pairwise, in increasing order within
each set. The first pair that differs determines
the result. (For a column that contains key-value
pairs, first all the keys are compared, and values
- are considered only if the two sets contain iden‐
+ are considered only if the two sets contain iden‐
tical keys.)
{=} {!=}
Test for set equality or inequality, respectively.
- {=} Selects records in which column[:key] is a subset
- of value. For example, flood-vlans{=}1,2 selects
- records in which the flood-vlans column is the
+ {=} Selects records in which column[:key] is a subset
+ of value. For example, flood-vlans{=}1,2 selects
+ records in which the flood-vlans column is the
empty set or contains 1 or 2 or both.
- {} Selects records in which column[:key] is a proper
- subset of value. For example, flood-vlans{}1,2
+ {} Selects records in which column[:key] is a proper
+ subset of value. For example, flood-vlans{}1,2
selects records in which the flood-vlans column is
the empty set or contains 1 or 2 but not both.
@@ -160,12 +158,12 @@
The following operators are available only in Open
vSwitch 2.16 and later:
- {in} Selects records in which every element in col‐
+ {in} Selects records in which every element in col
umn[:key] is also in value. (This is the same as
{=}.)
{not-in}
- Selects records in which every element in col‐
+ Selects records in which every element in col
umn[:key] is not in value.
For arithmetic operators (= != gt;>gt; = >gt;>gt;=), when key is
@@ -177,38 +175,38 @@
For the set operators, when key is specified but a par‐
ticular record’s column does not contain key, the compar‐
- ison is done against an empty set. Thus, the condition
- other-config:mtu{!=}1500 matches records that have a mtu
- key whose value is not 1500 and those that lack an mtu
+ ison is done against an empty set. Thus, the condition
+ other-config:mtu{!=}1500 matches records that have a mtu
+ key whose value is not 1500 and those that lack an mtu
key.
- Don’t forget to escape gt;>gt; from interpretation by the
+ Don’t forget to escape gt;>gt; from interpretation by the
shell.
If --columns is specified, only the requested columns are
listed, in the specified order. Otherwise all columns are
listed, in alphabetical order by column name.
- The UUIDs shown for rows created in the same ovs-vsctl
+ The UUIDs shown for rows created in the same ovs-vsctl
invocation will be wrong.
[--if-exists] [--id=@name] get table record [column[:key]]...
- Prints the value of each specified column in the given
+ Prints the value of each specified column in the given
record in table. For map columns, a key may optionally be
specified, in which case the value associated with key in
the column is printed, instead of the entire map.
- Without --if-exists, it is an error if record does not
- exist or key is specified, if key does not exist in
+ Without --if-exists, it is an error if record does not
+ exist or key is specified, if key does not exist in
record. With --if-exists, a missing record yields no out‐
put and a missing key prints a blank line.
If @name is specified, then the UUID for record may be
- referred to by that name later in the same ovs-vsctl
- invocation in contexts where a UUID is expected.
+ referred to by that name later in the same ovs-vsctl in‐
+ vocation in contexts where a UUID is expected.
Both --id and the column arguments are optional, but usu‐
- ally at least one or the other should be specified. If
+ ally at least one or the other should be specified. If
both are omitted, then get has no effect except to verify
that record exists in table.
@@ -216,10 +214,10 @@
[--if-exists] set table record column[:key]=value...
Sets the value of each specified column in the given
- record in table to value. For map columns, a key may
- optionally be specified, in which case the value associ‐
- ated with key in that column is changed (or added, if
- none exists), instead of the entire map.
+ record in table to value. For map columns, a key may op‐
+ tionally be specified, in which case the value associated
+ with key in that column is changed (or added, if none ex‐
+ ists), instead of the entire map.
Without --if-exists, it is an error if record does not
exist. With --if-exists, this command does nothing if
@@ -227,11 +225,10 @@
[--if-exists] add table record column [key=]value...
Adds the specified value or key-value pair to column in
- record in table. If column is a map, then key is
- required, otherwise it is prohibited. If key already
- exists in a map column, then the current value is not
- replaced (use the set command to replace an existing
- value).
+ record in table. If column is a map, then key is re‐
+ quired, otherwise it is prohibited. If key already exists
+ in a map column, then the current value is not replaced
+ (use the set command to replace an existing value).
Without --if-exists, it is an error if record does not
exist. With --if-exists, this command does nothing if
@@ -242,29 +239,29 @@
[--if-exists] remove table record column key...
[--if-exists] remove table record column key=value...
- Removes the specified values or key-value pairs from col‐
+ Removes the specified values or key-value pairs from col
umn in record in table. The first form applies to columns
that are not maps: each specified value is removed from
- the column. The second and third forms apply to map col‐
- umns: if only a key is specified, then any key-value pair
- with the given key is removed, regardless of its value;
- if a value is given then a pair is removed only if both
- key and value match.
+ the column. The second and third forms apply to map
+ columns: if only a key is specified, then any key-value
+ pair with the given key is removed, regardless of its
+ value; if a value is given then a pair is removed only if
+ both key and value match.
- It is not an error if the column does not contain the
+ It is not an error if the column does not contain the
specified key or value or pair.
- Without --if-exists, it is an error if record does not
- exist. With --if-exists, this command does nothing if
+ Without --if-exists, it is an error if record does not
+ exist. With --if-exists, this command does nothing if
record does not exist.
[--if-exists] clear table record column...
- Sets each column in record in table to the empty set or
- empty map, as appropriate. This command applies only to
+ Sets each column in record in table to the empty set or
+ empty map, as appropriate. This command applies only to
columns that are allowed to be empty.
- Without --if-exists, it is an error if record does not
- exist. With --if-exists, this command does nothing if
+ Without --if-exists, it is an error if record does not
+ exist. With --if-exists, this command does nothing if
record does not exist.
[--id=(@name|uuid)] create table column[:key]=value...
@@ -281,9 +278,9 @@
of the new row.
Caution (ovs-vsctl as example)
- Records in the Open vSwitch database are signifi‐
- cant only when they can be reached directly or
- indirectly from the Open_vSwitch table. Except for
+ Records in the Open vSwitch database are signifi‐
+ cant only when they can be reached directly or in‐
+ directly from the Open_vSwitch table. Except for
records in the QoS or Queue tables, records that
are not reachable from the Open_vSwitch table are
automatically deleted from the database. This
@@ -297,25 +294,25 @@
some examples that show how to do this.
[--if-exists] destroy table record...
- Deletes each specified record from table. Unless
- --if-exists is specified, each records must exist.
+ Deletes each specified record from table. Unless --if-ex‐‐
+ ists is specified, each records must exist.
--all destroy table
Deletes all records from the table.
Caution (ovs-vsctl as example)
- The destroy command is only useful for records in
- the QoS or Queue tables. Records in other tables
- are automatically deleted from the database when
- they become unreachable from the Open_vSwitch ta‐
- ble. This means that deleting the last reference
- to a record is sufficient for deleting the record
- itself. For records in these tables, destroy is
- silently ignored. See the EXAMPLES section below
+ The destroy command is only useful for records in
+ the QoS or Queue tables. Records in other tables
+ are automatically deleted from the database when
+ they become unreachable from the Open_vSwitch ta‐
+ ble. This means that deleting the last reference
+ to a record is sufficient for deleting the record
+ itself. For records in these tables, destroy is
+ silently ignored. See the EXAMPLES section below
for more information.
wait-until table record [column[:key]=value]...
- Waits until table contains a record named record whose
+ Waits until table contains a record named record whose
column equals value or, if key is specified, whose column
contains a key with the specified value. This command
supports the same operators and semantics described for
@@ -329,20 +326,20 @@
Caution (ovs-vsctl as example)
Usually wait-until should be placed at the begin‐
ning of a set of ovs-vsctl commands. For example,
- wait-until bridge br0 -- get bridge br0 data‐
+ wait-until bridge br0 -- get bridge br0 data‐‐
path_id waits until a bridge named br0 is created,
- then prints its datapath_id column, whereas get
- bridge br0 datapath_id -- wait-until bridge br0
- will abort if no bridge named br0 exists when
+ then prints its datapath_id column, whereas get
+ bridge br0 datapath_id -- wait-until bridge br0
+ will abort if no bridge named br0 exists when
ovs-vsctl initially connects to the database.
- Consider specifying --timeout=0 along with --wait-until,
- to prevent ovs-vsctl from terminating after waiting only
+ Consider specifying --timeout=0 along with --wait-until,
+ to prevent ovs-vsctl from terminating after waiting only
at most 5 seconds.
comment [arg]...
- This command has no effect on behavior, but any database
- log record created by the command will include the com‐
+ This command has no effect on behavior, but any database
+ log record created by the command will include the com‐
mand and its arguments.
REMOTE CONNECTIVITY COMMANDS
@@ -353,7 +350,7 @@
Deletes the configured connection(s).
[--inactivity-probe=msecs] set-connection target...
- Sets the configured manager target or targets. Use --inactiv‐
+ Sets the configured manager target or targets. Use --inactiv‐‐
ity-probe=msecs to override the default idle connection inactiv‐
ity probe time. Use 0 to disable inactivity probes.
@@ -364,17 +361,17 @@
del-ssl
Deletes the current SSL configuration.
- [--bootstrap] set-ssl private-key certificate ca-cert [ssl-protocol-
+ [--bootstrap] set-ssl private-key certificate ca-cert [ssl-protocol-
list [ssl-cipher-list]]
Sets the SSL configuration.
OPTIONS
--db database
- The OVSDB database remote to contact. If the OVN_IC_SB_DB envi‐
- ronment variable is set, its value is used as the default. Oth‐
+ The OVSDB database remote to contact. If the OVN_IC_SB_DB envi‐
+ ronment variable is set, its value is used as the default. Oth‐
erwise, the default is unix:/ovn_ic_sb_db.sock, but this default
- is unlikely to be useful outside of single-machine OVN test
- environments.
+ is unlikely to be useful outside of single-machine OVN test en‐
+ vironments.
--leader-only
--no-leader-only
@@ -383,34 +380,34 @@
cluster leader. This ensures that any data that ovn-ic-sbctl reads
and reports is up-to-date. With --no-leader-only, ovn-ic-sbctl
will use any server in the cluster, which means that for read-only
- transactions it can report and act on stale data (transactions
- that modify the database are always serialized even with
- --no-leader-only). Refer to Understanding Cluster Consistency in
+ transactions it can report and act on stale data (transactions
+ that modify the database are always serialized even with
+ --no-leader-only). Refer to Understanding Cluster Consistency in
ovsdb(7) for more information.
LOGGING OPTIONS
-v[spec]
--verbose=[spec]
- Sets logging levels. Without any spec, sets the log level for
- every module and destination to dbg. Otherwise, spec is a list of
+ Sets logging levels. Without any spec, sets the log level for
+ every module and destination to dbg. Otherwise, spec is a list of
words separated by spaces or commas or colons, up to one from each
category below:
- · A valid module name, as displayed by the vlog/list command
+ • A valid module name, as displayed by the vlog/list command
on ovs-appctl(8), limits the log level change to the speci‐
fied module.
- · syslog, console, or file, to limit the log level change to
- only to the system log, to the console, or to a file,
- respectively. (If --detach is specified, the daemon closes
- its standard file descriptors, so logging to the console
+ • syslog, console, or file, to limit the log level change to
+ only to the system log, to the console, or to a file, re‐
+ spectively. (If --detach is specified, the daemon closes
+ its standard file descriptors, so logging to the console
will have no effect.)
- On Windows platform, syslog is accepted as a word and is
+ On Windows platform, syslog is accepted as a word and is
only useful along with the --syslog-target option (the word
has no effect otherwise).
- · off, emer, err, warn, info, or dbg, to control the log
+ • off, emer, err, warn, info, or dbg, to control the log
level. Messages of the given severity or higher will be
logged, and messages of lower severity will be filtered
out. off filters out all messages. See ovs-appctl(8) for a
@@ -426,26 +423,26 @@
-v
--verbose
- Sets the maximum logging verbosity level, equivalent to --ver‐
+ Sets the maximum logging verbosity level, equivalent to --ver‐‐
bose=dbg.
-vPATTERN:destination:pattern
--verbose=PATTERN:destination:pattern
- Sets the log pattern for destination to pattern. Refer to
- ovs-appctl(8) for a description of the valid syntax for pattern.
+ Sets the log pattern for destination to pattern. Refer to ovs-ap‐‐
+ pctl(8) for a description of the valid syntax for pattern.
-vFACILITY:facility
--verbose=FACILITY:facility
- Sets the RFC5424 facility of the log message. facility can be one
+ Sets the RFC5424 facility of the log message. facility can be one
of kern, user, mail, daemon, auth, syslog, lpr, news, uucp, clock,
ftp, ntp, audit, alert, clock2, local0, local1, local2, local3,
local4, local5, local6 or local7. If this option is not specified,
- daemon is used as the default for the local system syslog and
- local0 is used while sending a message to the target provided via
+ daemon is used as the default for the local system syslog and lo‐‐
+ cal0 is used while sending a message to the target provided via
the --syslog-target option.
--log-file[=file]
- Enables logging to a file. If file is specified, then it is used
+ Enables logging to a file. If file is specified, then it is used
as the exact name for the log file. The default log file name used
if file is omitted is /usr/local/var/log/ovn/program.log.
@@ -458,30 +455,30 @@
Specify method as how syslog messages should be sent to syslog
daemon. The following forms are supported:
- · libc, to use the libc syslog() function. Downside of using
+ • libc, to use the libc syslog() function. Downside of using
this options is that libc adds fixed prefix to every mes‐
sage before it is actually sent to the syslog daemon over
/dev/log UNIX domain socket.
- · unix:file, to use a UNIX domain socket directly. It is pos‐
+ • unix:file, to use a UNIX domain socket directly. It is pos‐
sible to specify arbitrary message format with this option.
However, rsyslogd 8.9 and older versions use hard coded
parser function anyway that limits UNIX domain socket use.
If you want to use arbitrary message format with older
- rsyslogd versions, then use UDP socket to localhost IP
- address instead.
+ rsyslogd versions, then use UDP socket to localhost IP ad‐
+ dress instead.
- · udp:ip:port, to use a UDP socket. With this method it is
+ • udp:ip:port, to use a UDP socket. With this method it is
possible to use arbitrary message format also with older
- rsyslogd. When sending syslog messages over UDP socket
- extra precaution needs to be taken into account, for exam‐
- ple, syslog daemon needs to be configured to listen on the
- specified UDP port, accidental iptables rules could be
- interfering with local syslog traffic and there are some
- security considerations that apply to UDP sockets, but do
- not apply to UNIX domain sockets.
+ rsyslogd. When sending syslog messages over UDP socket ex‐
+ tra precaution needs to be taken into account, for example,
+ syslog daemon needs to be configured to listen on the spec‐
+ ified UDP port, accidental iptables rules could be inter‐
+ fering with local syslog traffic and there are some secu‐
+ rity considerations that apply to UDP sockets, but do not
+ apply to UNIX domain sockets.
- · null, to discard all messages logged to syslog.
+ • null, to discard all messages logged to syslog.
The default is taken from the OVS_SYSLOG_METHOD environment vari‐
able; if it is unset, the default is libc.
@@ -523,14 +520,14 @@
element is also an array with one element per
table column. The elements of this second-
level array are the cells that constitute the
- table. Cells that represent OVSDB data or
- data types are expressed in the format
- described in the OVSDB specification; other
+ table. Cells that represent OVSDB data or
+ data types are expressed in the format de‐
+ scribed in the OVSDB specification; other
cells are simply expressed as text strings.
-d format
--data=format
- Sets the formatting for cells within output tables unless
+ Sets the formatting for cells within output tables unless
the table format is set to json, in which case json format‐
ting is always used when formatting cells. The following
types of format are available:
@@ -540,19 +537,19 @@
section of ovs-vsctl(8).
bare The simple format with punctuation stripped off: []
- and {} are omitted around sets, maps, and empty col‐
- umns, items within sets and maps are space-sepa‐
+ and {} are omitted around sets, maps, and empty
+ columns, items within sets and maps are space-sepa‐
rated, and strings are never quoted. This format may
be easier for scripts to parse.
json The RFC 4627 JSON format as described above.
--no-headings
- This option suppresses the heading row that otherwise
- appears in the first row of table output.
+ This option suppresses the heading row that otherwise ap‐
+ pears in the first row of table output.
--pretty
- By default, JSON in output is printed as compactly as pos‐
+ By default, JSON in output is printed as compactly as pos‐
sible. This option causes JSON in output to be printed in a
more readable fashion. Members of objects and elements of
arrays are printed one per line, with indentation.
@@ -564,27 +561,27 @@
Equivalent to --format=list --data=bare --no-headings.
PKI Options
- PKI configuration is required to use SSL for the connection to the
+ PKI configuration is required to use SSL for the connection to the
database.
-p privkey.pem
--private-key=privkey.pem
- Specifies a PEM file containing the private key used as
+ Specifies a PEM file containing the private key used as
identity for outgoing SSL connections.
-c cert.pem
--certificate=cert.pem
- Specifies a PEM file containing a certificate that certi‐
+ Specifies a PEM file containing a certificate that certi‐
fies the private key specified on -p or --private-key to be
trustworthy. The certificate must be signed by the certifi‐
- cate authority (CA) that the peer in SSL connections will
+ cate authority (CA) that the peer in SSL connections will
use to verify it.
-C cacert.pem
--ca-cert=cacert.pem
Specifies a PEM file containing the CA certificate for ver‐
ifying certificates presented to this program by SSL peers.
- (This may be the same certificate that SSL peers use to
+ (This may be the same certificate that SSL peers use to
verify the certificate specified on -c or --certificate, or
it may be a different one, depending on the PKI design in
use.)
@@ -603,14 +600,14 @@
the SSL peer on its first SSL connection and save it to
the named PEM file. If it is successful, it will immedi‐
ately drop the connection and reconnect, and from then on
- all SSL connections must be authenticated by a certifi‐
+ all SSL connections must be authenticated by a certifi‐
cate 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, but
+ This option exposes the SSL connection to a man-in-the-
+ middle attack obtaining the initial CA certificate, but
it may be useful for bootstrapping.
- This option is only useful if the SSL peer sends its CA
+ This option is only useful if the SSL peer sends its CA
certificate as part of the SSL certificate chain. The SSL
protocol does not require the server to send the CA cer‐
tificate.
@@ -626,7 +623,5 @@
--version
Prints version information to the console.
-
-
-OVN 22.12.90 ovn-ic-sbctl ovn-ic-sbctl(8)
+OVN 24.03.90 ovn-ic-sbctl ovn-ic-sbctl(8)
diff --git a/src/static/support/dist-docs/ovn-ic-sbctl.8.pdf b/src/static/support/dist-docs/ovn-ic-sbctl.8.pdf
index 0fcc5d3e..5ca653ef 100644
Binary files a/src/static/support/dist-docs/ovn-ic-sbctl.8.pdf and b/src/static/support/dist-docs/ovn-ic-sbctl.8.pdf differ
diff --git a/src/static/support/dist-docs/ovn-ic-sbctl.8.txt b/src/static/support/dist-docs/ovn-ic-sbctl.8.txt
index d422d980..2b176108 100644
--- a/src/static/support/dist-docs/ovn-ic-sbctl.8.txt
+++ b/src/static/support/dist-docs/ovn-ic-sbctl.8.txt
@@ -1,7 +1,5 @@
ovn-ic-sbctl(8) OVN Manual ovn-ic-sbctl(8)
-
-
NAME
ovn-ic-sbctl - Open Virtual Network interconnection southbound db man‐
agement utility
@@ -31,17 +29,17 @@ DATABASE COMMANDS
Each of these commands has a table parameter to identify a table within
the database. Many of them also take a record parameter that identifies
- a particular record within a table. The record parameter may be the
- UUID for a record, which may be abbreviated to its first 4 (or more)
- hex digits, as long as that is unique. Many tables offer additional
- ways to identify records. Some commands also take column parameters
+ a particular record within a table. The record parameter may be the
+ UUID for a record, which may be abbreviated to its first 4 (or more)
+ hex digits, as long as that is unique. Many tables offer additional
+ ways to identify records. Some commands also take column parameters
that identify a particular field within the records in a table.
For a list of tables and their columns, see ovn-ic-sb(5) or see the ta‐
ble listing from the --help option.
Record names must be specified in full and with correct capitalization,
- except that UUIDs may be abbreviated to their first 4 (or more) hex
+ except that UUIDs may be abbreviated to their first 4 (or more) hex
digits, as long as that is unique within the table. Names of tables and
columns are not case-sensitive, and - and _ are treated interchange‐
ably. Unique abbreviations of table and column names are acceptable,
@@ -53,7 +51,7 @@ DATABASE COMMANDS
defined basic types, and their representations, are:
integer
- A decimal integer in the range -2**63 to 2**63-1, inclu‐
+ A decimal integer in the range -2**63 to 2**63-1, inclu‐
sive.
real A floating-point number.
@@ -61,10 +59,10 @@ DATABASE COMMANDS
Boolean
True or false, written true or false, respectively.
- string An arbitrary Unicode string, except that null bytes are
- not allowed. Quotes are optional for most strings that
- begin with an English letter or underscore and consist
- only of letters, underscores, hyphens, and periods. How‐
+ string An arbitrary Unicode string, except that null bytes are
+ not allowed. Quotes are optional for most strings that
+ begin with an English letter or underscore and consist
+ only of letters, underscores, hyphens, and periods. How‐
ever, true and false and strings that match the syntax of
UUIDs (see below) must be enclosed in double quotes to
distinguish them from other basic types. When double
@@ -79,44 +77,44 @@ DATABASE COMMANDS
same ovs-vsctl invocation.
Multiple values in a single column may be separated by spaces or a sin‐
- gle comma. When multiple values are present, duplicates are not
- allowed, and order is not important. Conversely, some database columns
+ gle comma. When multiple values are present, duplicates are not al‐
+ lowed, and order is not important. Conversely, some database columns
can have an empty set of values, represented as [], and square brackets
may optionally enclose other non-empty sets or single values as well.
A few database columns are ``maps’’ of key-value pairs, where the key
and the value are each some fixed database type. These are specified in
- the form key=value, where key and value follow the syntax for the col‐
- umn’s key type and value type, respectively. When multiple pairs are
- present (separated by spaces or a comma), duplicate keys are not
- allowed, and again the order is not important. Duplicate values are
- allowed. An empty map is represented as {}. Curly braces may optionally
- enclose non-empty maps as well (but use quotes to prevent the shell
- from expanding other-config={0=x,1=y} into other-config=0=x other-con‐
+ the form key=value, where key and value follow the syntax for the col‐
+ umn’s key type and value type, respectively. When multiple pairs are
+ present (separated by spaces or a comma), duplicate keys are not al‐
+ lowed, and again the order is not important. Duplicate values are al‐
+ lowed. An empty map is represented as {}. Curly braces may optionally
+ enclose non-empty maps as well (but use quotes to prevent the shell
+ from expanding other-config={0=x,1=y} into other-config=0=x other-con‐
fig=1=y, which may not have the desired effect).
Database Command Syntax
- [--if-exists] [--columns=column[,column]...] list table
+ [--if-exists] [--columns=column[,column]...] list table
[record]...
Lists the data in each specified record. If no records
are specified, lists all the records in table.
If --columns is specified, only the requested columns are
- listed, in the specified order. Otherwise, all columns
+ listed, in the specified order. Otherwise, all columns
are listed, in alphabetical order by column name.
- Without --if-exists, it is an error if any specified
- record does not exist. With --if-exists, the command
- ignores any record that does not exist, without producing
+ Without --if-exists, it is an error if any specified
+ record does not exist. With --if-exists, the command ig‐
+ nores any record that does not exist, without producing
any output.
- [--columns=column[,column]...] find table [col‐
+ [--columns=column[,column]...] find table [col‐
umn[:key]=value]...
Lists the data in each record in table whose column
equals value or, if key is specified, whose column con‐
tains a key with the specified value. The following oper‐
- ators may be used where = is written in the syntax sum‐
+ ators may be used where = is written in the syntax sum‐
mary:
= != < > <= >=
@@ -127,26 +125,26 @@ DATABASE COMMANDS
Consider column[:key] and value as sets of ele‐
ments. Identical sets are considered equal. Other‐
- wise, if the sets have different numbers of ele‐
- ments, then the set with more elements is consid‐
- ered to be larger. Otherwise, consider a element
+ wise, if the sets have different numbers of ele‐
+ ments, then the set with more elements is consid‐
+ ered to be larger. Otherwise, consider a element
from each set pairwise, in increasing order within
each set. The first pair that differs determines
the result. (For a column that contains key-value
pairs, first all the keys are compared, and values
- are considered only if the two sets contain iden‐
+ are considered only if the two sets contain iden‐
tical keys.)
{=} {!=}
Test for set equality or inequality, respectively.
- {<=} Selects records in which column[:key] is a subset
- of value. For example, flood-vlans{<=}1,2 selects
- records in which the flood-vlans column is the
+ {<=} Selects records in which column[:key] is a subset
+ of value. For example, flood-vlans{<=}1,2 selects
+ records in which the flood-vlans column is the
empty set or contains 1 or 2 or both.
- {<} Selects records in which column[:key] is a proper
- subset of value. For example, flood-vlans{<}1,2
+ {<} Selects records in which column[:key] is a proper
+ subset of value. For example, flood-vlans{<}1,2
selects records in which the flood-vlans column is
the empty set or contains 1 or 2 but not both.
@@ -176,38 +174,38 @@ DATABASE COMMANDS
For the set operators, when key is specified but a par‐
ticular record’s column does not contain key, the compar‐
- ison is done against an empty set. Thus, the condition
- other-config:mtu{!=}1500 matches records that have a mtu
- key whose value is not 1500 and those that lack an mtu
+ ison is done against an empty set. Thus, the condition
+ other-config:mtu{!=}1500 matches records that have a mtu
+ key whose value is not 1500 and those that lack an mtu
key.
- Don’t forget to escape < or > from interpretation by the
+ Don’t forget to escape < or > from interpretation by the
shell.
If --columns is specified, only the requested columns are
listed, in the specified order. Otherwise all columns are
listed, in alphabetical order by column name.
- The UUIDs shown for rows created in the same ovs-vsctl
+ The UUIDs shown for rows created in the same ovs-vsctl
invocation will be wrong.
[--if-exists] [--id=@name] get table record [column[:key]]...
- Prints the value of each specified column in the given
+ Prints the value of each specified column in the given
record in table. For map columns, a key may optionally be
specified, in which case the value associated with key in
the column is printed, instead of the entire map.
- Without --if-exists, it is an error if record does not
- exist or key is specified, if key does not exist in
+ Without --if-exists, it is an error if record does not
+ exist or key is specified, if key does not exist in
record. With --if-exists, a missing record yields no out‐
put and a missing key prints a blank line.
If @name is specified, then the UUID for record may be
- referred to by that name later in the same ovs-vsctl
- invocation in contexts where a UUID is expected.
+ referred to by that name later in the same ovs-vsctl in‐
+ vocation in contexts where a UUID is expected.
Both --id and the column arguments are optional, but usu‐
- ally at least one or the other should be specified. If
+ ally at least one or the other should be specified. If
both are omitted, then get has no effect except to verify
that record exists in table.
@@ -215,10 +213,10 @@ DATABASE COMMANDS
[--if-exists] set table record column[:key]=value...
Sets the value of each specified column in the given
- record in table to value. For map columns, a key may
- optionally be specified, in which case the value associ‐
- ated with key in that column is changed (or added, if
- none exists), instead of the entire map.
+ record in table to value. For map columns, a key may op‐
+ tionally be specified, in which case the value associated
+ with key in that column is changed (or added, if none ex‐
+ ists), instead of the entire map.
Without --if-exists, it is an error if record does not
exist. With --if-exists, this command does nothing if
@@ -226,11 +224,10 @@ DATABASE COMMANDS
[--if-exists] add table record column [key=]value...
Adds the specified value or key-value pair to column in
- record in table. If column is a map, then key is
- required, otherwise it is prohibited. If key already
- exists in a map column, then the current value is not
- replaced (use the set command to replace an existing
- value).
+ record in table. If column is a map, then key is re‐
+ quired, otherwise it is prohibited. If key already exists
+ in a map column, then the current value is not replaced
+ (use the set command to replace an existing value).
Without --if-exists, it is an error if record does not
exist. With --if-exists, this command does nothing if
@@ -244,26 +241,26 @@ DATABASE COMMANDS
Removes the specified values or key-value pairs from col‐
umn in record in table. The first form applies to columns
that are not maps: each specified value is removed from
- the column. The second and third forms apply to map col‐
- umns: if only a key is specified, then any key-value pair
- with the given key is removed, regardless of its value;
- if a value is given then a pair is removed only if both
- key and value match.
+ the column. The second and third forms apply to map
+ columns: if only a key is specified, then any key-value
+ pair with the given key is removed, regardless of its
+ value; if a value is given then a pair is removed only if
+ both key and value match.
- It is not an error if the column does not contain the
+ It is not an error if the column does not contain the
specified key or value or pair.
- Without --if-exists, it is an error if record does not
- exist. With --if-exists, this command does nothing if
+ Without --if-exists, it is an error if record does not
+ exist. With --if-exists, this command does nothing if
record does not exist.
[--if-exists] clear table record column...
- Sets each column in record in table to the empty set or
- empty map, as appropriate. This command applies only to
+ Sets each column in record in table to the empty set or
+ empty map, as appropriate. This command applies only to
columns that are allowed to be empty.
- Without --if-exists, it is an error if record does not
- exist. With --if-exists, this command does nothing if
+ Without --if-exists, it is an error if record does not
+ exist. With --if-exists, this command does nothing if
record does not exist.
[--id=(@name|uuid)] create table column[:key]=value...
@@ -280,9 +277,9 @@ DATABASE COMMANDS
of the new row.
Caution (ovs-vsctl as example)
- Records in the Open vSwitch database are signifi‐
- cant only when they can be reached directly or
- indirectly from the Open_vSwitch table. Except for
+ Records in the Open vSwitch database are signifi‐
+ cant only when they can be reached directly or in‐
+ directly from the Open_vSwitch table. Except for
records in the QoS or Queue tables, records that
are not reachable from the Open_vSwitch table are
automatically deleted from the database. This
@@ -296,25 +293,25 @@ DATABASE COMMANDS
some examples that show how to do this.
[--if-exists] destroy table record...
- Deletes each specified record from table. Unless
- --if-exists is specified, each records must exist.
+ Deletes each specified record from table. Unless --if-ex‐
+ ists is specified, each records must exist.
--all destroy table
Deletes all records from the table.
Caution (ovs-vsctl as example)
- The destroy command is only useful for records in
- the QoS or Queue tables. Records in other tables
- are automatically deleted from the database when
- they become unreachable from the Open_vSwitch ta‐
- ble. This means that deleting the last reference
- to a record is sufficient for deleting the record
- itself. For records in these tables, destroy is
- silently ignored. See the EXAMPLES section below
+ The destroy command is only useful for records in
+ the QoS or Queue tables. Records in other tables
+ are automatically deleted from the database when
+ they become unreachable from the Open_vSwitch ta‐
+ ble. This means that deleting the last reference
+ to a record is sufficient for deleting the record
+ itself. For records in these tables, destroy is
+ silently ignored. See the EXAMPLES section below
for more information.
wait-until table record [column[:key]=value]...
- Waits until table contains a record named record whose
+ Waits until table contains a record named record whose
column equals value or, if key is specified, whose column
contains a key with the specified value. This command
supports the same operators and semantics described for
@@ -328,20 +325,20 @@ DATABASE COMMANDS
Caution (ovs-vsctl as example)
Usually wait-until should be placed at the begin‐
ning of a set of ovs-vsctl commands. For example,
- wait-until bridge br0 -- get bridge br0 data‐
+ wait-until bridge br0 -- get bridge br0 data‐
path_id waits until a bridge named br0 is created,
- then prints its datapath_id column, whereas get
- bridge br0 datapath_id -- wait-until bridge br0
- will abort if no bridge named br0 exists when
+ then prints its datapath_id column, whereas get
+ bridge br0 datapath_id -- wait-until bridge br0
+ will abort if no bridge named br0 exists when
ovs-vsctl initially connects to the database.
- Consider specifying --timeout=0 along with --wait-until,
- to prevent ovs-vsctl from terminating after waiting only
+ Consider specifying --timeout=0 along with --wait-until,
+ to prevent ovs-vsctl from terminating after waiting only
at most 5 seconds.
comment [arg]...
- This command has no effect on behavior, but any database
- log record created by the command will include the com‐
+ This command has no effect on behavior, but any database
+ log record created by the command will include the com‐
mand and its arguments.
REMOTE CONNECTIVITY COMMANDS
@@ -352,7 +349,7 @@ REMOTE CONNECTIVITY COMMANDS
Deletes the configured connection(s).
[--inactivity-probe=msecs] set-connection target...
- Sets the configured manager target or targets. Use --inactiv‐
+ Sets the configured manager target or targets. Use --inactiv‐
ity-probe=msecs to override the default idle connection inactiv‐
ity probe time. Use 0 to disable inactivity probes.
@@ -363,17 +360,17 @@ SSL CONFIGURATION COMMANDS
del-ssl
Deletes the current SSL configuration.
- [--bootstrap] set-ssl private-key certificate ca-cert [ssl-protocol-
+ [--bootstrap] set-ssl private-key certificate ca-cert [ssl-protocol-
list [ssl-cipher-list]]
Sets the SSL configuration.
OPTIONS
--db database
- The OVSDB database remote to contact. If the OVN_IC_SB_DB envi‐
- ronment variable is set, its value is used as the default. Oth‐
+ The OVSDB database remote to contact. If the OVN_IC_SB_DB envi‐
+ ronment variable is set, its value is used as the default. Oth‐
erwise, the default is unix:/ovn_ic_sb_db.sock, but this default
- is unlikely to be useful outside of single-machine OVN test
- environments.
+ is unlikely to be useful outside of single-machine OVN test en‐
+ vironments.
--leader-only
--no-leader-only
@@ -382,34 +379,34 @@ OPTIONS
cluster leader. This ensures that any data that ovn-ic-sbctl reads
and reports is up-to-date. With --no-leader-only, ovn-ic-sbctl
will use any server in the cluster, which means that for read-only
- transactions it can report and act on stale data (transactions
- that modify the database are always serialized even with
- --no-leader-only). Refer to Understanding Cluster Consistency in
+ transactions it can report and act on stale data (transactions
+ that modify the database are always serialized even with
+ --no-leader-only). Refer to Understanding Cluster Consistency in
ovsdb(7) for more information.
LOGGING OPTIONS
-v[spec]
--verbose=[spec]
- Sets logging levels. Without any spec, sets the log level for
- every module and destination to dbg. Otherwise, spec is a list of
+ Sets logging levels. Without any spec, sets the log level for
+ every module and destination to dbg. Otherwise, spec is a list of
words separated by spaces or commas or colons, up to one from each
category below:
- · A valid module name, as displayed by the vlog/list command
+ • A valid module name, as displayed by the vlog/list command
on ovs-appctl(8), limits the log level change to the speci‐
fied module.
- · syslog, console, or file, to limit the log level change to
- only to the system log, to the console, or to a file,
- respectively. (If --detach is specified, the daemon closes
- its standard file descriptors, so logging to the console
+ • syslog, console, or file, to limit the log level change to
+ only to the system log, to the console, or to a file, re‐
+ spectively. (If --detach is specified, the daemon closes
+ its standard file descriptors, so logging to the console
will have no effect.)
- On Windows platform, syslog is accepted as a word and is
+ On Windows platform, syslog is accepted as a word and is
only useful along with the --syslog-target option (the word
has no effect otherwise).
- · off, emer, err, warn, info, or dbg, to control the log
+ • off, emer, err, warn, info, or dbg, to control the log
level. Messages of the given severity or higher will be
logged, and messages of lower severity will be filtered
out. off filters out all messages. See ovs-appctl(8) for a
@@ -425,26 +422,26 @@ LOGGING OPTIONS
-v
--verbose
- Sets the maximum logging verbosity level, equivalent to --ver‐
+ Sets the maximum logging verbosity level, equivalent to --ver‐
bose=dbg.
-vPATTERN:destination:pattern
--verbose=PATTERN:destination:pattern
- Sets the log pattern for destination to pattern. Refer to
- ovs-appctl(8) for a description of the valid syntax for pattern.
+ Sets the log pattern for destination to pattern. Refer to ovs-ap‐
+ pctl(8) for a description of the valid syntax for pattern.
-vFACILITY:facility
--verbose=FACILITY:facility
- Sets the RFC5424 facility of the log message. facility can be one
+ Sets the RFC5424 facility of the log message. facility can be one
of kern, user, mail, daemon, auth, syslog, lpr, news, uucp, clock,
ftp, ntp, audit, alert, clock2, local0, local1, local2, local3,
local4, local5, local6 or local7. If this option is not specified,
- daemon is used as the default for the local system syslog and
- local0 is used while sending a message to the target provided via
+ daemon is used as the default for the local system syslog and lo‐
+ cal0 is used while sending a message to the target provided via
the --syslog-target option.
--log-file[=file]
- Enables logging to a file. If file is specified, then it is used
+ Enables logging to a file. If file is specified, then it is used
as the exact name for the log file. The default log file name used
if file is omitted is /usr/local/var/log/ovn/program.log.
@@ -457,30 +454,30 @@ LOGGING OPTIONS
Specify method as how syslog messages should be sent to syslog
daemon. The following forms are supported:
- · libc, to use the libc syslog() function. Downside of using
+ • libc, to use the libc syslog() function. Downside of using
this options is that libc adds fixed prefix to every mes‐
sage before it is actually sent to the syslog daemon over
/dev/log UNIX domain socket.
- · unix:file, to use a UNIX domain socket directly. It is pos‐
+ • unix:file, to use a UNIX domain socket directly. It is pos‐
sible to specify arbitrary message format with this option.
However, rsyslogd 8.9 and older versions use hard coded
parser function anyway that limits UNIX domain socket use.
If you want to use arbitrary message format with older
- rsyslogd versions, then use UDP socket to localhost IP
- address instead.
+ rsyslogd versions, then use UDP socket to localhost IP ad‐
+ dress instead.
- · udp:ip:port, to use a UDP socket. With this method it is
+ • udp:ip:port, to use a UDP socket. With this method it is
possible to use arbitrary message format also with older
- rsyslogd. When sending syslog messages over UDP socket
- extra precaution needs to be taken into account, for exam‐
- ple, syslog daemon needs to be configured to listen on the
- specified UDP port, accidental iptables rules could be
- interfering with local syslog traffic and there are some
- security considerations that apply to UDP sockets, but do
- not apply to UNIX domain sockets.
+ rsyslogd. When sending syslog messages over UDP socket ex‐
+ tra precaution needs to be taken into account, for example,
+ syslog daemon needs to be configured to listen on the spec‐
+ ified UDP port, accidental iptables rules could be inter‐
+ fering with local syslog traffic and there are some secu‐
+ rity considerations that apply to UDP sockets, but do not
+ apply to UNIX domain sockets.
- · null, to discard all messages logged to syslog.
+ • null, to discard all messages logged to syslog.
The default is taken from the OVS_SYSLOG_METHOD environment vari‐
able; if it is unset, the default is libc.
@@ -522,14 +519,14 @@ TABLE FORMATTING OPTIONS
element is also an array with one element per
table column. The elements of this second-
level array are the cells that constitute the
- table. Cells that represent OVSDB data or
- data types are expressed in the format
- described in the OVSDB specification; other
+ table. Cells that represent OVSDB data or
+ data types are expressed in the format de‐
+ scribed in the OVSDB specification; other
cells are simply expressed as text strings.
-d format
--data=format
- Sets the formatting for cells within output tables unless
+ Sets the formatting for cells within output tables unless
the table format is set to json, in which case json format‐
ting is always used when formatting cells. The following
types of format are available:
@@ -539,19 +536,19 @@ TABLE FORMATTING OPTIONS
section of ovs-vsctl(8).
bare The simple format with punctuation stripped off: []
- and {} are omitted around sets, maps, and empty col‐
- umns, items within sets and maps are space-sepa‐
+ and {} are omitted around sets, maps, and empty
+ columns, items within sets and maps are space-sepa‐
rated, and strings are never quoted. This format may
be easier for scripts to parse.
json The RFC 4627 JSON format as described above.
--no-headings
- This option suppresses the heading row that otherwise
- appears in the first row of table output.
+ This option suppresses the heading row that otherwise ap‐
+ pears in the first row of table output.
--pretty
- By default, JSON in output is printed as compactly as pos‐
+ By default, JSON in output is printed as compactly as pos‐
sible. This option causes JSON in output to be printed in a
more readable fashion. Members of objects and elements of
arrays are printed one per line, with indentation.
@@ -563,27 +560,27 @@ TABLE FORMATTING OPTIONS
Equivalent to --format=list --data=bare --no-headings.
PKI Options
- PKI configuration is required to use SSL for the connection to the
+ PKI configuration is required to use SSL for the connection to the
database.
-p privkey.pem
--private-key=privkey.pem
- Specifies a PEM file containing the private key used as
+ Specifies a PEM file containing the private key used as
identity for outgoing SSL connections.
-c cert.pem
--certificate=cert.pem
- Specifies a PEM file containing a certificate that certi‐
+ Specifies a PEM file containing a certificate that certi‐
fies the private key specified on -p or --private-key to be
trustworthy. The certificate must be signed by the certifi‐
- cate authority (CA) that the peer in SSL connections will
+ cate authority (CA) that the peer in SSL connections will
use to verify it.
-C cacert.pem
--ca-cert=cacert.pem
Specifies a PEM file containing the CA certificate for ver‐
ifying certificates presented to this program by SSL peers.
- (This may be the same certificate that SSL peers use to
+ (This may be the same certificate that SSL peers use to
verify the certificate specified on -c or --certificate, or
it may be a different one, depending on the PKI design in
use.)
@@ -602,14 +599,14 @@ TABLE FORMATTING OPTIONS
the SSL peer on its first SSL connection and save it to
the named PEM file. If it is successful, it will immedi‐
ately drop the connection and reconnect, and from then on
- all SSL connections must be authenticated by a certifi‐
+ all SSL connections must be authenticated by a certifi‐
cate 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, but
+ This option exposes the SSL connection to a man-in-the-
+ middle attack obtaining the initial CA certificate, but
it may be useful for bootstrapping.
- This option is only useful if the SSL peer sends its CA
+ This option is only useful if the SSL peer sends its CA
certificate as part of the SSL certificate chain. The SSL
protocol does not require the server to send the CA cer‐
tificate.
@@ -625,6 +622,4 @@ TABLE FORMATTING OPTIONS
--version
Prints version information to the console.
-
-
-OVN 22.12.90 ovn-ic-sbctl ovn-ic-sbctl(8)
+OVN 24.03.90 ovn-ic-sbctl ovn-ic-sbctl(8)
diff --git a/src/static/support/dist-docs/ovn-ic.8 b/src/static/support/dist-docs/ovn-ic.8
index 3ccbb118..d4bd94b1 100644
--- a/src/static/support/dist-docs/ovn-ic.8
+++ b/src/static/support/dist-docs/ovn-ic.8
@@ -1,6 +1,6 @@
'\" p
.\" -*- nroff -*-
-.TH "ovn-ic" 8 "ovn-ic" "OVN 22\[char46]12\[char46]90" "OVN Manual"
+.TH "ovn-ic" 8 "ovn-ic" "OVN 24\[char46]03\[char46]90" "OVN Manual"
.fp 5 L CR \\" Make fixed-width font available as \\fL.
.de TQ
. br
diff --git a/src/static/support/dist-docs/ovn-ic.8.html b/src/static/support/dist-docs/ovn-ic.8.html
index b7af51be..e04396b9 100644
--- a/src/static/support/dist-docs/ovn-ic.8.html
+++ b/src/static/support/dist-docs/ovn-ic.8.html
@@ -1,7 +1,5 @@
-ovn-ic(8) OVN Manual ovn-ic(8)
-
-
+ovn-ic(8) OVN Manual ovn-ic(8)
NAME
ovn-ic - Open Virtual Network interconnection controller
@@ -28,7 +26,7 @@
--ic-nb-db=database
The OVSDB database containing the OVN Interconnection Northbound
- Database. If the OVN_IC_NB_DB environment variable is set, its
+ Database. If the OVN_IC_NB_DB environment variable is set, its
value is used as the default. Otherwise, the default is
unix:/ovn_ic_nb_db.sock.
@@ -44,7 +42,7 @@
Daemon Options
--pidfile[=pidfile]
Causes a file (by default, program.pid) to be created indicating
- the PID of the running process. If the pidfile argument is not
+ the PID of the running process. If the pidfile argument is not
specified, or if it does not begin with /, then it is created in
.
@@ -62,13 +60,13 @@
Runs this program as a background process. The process forks,
and in the child it starts a new session, closes the standard
file descriptors (which has the side effect of disabling logging
- to the console), and changes its current directory to the root
- (unless --no-chdir is specified). After the child completes its
+ to the console), and changes its current directory to the root
+ (unless --no-chdir is specified). After the child completes its
initialization, the parent exits.
--monitor
- Creates an additional process to monitor this program. If it
- dies due to a signal that indicates a programming error (SIGA‐
+ Creates an additional process to monitor this program. If it
+ dies due to a signal that indicates a programming error (SIGA‐‐
BRT, SIGALRM, SIGBUS, SIGFPE, SIGILL, SIGPIPE, SIGSEGV, SIGXCPU,
or SIGXFSZ) then the monitor process starts a new copy of it. If
the daemon dies or exits for another reason, the monitor process
@@ -79,10 +77,10 @@
--no-chdir
By default, when --detach is specified, the daemon changes its
- current working directory to the root directory after it
- detaches. Otherwise, invoking the daemon from a carelessly cho‐
- sen directory would prevent the administrator from unmounting
- the file system that holds that directory.
+ current working directory to the root directory after it de‐
+ taches. Otherwise, invoking the daemon from a carelessly chosen
+ directory would prevent the administrator from unmounting the
+ file system that holds that directory.
Specifying --no-chdir suppresses this behavior, preventing the
daemon from changing its current working directory. This may be
@@ -101,21 +99,21 @@
implementations that are typically enforced from kernel-space
(e.g. DAC or MAC), self-confinement is imposed from the user-
space daemon itself and hence should not be considered as a full
- confinement strategy, but instead should be viewed as an addi‐
+ confinement strategy, but instead should be viewed as an addi‐
tional layer of security.
--user=user:group
- Causes this program to run as a different user specified in
- user:group, thus dropping most of the root privileges. Short
- forms user and :group are also allowed, with current user or
- group assumed, respectively. Only daemons started by the root
+ Causes this program to run as a different user specified in
+ user:group, thus dropping most of the root privileges. Short
+ forms user and :group are also allowed, with current user or
+ group assumed, respectively. Only daemons started by the root
user accepts this argument.
On Linux, daemons will be granted CAP_IPC_LOCK and
- CAP_NET_BIND_SERVICES before dropping root privileges. Daemons
- that interact with a datapath, such as ovs-vswitchd, will be
- granted three additional capabilities, namely CAP_NET_ADMIN,
- CAP_NET_BROADCAST and CAP_NET_RAW. The capability change will
+ CAP_NET_BIND_SERVICES before dropping root privileges. Daemons
+ that interact with a datapath, such as ovs-vswitchd, will be
+ granted three additional capabilities, namely CAP_NET_ADMIN,
+ CAP_NET_BROADCAST and CAP_NET_RAW. The capability change will
apply even if the new user is root.
On Windows, this option is not currently supported. For security
@@ -130,13 +128,13 @@
words separated by spaces or commas or colons, up to one from each
category below:
- · A valid module name, as displayed by the vlog/list command
+ • A valid module name, as displayed by the vlog/list command
on ovs-appctl(8), limits the log level change to the speci‐
fied module.
- · syslog, console, or file, to limit the log level change to
- only to the system log, to the console, or to a file,
- respectively. (If --detach is specified, the daemon closes
+ • syslog, console, or file, to limit the log level change to
+ only to the system log, to the console, or to a file, re‐
+ spectively. (If --detach is specified, the daemon closes
its standard file descriptors, so logging to the console
will have no effect.)
@@ -144,15 +142,15 @@
only useful along with the --syslog-target option (the word
has no effect otherwise).
- · off, emer, err, warn, info, or dbg, to control the log
- level. Messages of the given severity or higher will be
- logged, and messages of lower severity will be filtered
- out. off filters out all messages. See ovs-appctl(8) for a
+ • off, emer, err, warn, info, or dbg, to control the log
+ level. Messages of the given severity or higher will be
+ logged, and messages of lower severity will be filtered
+ out. off filters out all messages. See ovs-appctl(8) for a
definition of each log level.
Case is not significant within spec.
- Regardless of the log levels set for file, logging to a file will
+ Regardless of the log levels set for file, logging to a file will
not take place unless --log-file is also specified (see below).
For compatibility with older versions of OVS, any is accepted as a
@@ -160,22 +158,22 @@
-v
--verbose
- Sets the maximum logging verbosity level, equivalent to --ver‐
+ Sets the maximum logging verbosity level, equivalent to --ver‐‐
bose=dbg.
-vPATTERN:destination:pattern
--verbose=PATTERN:destination:pattern
- Sets the log pattern for destination to pattern. Refer to
- ovs-appctl(8) for a description of the valid syntax for pattern.
+ Sets the log pattern for destination to pattern. Refer to ovs-ap‐‐
+ pctl(8) for a description of the valid syntax for pattern.
-vFACILITY:facility
--verbose=FACILITY:facility
Sets the RFC5424 facility of the log message. facility can be one
of kern, user, mail, daemon, auth, syslog, lpr, news, uucp, clock,
- ftp, ntp, audit, alert, clock2, local0, local1, local2, local3,
+ ftp, ntp, audit, alert, clock2, local0, local1, local2, local3,
local4, local5, local6 or local7. If this option is not specified,
- daemon is used as the default for the local system syslog and
- local0 is used while sending a message to the target provided via
+ daemon is used as the default for the local system syslog and lo‐‐
+ cal0 is used while sending a message to the target provided via
the --syslog-target option.
--log-file[=file]
@@ -184,64 +182,64 @@
if file is omitted is /usr/local/var/log/ovn/program.log.
--syslog-target=host:port
- Send syslog messages to UDP port on host, in addition to the sys‐
- tem syslog. The host must be a numerical IP address, not a host‐
+ Send syslog messages to UDP port on host, in addition to the sys‐
+ tem syslog. The host must be a numerical IP address, not a host‐
name.
--syslog-method=method
- Specify method as how syslog messages should be sent to syslog
+ Specify method as how syslog messages should be sent to syslog
daemon. The following forms are supported:
- · libc, to use the libc syslog() function. Downside of using
- this options is that libc adds fixed prefix to every mes‐
- sage before it is actually sent to the syslog daemon over
+ • libc, to use the libc syslog() function. Downside of using
+ this options is that libc adds fixed prefix to every mes‐
+ sage before it is actually sent to the syslog daemon over
/dev/log UNIX domain socket.
- · unix:file, to use a UNIX domain socket directly. It is pos‐
+ • unix:file, to use a UNIX domain socket directly. It is pos‐
sible to specify arbitrary message format with this option.
- However, rsyslogd 8.9 and older versions use hard coded
- parser function anyway that limits UNIX domain socket use.
- If you want to use arbitrary message format with older
- rsyslogd versions, then use UDP socket to localhost IP
- address instead.
-
- · udp:ip:port, to use a UDP socket. With this method it is
- possible to use arbitrary message format also with older
- rsyslogd. When sending syslog messages over UDP socket
- extra precaution needs to be taken into account, for exam‐
- ple, syslog daemon needs to be configured to listen on the
- specified UDP port, accidental iptables rules could be
- interfering with local syslog traffic and there are some
- security considerations that apply to UDP sockets, but do
- not apply to UNIX domain sockets.
-
- · null, to discard all messages logged to syslog.
-
- The default is taken from the OVS_SYSLOG_METHOD environment vari‐
+ However, rsyslogd 8.9 and older versions use hard coded
+ parser function anyway that limits UNIX domain socket use.
+ If you want to use arbitrary message format with older
+ rsyslogd versions, then use UDP socket to localhost IP ad‐
+ dress instead.
+
+ • udp:ip:port, to use a UDP socket. With this method it is
+ possible to use arbitrary message format also with older
+ rsyslogd. When sending syslog messages over UDP socket ex‐
+ tra precaution needs to be taken into account, for example,
+ syslog daemon needs to be configured to listen on the spec‐
+ ified UDP port, accidental iptables rules could be inter‐
+ fering with local syslog traffic and there are some secu‐
+ rity considerations that apply to UDP sockets, but do not
+ apply to UNIX domain sockets.
+
+ • null, to discard all messages logged to syslog.
+
+ The default is taken from the OVS_SYSLOG_METHOD environment vari‐
able; if it is unset, the default is libc.
PKI Options
- PKI configuration is required in order to use SSL for the connections
+ PKI configuration is required in order to use SSL for the connections
to the Northbound and Southbound databases.
-p privkey.pem
--private-key=privkey.pem
- Specifies a PEM file containing the private key used as
+ Specifies a PEM file containing the private key used as
identity for outgoing SSL connections.
-c cert.pem
--certificate=cert.pem
- Specifies a PEM file containing a certificate that certi‐
+ Specifies a PEM file containing a certificate that certi‐
fies the private key specified on -p or --private-key to be
trustworthy. The certificate must be signed by the certifi‐
- cate authority (CA) that the peer in SSL connections will
+ cate authority (CA) that the peer in SSL connections will
use to verify it.
-C cacert.pem
--ca-cert=cacert.pem
Specifies a PEM file containing the CA certificate for ver‐
ifying certificates presented to this program by SSL peers.
- (This may be the same certificate that SSL peers use to
+ (This may be the same certificate that SSL peers use to
verify the certificate specified on -c or --certificate, or
it may be a different one, depending on the PKI design in
use.)
@@ -256,9 +254,9 @@
Other Options
--unixctl=socket
Sets the name of the control socket on which program listens for
- runtime management commands (see RUNTIME MANAGEMENT COMMANDS,
- below). If socket does not begin with /, it is interpreted as
- relative to . If --unixctl is not used at all, the default
+ runtime management commands (see RUNTIME MANAGEMENT COMMANDS,
+ below). If socket does not begin with /, it is interpreted as
+ relative to . If --unixctl is not used at all, the default
socket is /program.pid.ctl, where pid is program’s process ID.
On Windows a local named pipe is used to listen for runtime man‐
@@ -285,30 +283,28 @@
exit Causes ovn-ic to gracefully terminate.
- pause Pauses the ovn-ic operation from processing any database
- changes. This will also instruct ovn-ic to drop any lock
+ pause Pauses the ovn-ic operation from processing any database
+ changes. This will also instruct ovn-ic to drop any lock
on SB DB.
- resume Resumes the ovn-ic operation to process database con‐
- tents. This will also instruct ovn-northd to aspire for
+ resume Resumes the ovn-ic operation to process database con‐
+ tents. This will also instruct ovn-northd to aspire for
the lock on SB DB.
is-paused
- Returns "true" if ovn-ic is currently paused, "false"
+ Returns "true" if ovn-ic is currently paused, "false"
otherwise.
- status Prints this server’s status. Status will be "active" if
- ovn-ic has acquired OVSDB lock on SB DB, "standby" if it
+ status Prints this server’s status. Status will be "active" if
+ ovn-ic has acquired OVSDB lock on SB DB, "standby" if it
has not or "paused" if this instance is paused.
ACTIVE-STANDBY FOR HIGH AVAILABILITY
- You may run ovn-ic more than once in an OVN deployment. When connected
- to a standalone or clustered DB setup, OVN will automatically ensure
- that only one of them is active at a time. If multiple instances of
- ovn-ic are running and the active ovn-ic fails, one of the hot standby
+ You may run ovn-ic more than once in an OVN deployment. When connected
+ to a standalone or clustered DB setup, OVN will automatically ensure
+ that only one of them is active at a time. If multiple instances of
+ ovn-ic are running and the active ovn-ic fails, one of the hot standby
instances of ovn-ic will automatically take over.
-
-
-OVN 22.12.90 ovn-ic ovn-ic(8)
+OVN 24.03.90 ovn-ic ovn-ic(8)
diff --git a/src/static/support/dist-docs/ovn-ic.8.pdf b/src/static/support/dist-docs/ovn-ic.8.pdf
index ed131cc8..53df4096 100644
Binary files a/src/static/support/dist-docs/ovn-ic.8.pdf and b/src/static/support/dist-docs/ovn-ic.8.pdf differ
diff --git a/src/static/support/dist-docs/ovn-ic.8.txt b/src/static/support/dist-docs/ovn-ic.8.txt
index e146e463..5d651de1 100644
--- a/src/static/support/dist-docs/ovn-ic.8.txt
+++ b/src/static/support/dist-docs/ovn-ic.8.txt
@@ -1,7 +1,5 @@
ovn-ic(8) OVN Manual ovn-ic(8)
-
-
NAME
ovn-ic - Open Virtual Network interconnection controller
@@ -27,7 +25,7 @@ OPTIONS
--ic-nb-db=database
The OVSDB database containing the OVN Interconnection Northbound
- Database. If the OVN_IC_NB_DB environment variable is set, its
+ Database. If the OVN_IC_NB_DB environment variable is set, its
value is used as the default. Otherwise, the default is
unix:/ovn_ic_nb_db.sock.
@@ -43,7 +41,7 @@ OPTIONS
Daemon Options
--pidfile[=pidfile]
Causes a file (by default, program.pid) to be created indicating
- the PID of the running process. If the pidfile argument is not
+ the PID of the running process. If the pidfile argument is not
specified, or if it does not begin with /, then it is created in
.
@@ -61,13 +59,13 @@ OPTIONS
Runs this program as a background process. The process forks,
and in the child it starts a new session, closes the standard
file descriptors (which has the side effect of disabling logging
- to the console), and changes its current directory to the root
- (unless --no-chdir is specified). After the child completes its
+ to the console), and changes its current directory to the root
+ (unless --no-chdir is specified). After the child completes its
initialization, the parent exits.
--monitor
- Creates an additional process to monitor this program. If it
- dies due to a signal that indicates a programming error (SIGA‐
+ Creates an additional process to monitor this program. If it
+ dies due to a signal that indicates a programming error (SIGA‐
BRT, SIGALRM, SIGBUS, SIGFPE, SIGILL, SIGPIPE, SIGSEGV, SIGXCPU,
or SIGXFSZ) then the monitor process starts a new copy of it. If
the daemon dies or exits for another reason, the monitor process
@@ -78,10 +76,10 @@ OPTIONS
--no-chdir
By default, when --detach is specified, the daemon changes its
- current working directory to the root directory after it
- detaches. Otherwise, invoking the daemon from a carelessly cho‐
- sen directory would prevent the administrator from unmounting
- the file system that holds that directory.
+ current working directory to the root directory after it de‐
+ taches. Otherwise, invoking the daemon from a carelessly chosen
+ directory would prevent the administrator from unmounting the
+ file system that holds that directory.
Specifying --no-chdir suppresses this behavior, preventing the
daemon from changing its current working directory. This may be
@@ -100,21 +98,21 @@ OPTIONS
implementations that are typically enforced from kernel-space
(e.g. DAC or MAC), self-confinement is imposed from the user-
space daemon itself and hence should not be considered as a full
- confinement strategy, but instead should be viewed as an addi‐
+ confinement strategy, but instead should be viewed as an addi‐
tional layer of security.
--user=user:group
- Causes this program to run as a different user specified in
- user:group, thus dropping most of the root privileges. Short
- forms user and :group are also allowed, with current user or
- group assumed, respectively. Only daemons started by the root
+ Causes this program to run as a different user specified in
+ user:group, thus dropping most of the root privileges. Short
+ forms user and :group are also allowed, with current user or
+ group assumed, respectively. Only daemons started by the root
user accepts this argument.
On Linux, daemons will be granted CAP_IPC_LOCK and
- CAP_NET_BIND_SERVICES before dropping root privileges. Daemons
- that interact with a datapath, such as ovs-vswitchd, will be
- granted three additional capabilities, namely CAP_NET_ADMIN,
- CAP_NET_BROADCAST and CAP_NET_RAW. The capability change will
+ CAP_NET_BIND_SERVICES before dropping root privileges. Daemons
+ that interact with a datapath, such as ovs-vswitchd, will be
+ granted three additional capabilities, namely CAP_NET_ADMIN,
+ CAP_NET_BROADCAST and CAP_NET_RAW. The capability change will
apply even if the new user is root.
On Windows, this option is not currently supported. For security
@@ -129,13 +127,13 @@ OPTIONS
words separated by spaces or commas or colons, up to one from each
category below:
- · A valid module name, as displayed by the vlog/list command
+ • A valid module name, as displayed by the vlog/list command
on ovs-appctl(8), limits the log level change to the speci‐
fied module.
- · syslog, console, or file, to limit the log level change to
- only to the system log, to the console, or to a file,
- respectively. (If --detach is specified, the daemon closes
+ • syslog, console, or file, to limit the log level change to
+ only to the system log, to the console, or to a file, re‐
+ spectively. (If --detach is specified, the daemon closes
its standard file descriptors, so logging to the console
will have no effect.)
@@ -143,15 +141,15 @@ OPTIONS
only useful along with the --syslog-target option (the word
has no effect otherwise).
- · off, emer, err, warn, info, or dbg, to control the log
- level. Messages of the given severity or higher will be
- logged, and messages of lower severity will be filtered
- out. off filters out all messages. See ovs-appctl(8) for a
+ • off, emer, err, warn, info, or dbg, to control the log
+ level. Messages of the given severity or higher will be
+ logged, and messages of lower severity will be filtered
+ out. off filters out all messages. See ovs-appctl(8) for a
definition of each log level.
Case is not significant within spec.
- Regardless of the log levels set for file, logging to a file will
+ Regardless of the log levels set for file, logging to a file will
not take place unless --log-file is also specified (see below).
For compatibility with older versions of OVS, any is accepted as a
@@ -159,22 +157,22 @@ OPTIONS
-v
--verbose
- Sets the maximum logging verbosity level, equivalent to --ver‐
+ Sets the maximum logging verbosity level, equivalent to --ver‐
bose=dbg.
-vPATTERN:destination:pattern
--verbose=PATTERN:destination:pattern
- Sets the log pattern for destination to pattern. Refer to
- ovs-appctl(8) for a description of the valid syntax for pattern.
+ Sets the log pattern for destination to pattern. Refer to ovs-ap‐
+ pctl(8) for a description of the valid syntax for pattern.
-vFACILITY:facility
--verbose=FACILITY:facility
Sets the RFC5424 facility of the log message. facility can be one
of kern, user, mail, daemon, auth, syslog, lpr, news, uucp, clock,
- ftp, ntp, audit, alert, clock2, local0, local1, local2, local3,
+ ftp, ntp, audit, alert, clock2, local0, local1, local2, local3,
local4, local5, local6 or local7. If this option is not specified,
- daemon is used as the default for the local system syslog and
- local0 is used while sending a message to the target provided via
+ daemon is used as the default for the local system syslog and lo‐
+ cal0 is used while sending a message to the target provided via
the --syslog-target option.
--log-file[=file]
@@ -183,64 +181,64 @@ OPTIONS
if file is omitted is /usr/local/var/log/ovn/program.log.
--syslog-target=host:port
- Send syslog messages to UDP port on host, in addition to the sys‐
- tem syslog. The host must be a numerical IP address, not a host‐
+ Send syslog messages to UDP port on host, in addition to the sys‐
+ tem syslog. The host must be a numerical IP address, not a host‐
name.
--syslog-method=method
- Specify method as how syslog messages should be sent to syslog
+ Specify method as how syslog messages should be sent to syslog
daemon. The following forms are supported:
- · libc, to use the libc syslog() function. Downside of using
- this options is that libc adds fixed prefix to every mes‐
- sage before it is actually sent to the syslog daemon over
+ • libc, to use the libc syslog() function. Downside of using
+ this options is that libc adds fixed prefix to every mes‐
+ sage before it is actually sent to the syslog daemon over
/dev/log UNIX domain socket.
- · unix:file, to use a UNIX domain socket directly. It is pos‐
+ • unix:file, to use a UNIX domain socket directly. It is pos‐
sible to specify arbitrary message format with this option.
- However, rsyslogd 8.9 and older versions use hard coded
- parser function anyway that limits UNIX domain socket use.
- If you want to use arbitrary message format with older
- rsyslogd versions, then use UDP socket to localhost IP
- address instead.
-
- · udp:ip:port, to use a UDP socket. With this method it is
- possible to use arbitrary message format also with older
- rsyslogd. When sending syslog messages over UDP socket
- extra precaution needs to be taken into account, for exam‐
- ple, syslog daemon needs to be configured to listen on the
- specified UDP port, accidental iptables rules could be
- interfering with local syslog traffic and there are some
- security considerations that apply to UDP sockets, but do
- not apply to UNIX domain sockets.
-
- · null, to discard all messages logged to syslog.
-
- The default is taken from the OVS_SYSLOG_METHOD environment vari‐
+ However, rsyslogd 8.9 and older versions use hard coded
+ parser function anyway that limits UNIX domain socket use.
+ If you want to use arbitrary message format with older
+ rsyslogd versions, then use UDP socket to localhost IP ad‐
+ dress instead.
+
+ • udp:ip:port, to use a UDP socket. With this method it is
+ possible to use arbitrary message format also with older
+ rsyslogd. When sending syslog messages over UDP socket ex‐
+ tra precaution needs to be taken into account, for example,
+ syslog daemon needs to be configured to listen on the spec‐
+ ified UDP port, accidental iptables rules could be inter‐
+ fering with local syslog traffic and there are some secu‐
+ rity considerations that apply to UDP sockets, but do not
+ apply to UNIX domain sockets.
+
+ • null, to discard all messages logged to syslog.
+
+ The default is taken from the OVS_SYSLOG_METHOD environment vari‐
able; if it is unset, the default is libc.
PKI Options
- PKI configuration is required in order to use SSL for the connections
+ PKI configuration is required in order to use SSL for the connections
to the Northbound and Southbound databases.
-p privkey.pem
--private-key=privkey.pem
- Specifies a PEM file containing the private key used as
+ Specifies a PEM file containing the private key used as
identity for outgoing SSL connections.
-c cert.pem
--certificate=cert.pem
- Specifies a PEM file containing a certificate that certi‐
+ Specifies a PEM file containing a certificate that certi‐
fies the private key specified on -p or --private-key to be
trustworthy. The certificate must be signed by the certifi‐
- cate authority (CA) that the peer in SSL connections will
+ cate authority (CA) that the peer in SSL connections will
use to verify it.
-C cacert.pem
--ca-cert=cacert.pem
Specifies a PEM file containing the CA certificate for ver‐
ifying certificates presented to this program by SSL peers.
- (This may be the same certificate that SSL peers use to
+ (This may be the same certificate that SSL peers use to
verify the certificate specified on -c or --certificate, or
it may be a different one, depending on the PKI design in
use.)
@@ -255,9 +253,9 @@ OPTIONS
Other Options
--unixctl=socket
Sets the name of the control socket on which program listens for
- runtime management commands (see RUNTIME MANAGEMENT COMMANDS,
- below). If socket does not begin with /, it is interpreted as
- relative to . If --unixctl is not used at all, the default
+ runtime management commands (see RUNTIME MANAGEMENT COMMANDS,
+ below). If socket does not begin with /, it is interpreted as
+ relative to . If --unixctl is not used at all, the default
socket is /program.pid.ctl, where pid is program’s process ID.
On Windows a local named pipe is used to listen for runtime man‐
@@ -284,29 +282,27 @@ RUNTIME MANAGEMENT COMMANDS
exit Causes ovn-ic to gracefully terminate.
- pause Pauses the ovn-ic operation from processing any database
- changes. This will also instruct ovn-ic to drop any lock
+ pause Pauses the ovn-ic operation from processing any database
+ changes. This will also instruct ovn-ic to drop any lock
on SB DB.
- resume Resumes the ovn-ic operation to process database con‐
- tents. This will also instruct ovn-northd to aspire for
+ resume Resumes the ovn-ic operation to process database con‐
+ tents. This will also instruct ovn-northd to aspire for
the lock on SB DB.
is-paused
- Returns "true" if ovn-ic is currently paused, "false"
+ Returns "true" if ovn-ic is currently paused, "false"
otherwise.
- status Prints this server’s status. Status will be "active" if
- ovn-ic has acquired OVSDB lock on SB DB, "standby" if it
+ status Prints this server’s status. Status will be "active" if
+ ovn-ic has acquired OVSDB lock on SB DB, "standby" if it
has not or "paused" if this instance is paused.
ACTIVE-STANDBY FOR HIGH AVAILABILITY
- You may run ovn-ic more than once in an OVN deployment. When connected
- to a standalone or clustered DB setup, OVN will automatically ensure
- that only one of them is active at a time. If multiple instances of
- ovn-ic are running and the active ovn-ic fails, one of the hot standby
+ You may run ovn-ic more than once in an OVN deployment. When connected
+ to a standalone or clustered DB setup, OVN will automatically ensure
+ that only one of them is active at a time. If multiple instances of
+ ovn-ic are running and the active ovn-ic fails, one of the hot standby
instances of ovn-ic will automatically take over.
-
-
-OVN 22.12.90 ovn-ic ovn-ic(8)
+OVN 24.03.90 ovn-ic ovn-ic(8)
diff --git a/src/static/support/dist-docs/ovn-nb.5 b/src/static/support/dist-docs/ovn-nb.5
index f2917cf3..a6b03f75 100644
--- a/src/static/support/dist-docs/ovn-nb.5
+++ b/src/static/support/dist-docs/ovn-nb.5
@@ -1,6 +1,6 @@
'\" p
.\" -*- nroff -*-
-.TH "ovn-nb" 5 " DB Schema 7.0.0" "Open vSwitch 22.12.90" "Open vSwitch Manual"
+.TH "ovn-nb" 5 " DB Schema 7.3.0" "Open vSwitch 24.03.90" "Open vSwitch Manual"
.fp 5 L CR \\" Make fixed-width font available as \\fL.
.de TQ
. br
@@ -129,6 +129,204 @@ Static_MAC_Binding configuration\[char46]
.TQ 1in
\fBChassis_Template_Var\fR
Chassis_Template_Var configuration\[char46]
+.\" check if in troff mode (TTY)
+.if t \{
+.bp
+.SH "TABLE RELATIONSHIPS"
+.PP
+The following diagram shows the relationship among tables in the
+database. Each node represents a table. Tables that are part of the
+``root set'' are shown with double borders. Each edge leads from the
+table that contains it and points to the table that its value
+represents. Edges are labeled with their column names, followed by a
+constraint on the number of allowed values: \fB?\fR for zero or one,
+\fB*\fR for zero or more, \fB+\fR for one or more. Thick lines
+represent strong references; thin lines represent weak references.
+.RS -1in
+.ps -3
+.PS
+linethick = 1;
+linethick = 0.500000;
+box at 0.290590,0.186144 wid 0.323682 height 0.148915 "NB_Global"
+box at 0.290590,0.186144 wid 0.268126 height 0.093359
+linethick = 1.000000;
+box at 1.600836,0.297830 wid 0.323682 height 0.148915 "Connection"
+linethick = 1.000000;
+box at 1.600836,0.074457 wid 0.223372 height 0.148915 "SSL"
+linethick = 0.500000;
+box at 1.600836,1.911086 wid 0.223372 height 0.148915 "Copp"
+box at 1.600836,1.911086 wid 0.167817 height 0.093359
+linethick = 0.500000;
+box at 0.290590,2.452958 wid 0.422948 height 0.148915 "Logical_Switch"
+box at 0.290590,2.452958 wid 0.367393 height 0.093359
+linethick = 1.000000;
+box at 1.600836,3.234732 wid 0.547054 height 0.148915 "Logical_Switch_Port"
+linethick = 1.000000;
+box at 1.600836,3.011359 wid 0.223372 height 0.148915 "ACL"
+linethick = 1.000000;
+box at 1.600836,2.564644 wid 0.223372 height 0.148915 "QoS"
+linethick = 0.500000;
+box at 2.818008,1.687713 wid 0.410559 height 0.148915 "Load_Balancer"
+box at 2.818008,1.687713 wid 0.355003 height 0.093359
+linethick = 0.500000;
+box at 1.600836,1.687713 wid 0.581185 height 0.148915 "Load_Balancer_Group"
+box at 1.600836,1.687713 wid 0.525630 height 0.093359
+linethick = 0.500000;
+box at 1.600836,2.341271 wid 0.223372 height 0.148915 "DNS"
+box at 1.600836,2.341271 wid 0.167817 height 0.093359
+linethick = 1.000000;
+box at 1.600836,2.788016 wid 0.500533 height 0.148915 "Forwarding_Group"
+linethick = 0.500000;
+box at 2.818008,3.123045 wid 0.419851 height 0.148915 "DHCP_Options"
+box at 2.818008,3.123045 wid 0.364295 height 0.093359
+linethick = 0.500000;
+box at 2.818008,3.387816 wid 0.223372 height 0.148915 "Mirror"
+box at 2.818008,3.387816 wid 0.167817 height 0.093359
+linethick = 0.500000;
+box at 4.043042,1.174761 wid 0.519147 height 0.148915 "HA_Chassis_Group"
+box at 4.043042,1.174761 wid 0.463592 height 0.093359
+linethick = 0.500000;
+box at 2.818008,0.922439 wid 0.348491 height 0.148915 "Address_Set"
+box at 2.818008,0.922439 wid 0.292935 height 0.093359
+linethick = 0.500000;
+box at 0.290590,3.205842 wid 0.333004 height 0.148915 "Port_Group"
+box at 0.290590,3.205842 wid 0.277448 height 0.093359
+linethick = 1.000000;
+box at 4.043042,1.687713 wid 0.758007 height 0.148915 "Load_Balancer_Health_Check"
+linethick = 0.500000;
+box at 0.290590,3.478952 wid 0.223372 height 0.148915 "Meter"
+box at 0.290590,3.478952 wid 0.167817 height 0.093359
+linethick = 1.000000;
+box at 1.600836,3.478952 wid 0.348491 height 0.148915 "Meter_Band"
+linethick = 0.500000;
+box at 0.290590,1.257498 wid 0.419851 height 0.148915 "Logical_Router"
+box at 0.290590,1.257498 wid 0.364295 height 0.093359
+linethick = 1.000000;
+box at 2.818008,0.657698 wid 0.543957 height 0.148915 "Logical_Router_Port"
+linethick = 1.000000;
+box at 1.600836,1.257498 wid 0.736295 height 0.148915 "Logical_Router_Static_Route"
+linethick = 1.000000;
+box at 1.600836,1.034125 wid 0.590478 height 0.148915 "Logical_Router_Policy"
+linethick = 1.000000;
+box at 1.600836,0.810753 wid 0.223372 height 0.148915 "NAT"
+linethick = 1.000000;
+box at 4.043042,0.657698 wid 0.463304 height 0.148915 "Gateway_Chassis"
+linethick = 0.500000;
+box at 2.818008,1.187180 wid 0.223372 height 0.148915 "BFD"
+box at 2.818008,1.187180 wid 0.167817 height 0.093359
+linethick = 1.000000;
+box at 5.011883,1.174761 wid 0.348491 height 0.148915 "HA_Chassis"
+linethick = 0.500000;
+box at 0.290590,3.702325 wid 0.556376 height 0.148915 "Static_MAC_Binding"
+box at 0.290590,3.702325 wid 0.500821 height 0.093359
+linethick = 0.500000;
+box at 0.290590,3.925697 wid 0.581185 height 0.148915 "Chassis_Template_Var"
+box at 0.290590,3.925697 wid 0.525630 height 0.093359
+linethick = 1.000000;
+spline -> from 0.454369,0.199838 to 0.454369,0.199838 to 0.704934,0.221332 to 1.187686,0.262743 to 1.437774,0.284198
+"connections*" at 0.906922,0.290075
+linethick = 1.000000;
+spline -> from 0.454459,0.165865 to 0.454459,0.165865 to 0.517122,0.158306 to 0.589703,0.150044 to 0.655643,0.143745 to 0.956511,0.115007 to 1.312507,0.091705 to 1.487899,0.080929
+"ssl?" at 0.906922,0.174251
+linethick = 0.500000;
+spline -> from 0.338603,2.376892 to 0.338603,2.376892 to 0.397603,2.282331 to 0.511880,2.123915 to 0.655643,2.046539 to 0.727956,2.007612 to 1.256485,1.947361 to 1.488257,1.922433
+"copp?" at 0.906922,2.072927
+linethick = 1.000000;
+spline -> from 0.331723,2.528636 to 0.331723,2.528636 to 0.386822,2.632639 to 0.500861,2.817144 to 0.655643,2.907982 to 0.850811,3.022379 to 0.972921,2.859764 to 1.158231,2.989618 to 1.213836,3.028633 to 1.179883,3.080456 to 1.232689,3.123045 to 1.260446,3.145383 to 1.292701,3.163550 to 1.326297,3.177846
+"ports*" at 0.906922,3.016124
+linethick = 1.000000;
+spline -> from 0.362876,2.528964 to 0.362876,2.528964 to 0.430186,2.599013 to 0.539638,2.700186 to 0.655643,2.754927 to 0.861175,2.851901 to 0.948142,2.762343 to 1.158231,2.849042 to 1.195222,2.864291 to 1.196592,2.882369 to 1.232689,2.899703 to 1.314919,2.939195 to 1.414276,2.968561 to 1.488405,2.987235
+"acls*" at 0.906922,2.875400
+linethick = 1.000000;
+spline -> from 0.503899,2.470917 to 0.503899,2.470917 to 0.784246,2.494952 to 1.271555,2.536767 to 1.487869,2.555322
+"qos_rules*" at 0.906922,2.552760
+linethick = 0.500000;
+spline -> from 0.503631,2.383921 to 0.503631,2.383921 to 0.692693,2.322895 to 0.979474,2.234023 to 1.232689,2.170645 to 1.556489,2.089575 to 1.648936,2.117542 to 1.968984,2.022772 to 2.210316,1.951293 to 2.478899,1.838832 to 2.647083,1.764166
+"load_balancer*" at 1.600836,2.197003
+linethick = 1.000000;
+spline -> from 0.319601,2.377815 to 0.319601,2.377815 to 0.365020,2.253352 to 0.473758,2.006153 to 0.655643,1.885234 to 0.844348,1.759729 to 0.936556,1.846457 to 1.158231,1.799400 to 1.207790,1.788856 to 1.260208,1.776556 to 1.310899,1.764017
+"load_balancer_group*" at 0.906922,1.911592
+linethick = 0.500000;
+spline -> from 0.502529,2.424038 to 0.502529,2.424038 to 0.552594,2.417665 to 0.605965,2.411351 to 0.655643,2.406437 to 0.956332,2.376654 to 1.312388,2.355954 to 1.487840,2.346722
+"dns_records*" at 0.906922,2.432795
+linethick = 1.000000;
+spline -> from 0.464942,2.528904 to 0.464942,2.528904 to 0.524419,2.553386 to 0.592175,2.578999 to 0.655643,2.597733 to 0.873923,2.662213 to 0.935156,2.650776 to 1.158231,2.695987 to 1.219971,2.708496 to 1.286536,2.722315 to 1.348693,2.735330
+"forwarding_groups*" at 0.906922,2.722345
+linethick = 0.500000;
+spline -> from 1.876269,3.209714 to 1.876269,3.209714 to 2.097646,3.189164 to 2.405722,3.160870 to 2.607383,3.142107
+"dhcpv4_options?" at 2.257522,3.218649
+linethick = 0.500000;
+spline -> from 1.876269,3.160274 to 1.876269,3.160274 to 1.907988,3.148957 to 1.939529,3.136448 to 1.968984,3.123045 to 2.004485,3.106963 to 2.005945,3.087306 to 2.043441,3.076584 to 2.228930,3.023272 to 2.449503,3.044716 to 2.607025,3.073606
+"dhcpv6_options?" at 2.257522,3.102793
+linethick = 0.500000;
+spline -> from 1.876269,3.268982 to 1.876269,3.268982 to 2.137317,3.302041 to 2.518957,3.350587 to 2.704475,3.373818
+"mirror_rules*" at 2.257522,3.371733
+linethick = 1.000000;
+spline -> from 1.874572,3.173379 to 1.874572,3.173379 to 1.907929,3.159678 to 1.940333,3.143298 to 1.968984,3.123045 to 2.014105,3.091475 to 2.005260,3.063479 to 2.043441,3.023868 to 2.657597,2.383980 to 3.064373,2.476993 to 3.589447,1.762171 to 3.642163,1.690334 to 3.616252,1.651229 to 3.663905,1.576027 to 3.744617,1.448883 to 3.868514,1.325850 to 3.951608,1.250261
+"ha_chassis_group?" at 2.818008,2.631358
+linethick = 1.000000;
+spline -> from 3.024464,1.687713 to 3.024464,1.687713 to 3.197801,1.687713 to 3.451850,1.687713 to 3.662713,1.687713
+"health_check*" at 3.377094,1.717169
+linethick = 0.500000;
+spline -> from 1.893007,1.687713 to 1.893007,1.687713 to 2.114385,1.687713 to 2.414627,1.687713 to 2.611225,1.687713
+"load_balancer*" at 2.257522,1.717169
+linethick = 1.000000;
+spline -> from 4.304537,1.174761 to 4.304537,1.174761 to 4.472811,1.174761 to 4.688440,1.174761 to 4.836164,1.174761
+"ha_chassis*" at 4.629767,1.204246
+linethick = 0.500000;
+spline -> from 0.458211,3.209714 to 0.458211,3.209714 to 0.520071,3.210905 to 0.591103,3.212692 to 0.655643,3.214181 to 0.881904,3.219244 to 1.138813,3.224903 to 1.326952,3.228775
+"ports*" at 0.906922,3.251708
+linethick = 1.000000;
+spline -> from 0.457914,3.173676 to 0.457914,3.173676 to 0.519743,3.162061 to 0.590835,3.148957 to 0.655643,3.138533 to 0.955975,3.090284 to 1.312209,3.045610 to 1.487750,3.024464
+"acls*" at 0.906922,3.165039
+linethick = 1.000000;
+spline -> from 0.403500,3.478952 to 0.403500,3.478952 to 0.629940,3.478952 to 1.153466,3.478952 to 1.425563,3.478952
+"bands+" at 0.906922,3.508437
+linethick = 0.500000;
+spline -> from 0.342058,1.332491 to 0.342058,1.332491 to 0.403024,1.422347 to 0.517718,1.570309 to 0.655643,1.646345 to 0.854653,1.756065 to 0.951418,1.646255 to 1.158231,1.740459 to 1.196651,1.757942 to 1.195311,1.779773 to 1.232689,1.799400 to 1.313460,1.841811 to 1.412906,1.870938 to 1.487452,1.888808
+"copp?" at 0.906922,1.766817
+linethick = 0.500000;
+spline -> from 0.502320,1.302679 to 0.502320,1.302679 to 0.552415,1.312924 to 0.605846,1.323318 to 0.655643,1.331955 to 1.236441,1.432711 to 1.387977,1.417552 to 1.968984,1.517086 to 2.189497,1.554851 to 2.440598,1.606704 to 2.611344,1.643307
+"load_balancer*" at 1.600836,1.543444
+linethick = 1.000000;
+spline -> from 0.388489,1.333683 to 0.388489,1.333683 to 0.458182,1.386428 to 0.557716,1.453946 to 0.655643,1.493290 to 0.866536,1.577993 to 0.935722,1.541121 to 1.158231,1.587404 to 1.207165,1.597560 to 1.259017,1.608937 to 1.309320,1.620225
+"load_balancer_group*" at 0.906922,1.613762
+linethick = 1.000000;
+spline -> from 0.347806,1.181253 to 0.347806,1.181253 to 0.411869,1.094138 to 0.527159,0.952341 to 0.655643,0.864541 to 0.882857,0.709282 to 0.962229,0.690876 to 1.232689,0.640126 to 1.687326,0.554828 to 2.228513,0.589435 to 2.545315,0.623060
+"ports*" at 1.600836,0.670624
+linethick = 1.000000;
+spline -> from 0.502469,1.257498 to 0.502469,1.257498 to 0.698114,1.257498 to 0.995467,1.257498 to 1.230842,1.257498
+"static_routes*" at 0.906922,1.286983
+linethick = 1.000000;
+spline -> from 0.502409,1.212198 to 0.502409,1.212198 to 0.552475,1.201804 to 0.605905,1.191112 to 0.655643,1.182028 to 0.872016,1.142416 to 1.117548,1.104056 to 1.303572,1.076328
+"policies*" at 0.906922,1.208386
+linethick = 1.000000;
+spline -> from 0.392123,1.181313 to 0.392123,1.181313 to 0.461934,1.130146 to 0.560129,1.065010 to 0.655643,1.024833 to 0.942126,0.904331 to 1.307563,0.846046 to 1.487095,0.823113
+"nat*" at 0.906922,1.051191
+linethick = 1.000000;
+spline -> from 3.001531,0.734002 to 3.001531,0.734002 to 3.232349,0.832048 to 3.630548,1.001215 to 3.860472,1.099022
+"ha_chassis_group?" at 3.377094,1.005683
+linethick = 1.000000;
+spline -> from 3.090582,0.657698 to 3.090582,0.657698 to 3.306211,0.657698 to 3.605530,0.657698 to 3.809841,0.657698
+"gateway_chassis*" at 3.377094,0.687183
+linethick = 0.500000;
+spline -> from 1.970950,1.236203 to 1.970950,1.236203 to 2.223241,1.221550 to 2.541473,1.203025 to 2.705369,1.193494
+"bfd?" at 2.257522,1.258034
+linethick = 0.500000;
+spline -> from 1.896224,1.063789 to 1.896224,1.063789 to 2.064587,1.081748 to 2.280306,1.106230 to 2.471572,1.132379 to 2.549693,1.143042 to 2.637493,1.157159 to 2.704624,1.168387
+"bfd_sessions*" at 2.257522,1.158737
+linethick = 1.000000;
+spline -> from 1.713893,0.800656 to 1.713893,0.800656 to 1.878950,0.787701 to 2.201798,0.771588 to 2.471572,0.813850 to 2.528249,0.822726 to 2.588381,0.839255 to 2.642199,0.856768
+"allowed_ext_ips?" at 2.257522,0.844378
+linethick = 1.000000;
+spline -> from 1.712820,0.828355 to 1.712820,0.828355 to 1.801395,0.842263 to 1.930266,0.861175 to 2.043441,0.872821 to 2.248765,0.893907 to 2.485868,0.907607 to 2.642199,0.915142
+"exempted_ext_ips?" at 2.257522,0.935365
+linethick = 0.500000;
+spline -> from 1.714101,0.782280 to 1.714101,0.782280 to 1.802318,0.760360 to 1.930087,0.731113 to 2.043441,0.714584 to 2.209333,0.690400 to 2.396906,0.676253 to 2.545434,0.668152
+"gateway_port?" at 2.257522,0.745081
+.ps +3
+.PE
+.RE\}
.bp
.SH "NB_Global TABLE"
.PP
@@ -195,18 +393,33 @@ optional string
optional string
.RE
.TQ 2.75in
+\fBoptions : ignore_chassis_features\fR
+optional string
+.TQ 2.75in
\fBoptions : mac_prefix\fR
optional string
.TQ 2.75in
\fBoptions : mac_binding_removal_limit\fR
optional string, containing an integer, in range 0 to 4,294,967,295
.TQ 2.75in
+\fBoptions : fdb_removal_limit\fR
+optional string, containing an integer, in range 0 to 4,294,967,295
+.TQ 2.75in
\fBoptions : controller_event\fR
optional string, either \fBtrue\fR or \fBfalse\fR
.TQ 2.75in
\fBoptions : northd_probe_interval\fR
optional string
.TQ 2.75in
+\fBoptions : ic_probe_interval\fR
+optional string
+.TQ 2.75in
+\fBoptions : nbctl_probe_interval\fR
+optional string
+.TQ 2.75in
+\fBoptions : northd_trim_timeout\fR
+optional string
+.TQ 2.75in
\fBoptions : use_logical_dp_groups\fR
optional string
.TQ 2.75in
@@ -227,6 +440,12 @@ optional string
.TQ 2.75in
\fBoptions : debug_drop_collector_set\fR
optional string
+.TQ 2.75in
+\fBoptions : use_common_zone\fR
+optional string, either \fBtrue\fR or \fBfalse\fR
+.TQ 2.75in
+\fBoptions : northd-backoff-interval-ms\fR
+optional string
.TQ .25in
\fIOptions for configuring interconnection route advertisement:\fR
.RS .25in
@@ -324,10 +543,18 @@ BFD option \fBdecay\-min\-rx\fR value to use when configuring BFD on tunnel inte
BFD option \fBmin\-tx\fR value to use when configuring BFD on tunnel interfaces\[char46]
.IP "\fBoptions : bfd-mult\fR: optional string"
BFD option \fBmult\fR value to use when configuring BFD on tunnel interfaces\[char46]
+.IP "\fBoptions : ignore_chassis_features\fR: optional string"
+When set to \fBfalse\fR, the \fBovn\-northd\fR will evaluate the features supported by each chassis and will only activate features that are universally supported by all chassis\[char46] This approach is crucial for maintaining backward compatibility during an upgrade when the \fBovn\-northd\fR is updated prior to the \fBovn\-controller\fR\[char46] However, if any chassis is poorly managed and the upgrade is unsuccessful, it will restrict \fBovn\-northd\fR from activating the new features\[char46]
+.IP
+Alternatively, setting this option to \fBtrue\fR instructs \fBovn\-northd\fR to bypass the support status of features on each chassis and to directly implement the latest features\[char46] This approach safeguards the operation of \fBovn\-northd\fR from being adversely affected by a mismatched configuration of a chassis\[char46]
+.IP
+The default setting for this option is \fBfalse\fR\[char46]
.IP "\fBoptions : mac_prefix\fR: optional string"
Configure a given OUI to be used as prefix when L2 address is dynamically assigned, e\[char46]g\[char46] \fB00:11:22\fR
.IP "\fBoptions : mac_binding_removal_limit\fR: optional string, containing an integer, in range 0 to 4,294,967,295"
MAC binding aging bulk removal limit\[char46] This limits how many rows can expire in a single transaction\[char46] Default value is 0 which is unlimited\[char46] When we hit the limit next batch removal is delayed by 5 s\[char46]
+.IP "\fBoptions : fdb_removal_limit\fR: optional string, containing an integer, in range 0 to 4,294,967,295"
+FDB aging bulk removal limit\[char46] This limits how many rows can expire in a single transaction\[char46] Default value is 0 which is unlimited\[char46] When we hit the limit next batch removal is delayed by 5 s\[char46]
.IP "\fBoptions : controller_event\fR: optional string, either \fBtrue\fR or \fBfalse\fR"
Value set by the CMS to enable/disable ovn-controller event reporting\[char46] Traffic into OVS can raise a \(cqcontroller\(cq event that results in a Controller_Event being written to the \fBController_Event\fR table in SBDB\[char46] When the CMS has seen the event and taken appropriate action, it can remove the corresponding row in \fBController_Event\fR table\[char46] The intention is for a CMS to see the events and take some sort of action\[char46] Please see the \fBController_Event\fR table in SBDB\[char46] It is possible to associate a meter to each controller event type in order to not overload the pinctrl thread under heavy load\[char46] Each event type relies on a meter with a defined name:
.RS
@@ -338,6 +565,18 @@ empty_lb_backends: event-elb
The inactivity probe interval of the connection to the OVN Northbound and Southbound databases from \fBovn\-northd\fR, in milliseconds\[char46] If the value is zero, it disables the connection keepalive feature\[char46]
.IP
If the value is nonzero, then it will be forced to a value of at least 1000 ms\[char46]
+.IP "\fBoptions : ic_probe_interval\fR: optional string"
+The inactivity probe interval of the connection to the OVN Northbound and Southbound databases from \fBovn\-ic\fR, in milliseconds\[char46] If the value is zero, it disables the connection keepalive feature\[char46]
+.IP
+If the value is nonzero, then it will be forced to a value of at least 1000 ms\[char46]
+.IP "\fBoptions : nbctl_probe_interval\fR: optional string"
+The inactivity probe interval of the connection to the OVN Northbound database from \fBovn\-nbctl\fR utility, in milliseconds\[char46] If the value is zero, it disables the connection keepalive feature\[char46]
+.IP
+If the value is nonzero, then it will be forced to a value of at least 1000 ms\[char46]
+.IP
+If the value is less than zero, then the default inactivity probe interval for \fBovn\-nbctl\fR would be left intact (120000 ms)\[char46]
+.IP "\fBoptions : northd_trim_timeout\fR: optional string"
+When used, this configuration value specifies the time, in milliseconds, since the last \fBovn\-northd\fR active operation after which memory trimming is performed\[char46] By default this is set to 30000 (30 seconds)\[char46]
.IP "\fBoptions : use_logical_dp_groups\fR: optional string"
Note: This option is deprecated, the only behavior is to always combine logical flows by datapath groups\[char46] Changing the value or removing this option all toghether will have no effect\[char46]
.IP
@@ -360,6 +599,10 @@ If set to a 8-bit number and if \fBdebug_drop_collector_set\fR is also configure
The observation_point_id will be set to the first 32 bits of the logical flow\(cqs UUID\[char46]
.IP "\fBoptions : debug_drop_collector_set\fR: optional string"
If set to a 32-bit number \fBovn\-northd\fR will add a \fBsample\fR action to every logical flow that contains a \(cqdrop\(cq action\[char46] The sample action will have the specified collector_set_id\[char46] The value must match that of the local OVS configuration as described in \fBovs\-actions\fR(7)\[char46]
+.IP "\fBoptions : use_common_zone\fR: optional string, either \fBtrue\fR or \fBfalse\fR"
+Default value is \fBfalse\fR\[char46] If set to \fBtrue\fR the SNAT and DNAT happens in common zone, instead of happening in separate zones, depending on the configuration\[char46] However, this option breaks traffic when there is configuration of DGP + LB + SNAT on this LR\[char46] The value \fBtrue\fR should be used only in case of HWOL compatibility with GDP\[char46]
+.IP "\fBoptions : northd-backoff-interval-ms\fR: optional string"
+Maximum interval that the northd incremental engine is delayed by in milliseconds\[char46] Setting the value to nonzero delays the next northd engine run by the previous run time, capped by the specified value\[char46] If the value is zero the engine won\(cqt be delayed at all\[char46] The recommended period is smaller than 500 ms, beyond that the latency of SB changes would be very noticeable\[char46]
.ST "Options for configuring interconnection route advertisement:"
.PP
.PP
@@ -460,6 +703,9 @@ optional string
\fBmeters : reject\fR
optional string
.TQ 3.00in
+\fBmeters : svc-monitor\fR
+optional string
+.TQ 3.00in
\fBexternal_ids\fR
map of string-string pairs
.SS "Details:
@@ -497,6 +743,8 @@ Rate limiting meter for packets that require replying with TCP RST packet\[char4
Rate limiting meter for BFD packets\[char46]
.IP "\fBmeters : reject\fR: optional string"
Rate limiting meter for packets that trigger a reject action
+.IP "\fBmeters : svc-monitor\fR: optional string"
+Rate limiting meter for packets that are arriving to service monitor MAC address\[char46]
.IP "\fBexternal_ids\fR: map of string-string pairs"
See \fBExternal IDs\fR at the beginning of this document\[char46]
.bp
@@ -555,6 +803,9 @@ optional string
.TQ 2.75in
\fBother_config : mac_only\fR
optional string, either \fBtrue\fR or \fBfalse\fR
+.TQ 2.75in
+\fBother_config : fdb_age_threshold\fR
+optional string, containing an integer, in range 0 to 4,294,967,295
.RE
.TQ .25in
\fIIP Multicast Snooping Options:\fR
@@ -613,6 +864,9 @@ optional weak reference to \fBCopp\fR
.TQ 2.75in
\fBother_config : vlan-passthru\fR
optional string, either \fBtrue\fR or \fBfalse\fR
+.TQ 2.75in
+\fBother_config : broadcast-arps-to-all-routers\fR
+optional string, either \fBtrue\fR or \fBfalse\fR
.RE
.TQ .25in
\fICommon Columns:\fR
@@ -688,15 +942,17 @@ Examples:
.RE
.IP "\fBother_config : mac_only\fR: optional string, either \fBtrue\fR or \fBfalse\fR"
Value used to request to assign L2 address only if neither subnet nor ipv6_prefix are specified
+.IP "\fBother_config : fdb_age_threshold\fR: optional string, containing an integer, in range 0 to 4,294,967,295"
+FDB aging \fBthreshold\fR value in seconds\[char46] FDB exceeding this timeout will be automatically removed\[char46] The value defaults to 0, which means disabled\[char46]
.ST "IP Multicast Snooping Options:"
.PP
.PP
.PP
-These options control IP Multicast Snooping configuration of the logical switch\[char46] To enable IP Multicast Snooping set \fBother_config:mcast_snoop\fR to true\[char46] To enable IP Multicast Querier set \fBother_config:mcast_snoop\fR to true\[char46] If IP Multicast Querier is enabled \fBother_config:mcast_eth_src\fR and \fBother_config:mcast_ip4_src\fR must be set\[char46]
+These options control IP Multicast Snooping configuration of the logical switch\[char46] To enable IP Multicast Snooping set \fBother_config:mcast_snoop\fR to true\[char46] To enable IP Multicast Querier set \fBother_config:mcast_querier\fR to true\[char46] If IP Multicast Querier is enabled \fBother_config:mcast_eth_src\fR and \fBother_config:mcast_ip4_src\fR must be set\[char46]
.IP "\fBother_config : mcast_snoop\fR: optional string, either \fBtrue\fR or \fBfalse\fR"
-Enables/disables IP Multicast Snooping on the logical switch\[char46]
+Enables/disables IP Multicast Snooping on the logical switch\[char46] Default: \fBfalse\fR\[char46]
.IP "\fBother_config : mcast_querier\fR: optional string, either \fBtrue\fR or \fBfalse\fR"
-Enables/disables IP Multicast Querier on the logical switch\[char46]
+Enables/disables IP Multicast Querier on the logical switch\[char46] Only applicable if \fBother_config:mcast_snoop\fR is enabled\[char46] Default: \fBtrue\fR\[char46]
.IP "\fBother_config : mcast_flood_unregistered\fR: optional string, either \fBtrue\fR or \fBfalse\fR"
Determines whether unregistered multicast traffic should be flooded or not\[char46] Only applicable if \fBother_config:mcast_snoop\fR is enabled\[char46] Default: \fBfalse\fR\[char46]
.IP "\fBother_config : mcast_table_size\fR: optional string, containing an integer, in range 1 to 32,766"
@@ -727,6 +983,8 @@ The control plane protection policy from table \fBCopp\fR used for metering pack
.PP
.IP "\fBother_config : vlan-passthru\fR: optional string, either \fBtrue\fR or \fBfalse\fR"
Determines whether VLAN tagged incoming traffic should be allowed\[char46] Note that this may have security implications when enabled for a logical switch with a tag=0 localnet port\[char46] If not properly isolated from other localnet ports, fabric traffic that belongs to other tagged networks may be passed through such a port\[char46]
+.IP "\fBother_config : broadcast-arps-to-all-routers\fR: optional string, either \fBtrue\fR or \fBfalse\fR"
+Determines whether arp requests and ipv6 neighbor solicitations should be sent to all routers and other switchports (default) or if it should only be sent to switchports where the ip/mac address is unknown\[char46] Setting this to false can significantly reduce the load if the logical switch can receive arp requests for ips it does not know about\[char46] However setting this to false also means that garps are no longer forwarded to all routers and therefor the mac bindings of the routers are no longer updated\[char46]
.ST "Common Columns:"
.PP
.IP "\fBexternal_ids\fR: map of string-string pairs"
@@ -769,6 +1027,9 @@ optional string
.TQ 2.50in
\fBoptions : arp_proxy\fR
optional string
+.TQ 2.50in
+\fBoptions : enable_router_port_acl\fR
+optional string, either \fBtrue\fR or \fBfalse\fR
.RE
.TQ .25in
\fIOptions for localnet ports:\fR
@@ -1023,7 +1284,10 @@ This form of \fBoptions:nat-addresses\fR is only valid for logical switch ports
.IP "\fBoptions : exclude-lb-vips-from-garp\fR: optional string"
If \fBoptions:nat-addresses\fR is set to \fBrouter\fR, Gratuitous ARPs will be sent for all SNAT and DNAT external IP addresses defined on the \fBoptions:router-port\fR\(cqs logical router, using the \fBoptions:router-port\fR\(cqs MAC address, not cosidering configured load balancers\[char46]
.IP "\fBoptions : arp_proxy\fR: optional string"
-Optional\[char46] A list of IPv4 addresses that this logical switch \fBrouter\fR port will reply to ARP requests\[char46] Example: \fB169\[char46]254\[char46]239\[char46]254 169\[char46]254\[char46]239\[char46]2\fR\[char46] The \fBoptions:router-port\fR\(cqs logical router should have a route to forward packets sent to configured proxy ARP IPs to an appropriate destination\[char46]
+Optional\[char46] A list of MAC and addresses/cidrs or just addresses/cidrs that this logical switch \fBrouter\fR port will reply to ARP/NDP requests\[char46] Examples: \fB169\[char46]254\[char46]239\[char46]254 169\[char46]254\[char46]239\[char46]2\fR, \fB0a:58:a9:fe:01:01 169\[char46]254\[char46]239\[char46]254 169\[char46]254\[char46]239\[char46]2
+169\[char46]254\[char46]238\[char46]0/24\fR, \fBfd7b:6b4d:7b25:d22f::1 fd7b:6b4d:7b25:d22f::2\fR, \fB0a:58:a9:fe:01:01 fd7b:6b4d:7b25:d22f::0/64\fR\[char46] The\fBoptions:router-port\fR\(cqs logical router should have a route to forward packets sent to configured proxy ARP MAC/IPs to an appropriate destination\[char46]
+.IP "\fBoptions : enable_router_port_acl\fR: optional string, either \fBtrue\fR or \fBfalse\fR"
+Optional\[char46] Enable conntrack for the router port whose peer is l3dgw_port if set to \fBtrue\fR\[char46] The default value is \fBfalse\fR\[char46]
.ST "Options for localnet ports:"
.PP
.PP
@@ -1032,7 +1296,7 @@ These options apply when \fBtype\fR is \fBlocalnet\fR\[char46]
.IP "\fBoptions : network_name\fR: optional string"
Required\[char46] The name of the network to which the \fBlocalnet\fR port is connected\[char46] Each hypervisor, via \fBovn\-controller\fR, uses its local configuration to determine exactly how to connect to this locally accessible network, if at all\[char46]
.IP "\fBoptions : ethtype\fR: optional string"
-Optional\[char46] VLAN EtherType field value for encapsulating VLAN headers\[char46] Supported values: 802\[char46]11q (default), 802\[char46]11ad\[char46]
+Optional\[char46] VLAN EtherType field value for encapsulating VLAN headers\[char46] Supported values: 802\[char46]1q (default), 802\[char46]1ad\[char46]
.IP "\fBoptions : localnet_learn_fdb\fR: optional string, either \fBtrue\fR or \fBfalse\fR"
Optional\[char46] Allows localnet port to learn MACs and store them in FDB table if set to \fBtrue\fR\[char46] The default value is \fBfalse\fR\[char46]
.ST "Options for l2gateway ports:"
@@ -1111,7 +1375,7 @@ When a large number of containers are nested within a VM, it may be too expensiv
.PP
These columns are used for VIFs that represent nested containers using shared VIFs\[char46] For VMs and for containers that have dedicated VIFs, they are empty\[char46]
.IP "\fBparent_name\fR: optional string"
-The VM interface through which the nested container sends its network traffic\[char46] This must match the \fBname\fR column for some other \fBLogical_Switch_Port\fR\[char46]
+The VM interface through which the nested container sends its network traffic\[char46] This must match the \fBname\fR column for some other \fBLogical_Switch_Port\fR\[char46] Note: for performance of the OVN Southbound database conditional monitoring, unlike for regular VIFs, \fBovn\-controller\fR will register to get updates about all OVN Southbound database \fBPort_Binding\fR table records that correspond to nested container ports even if \fBexternal_ids:ovn\-monitor\-all\fR is set to \fBfalse\fR\[char46] See \fBovn\-controller\fR(8) for more information\[char46]
.IP "\fBtag_request\fR: optional integer, in range 0 to 4,095"
The VLAN tag in the network traffic associated with a container\(cqs network interface\[char46] The client can request \fBovn\-northd\fR to allocate a tag that is unique within the scope of a specific parent (specified in \fBparent_name\fR) by setting a value of \fB0\fR in this column\[char46] The allocated value is written by \fBovn\-northd\fR in the \fBtag\fR column\[char46] (Note that these tags are allocated and managed locally in \fBovn\-northd\fR, so they cannot be reconstructed in the event that the database is lost\[char46]) The client can also request a specific non-zero tag and \fBovn\-northd\fR will honor it and copy that value to the \fBtag\fR column\[char46]
.IP
@@ -1438,6 +1702,9 @@ optional string
.TQ 2.75in
\fBoptions : affinity_timeout\fR
optional string
+.TQ 2.75in
+\fBoptions : ct_flush\fR
+optional string, either \fBtrue\fR or \fBfalse\fR
.RE
.SS "Details:
.IP "\fBname\fR: string"
@@ -1452,16 +1719,18 @@ Valid protocols are \fBtcp\fR, \fBudp\fR, or \fBsctp\fR\[char46] This column is
.PP
.PP
.PP
-OVN supports health checks for load balancer endpoints, for IPv4 load balancers only\[char46] When health checks are enabled, the load balancer uses only healthy endpoints\[char46]
+OVN supports health checks for load balancer endpoints\[char46] When health checks are enabled, the load balancer uses only healthy endpoints\[char46]
.PP
.PP
-Suppose that \fBvips\fR contains a key-value pair \fB10\[char46]0\[char46]0\[char46]10:80\fR=\fB10\[char46]0\[char46]0\[char46]4:8080,20\[char46]0\[char46]0\[char46]4:8080\fR\[char46] To enable health checks for this virtual\(cqs endpoints, add two key-value pairs to \fBip_port_mappings\fR, with keys \fB10\[char46]0\[char46]0\[char46]4\fR and \fB20\[char46]0\[char46]0\[char46]4\fR, and add to \fBhealth_check\fR a reference to a \fBLoad_Balancer_Health_Check\fR row whose \fBvip\fR is set to \fB10\[char46]0\[char46]0\[char46]10\fR\[char46]
+Suppose that \fBvips\fR contains a key-value pair \fB10\[char46]0\[char46]0\[char46]10:80\fR=\fB10\[char46]0\[char46]0\[char46]4:8080,20\[char46]0\[char46]0\[char46]4:8080\fR\[char46] To enable health checks for this virtual\(cqs endpoints, add two key-value pairs to \fBip_port_mappings\fR, with keys \fB10\[char46]0\[char46]0\[char46]4\fR and \fB20\[char46]0\[char46]0\[char46]4\fR, and add to \fBhealth_check\fR a reference to a \fBLoad_Balancer_Health_Check\fR row whose \fBvip\fR is set to \fB10\[char46]0\[char46]0\[char46]10\fR\[char46] The same approach can be used for IPv6 as well\[char46]
.IP "\fBhealth_check\fR: set of \fBLoad_Balancer_Health_Check\fRs"
Load balancer health checks associated with this load balancer\[char46]
.IP "\fBip_port_mappings\fR: map of string-string pairs"
-Maps from endpoint IP to a colon-separated pair of logical port name and source IP, e\[char46]g\[char46] \fB\fIport_name\fB:\fIsourc_ip\fB\fR\[char46] Health checks are sent to this port with the specified source IP\[char46]
+Maps from endpoint IP to a colon-separated pair of logical port name and source IP, e\[char46]g\[char46] \fB\fIport_name\fB:\fIsourc_ip\fB\fR for IPv4\[char46] Health checks are sent to this port with the specified source IP\[char46] For IPv6 square brackets must be used around IP address, e\[char46]g: \fB\fIport_name\fB:\fI[sourc_ip]\fB\fR
.IP
For example, in the example above, IP to port mappings might be defined as \fB10\[char46]0\[char46]0\[char46]4\fR=\fBsw0\-p1:10\[char46]0\[char46]0\[char46]2\fR and \fB20\[char46]0\[char46]0\[char46]4\fR=\fBsw1\-p1:20\[char46]0\[char46]0\[char46]2\fR, if the values given were suitable ports and IP addresses\[char46]
+.IP
+For IPv6 IP to port mappings might be defined as \fB[2001::1]\fR=\fBsw0\-p1:[2002::1]\fR\[char46]
.IP "\fBselection_fields\fR: set of strings, one of \fBeth_dst\fR, \fBeth_src\fR, \fBip_dst\fR, \fBip_src\fR, \fBtp_dst\fR, or \fBtp_src\fR"
OVN native load balancers are supported using the OpenFlow groups of type \fBselect\fR\[char46] OVS supports two selection methods: \fBdp_hash\fR and \fBhash (with optional fields
specified)\fR in selecting the buckets of a group\[char46] Please see the OVS documentation (man ovs-ofctl) for more details on the selection methods\[char46] Each endpoint IP (and port if set) is mapped to a bucket in the group flow\[char46]
@@ -1525,6 +1794,8 @@ where \fBBACKEND_VAR1\fR, \fBPORT_VAR1\fR, \fBBACKEND_VAR2\fR, \fBPORT_VAR2\fR,
Address family used by the load balancer\[char46] Supported values are \fBipv4\fR and \fBipv6\fR\[char46] The address-family is only used for load balancers with \fBoptions:template=true\fR\[char46] For explicit load balancers, setting the address-family has no effect\[char46]
.IP "\fBoptions : affinity_timeout\fR: optional string"
If the CMS provides a positive value (in seconds) for \fBaffinity_timeout\fR, OVN will dnat connections received from the same client to this lb to the same backend if received in the affinity timeslot\[char46] Max supported affinity_timeout is 65535 seconds\[char46]
+.IP "\fBoptions : ct_flush\fR: optional string, either \fBtrue\fR or \fBfalse\fR"
+The value indicates whether ovn-controller should flush CT entries that are related to this LB\[char46] The flush happens if the LB is removed, any of the backends is updated/removed or the LB is not considered local anymore by the ovn-controller\[char46] This option is set to \fBfalse\fR by default\[char46]
.bp
.SH "Load_Balancer_Group TABLE"
.PP
@@ -1548,7 +1819,7 @@ A set of load balancers\[char46]
.PP
.PP
.PP
-Each row represents one load balancer health check\[char46] Health checks are supported for IPv4 load balancers only\[char46]
+Each row represents one load balancer health check\[char46]
.SS "Summary:
.TQ 3.00in
\fBvip\fR
@@ -1614,7 +1885,10 @@ string, either \fBfrom\-lport\fR or \fBto\-lport\fR
string
.TQ 3.00in
\fBaction\fR
-string, one of \fBallow\-related\fR, \fBallow\-stateless\fR, \fBallow\fR, \fBdrop\fR, or \fBreject\fR
+string, one of \fBallow\-related\fR, \fBallow\-stateless\fR, \fBallow\fR, \fBdrop\fR, \fBpass\fR, or \fBreject\fR
+.TQ 3.00in
+\fBtier\fR
+integer, in range 0 to 3
.TQ .25in
\fIoptions:\fR
.RS .25in
@@ -1678,7 +1952,7 @@ The packets that the ACL should match, in the same expression language used for
By default all traffic is allowed\[char46] When writing a more restrictive policy, it is important to remember to allow flows such as ARP and IPv6 neighbor discovery packets\[char46]
.IP
Note that you can not create an ACL matching on a port with type=router or type=localnet\[char46]
-.IP "\fBaction\fR: string, one of \fBallow\-related\fR, \fBallow\-stateless\fR, \fBallow\fR, \fBdrop\fR, or \fBreject\fR"
+.IP "\fBaction\fR: string, one of \fBallow\-related\fR, \fBallow\-stateless\fR, \fBallow\fR, \fBdrop\fR, \fBpass\fR, or \fBreject\fR"
The action to take when the ACL rule matches:
.RS
.IP \(bu
@@ -1691,7 +1965,15 @@ The action to take when the ACL rule matches:
\fBdrop\fR: Silently drop the packet\[char46]
.IP \(bu
\fBreject\fR: Drop the packet, replying with a RST for TCP or ICMPv4/ICMPv6 unreachable message for other IPv4/IPv6-based protocols\[char46]
+.IP \(bu
+\fBpass\fR: Pass to the next ACL tier\[char46] If using multiple ACL tiers, a match on this ACL will stop evaluating ACLs at the current tier and move to the next one\[char46] If not using ACL tiers or if a \fBpass\fR ACL is matched at the final tier, then the \fBoptions:default_acl_drop\fR option from the \fBNB_Global\fR table is used to determine how to proceed\[char46]
.RE
+.IP "\fBtier\fR: integer, in range 0 to 3"
+The hierarchical tier that this ACL belongs to\[char46]
+.IP
+ACLs can be assigned to numerical tiers\[char46] When evaluating ACLs, an internal counter is used to determine which tier of ACLs should be evaluated\[char46] Tier 0 ACLs are evaluated first\[char46] If no verdict can be determined, then tier 1 ACLs are evaluated next\[char46] This continues until the maximum tier value is reached\[char46] If all tiers of ACLs are evaluated and no verdict is reached, then the \fBoptions:default_acl_drop\fR option from table \fBNB_Global\fR is used to determine how to proceed\[char46]
+.IP
+In this version of OVN, the maximum tier value for ACLs is 3, meaning there are 4 tiers of ACLs allowed (0\-3)\[char46]
.ST "options:"
.PP
.PP
@@ -1798,7 +2080,7 @@ optional string, containing an integer, in range 1 to 16,777,215
optional string, containing an integer, in range 0 to 65,535
.TQ 2.75in
\fBoptions : mac_binding_age_threshold\fR
-optional string, containing an integer, in range 0 to 4,294,967,295
+optional string
.RE
.TQ .25in
\fICommon Columns:\fR
@@ -1869,8 +2151,26 @@ It is \fBtrue\fR by default\[char46] It is recommended to set to \fBfalse\fR whe
Configures the datapath tunnel key for the logical router\[char46] This is not needed because \fBovn\-northd\fR will assign an unique key for each datapath by itself\[char46] However, if it is configured, \fBovn\-northd\fR honors the configured value\[char46]
.IP "\fBoptions : snat-ct-zone\fR: optional string, containing an integer, in range 0 to 65,535"
Use the requested conntrack zone for SNAT with this router\[char46] This can be useful if egress traffic from the host running OVN comes from both OVN and other sources\[char46] This way, OVN and the other sources can make use of the same conntrack zone\[char46]
-.IP "\fBoptions : mac_binding_age_threshold\fR: optional string, containing an integer, in range 0 to 4,294,967,295"
-MAC binding aging \fBthreshold\fR value in seconds\[char46] MAC binding exceeding this timeout will be automatically removed\[char46] The value defaults to 0, which means disabled\[char46]
+.IP "\fBoptions : mac_binding_age_threshold\fR: optional string"
+Specifies the MAC binding aging thresholds based on CIDRs, with the format: \fIentry\fR[\fB;\fR\fIentry\fR[\[char46]\[char46]\[char46]]], where each \fIentry\fR has the format: [\fIcidr\fR\fB:\fR]\fIthreshold\fR
+.RS
+.IP \(bu
+\fIcidr\fR: Can be either an IPv4 or IPv6 CIDR\[char46]
+.IP \(bu
+\fIthreshold\fR: Threshold value in seconds\[char46] MAC bindings with IP addresses matching the specified CIDR that exceed this timeout will be automatically removed\[char46]
+.RE
+.IP
+If an \fIentry\fR is provided without an CIDR (just the threshold value), it specifies the default threshold for MAC bindings that don\(cqt match any of the given CIDRs\[char46] If there are multiple default threshold entries in the option, the behavior is undefined\[char46]
+.IP
+If there are multiple CIDRs matching a MAC binding IP, the one with the longest prefix length takes effect\[char46] If there are multiple entries with the same CIDR in the option, the behavior is undefined\[char46]
+.IP
+If no matching CIDR is found for a MAC binding IP, and no default threshold is specified, the behavior defaults to the original: the binding will not be removed based on age\[char46]
+.IP
+The value can also default to an empty string, which means that the aging threshold is disabled\[char46] Any string not in the above format is regarded as invalid and the aging is disabled\[char46]
+.IP
+Example: \fB192\[char46]168\[char46]0\[char46]0/16:300;192\[char46]168\[char46]10\[char46]0/24:0;fe80::/10:600;1200\fR
+.IP
+This sets a threshold of 300 seconds for MAC bindings with IP addresses in the 192\[char46]168\[char46]0\[char46]0/16 range, excluding the 192\[char46]168\[char46]1\[char46]0/24 range (for which the aging is disabled), a threshold of 600 seconds for MAC bindings with IP addresses in the fe80::/10 IPv6 range, and a default threshold of 1200 seconds for all other MAC bindings\[char46]
.ST "Common Columns:"
.PP
.IP "\fBexternal_ids\fR: map of string-string pairs"
@@ -1893,7 +2193,7 @@ string, either \fBfrom\-lport\fR or \fBto\-lport\fR
string
.TQ 3.00in
\fBaction\fR
-map of string-integer pairs, key must be \fBdscp\fR, value in range 0 to 63
+map of string-integer pairs, key either \fBdscp\fR or \fBmark\fR, value in range 0 to 4,294,967,295
.TQ 3.00in
\fBbandwidth\fR
map of string-integer pairs, key either \fBburst\fR or \fBrate\fR, value in range 1 to 4,294,967,295
@@ -1907,11 +2207,13 @@ The QoS rule\(cqs priority\[char46] Rules with numerically higher priority take
The value of this field is similar to \fBACL\fR column in the OVN Northbound database\(cqs \fBACL\fR table\[char46]
.IP "\fBmatch\fR: string"
The packets that the QoS rules should match, in the same expression language used for the \fBmatch\fR column in the OVN Southbound database\(cqs \fBLogical_Flow\fR table\[char46] The \fBoutport\fR logical port is only available in the \fBto\-lport\fR direction (the \fBinport\fR is available in both directions)\[char46]
-.IP "\fBaction\fR: map of string-integer pairs, key must be \fBdscp\fR, value in range 0 to 63"
-When specified, matching flows will have DSCP marking applied\[char46]
+.IP "\fBaction\fR: map of string-integer pairs, key either \fBdscp\fR or \fBmark\fR, value in range 0 to 4,294,967,295"
+When \fBdscp\fR action is specified, matching flows will have have DSCP marking applied\[char46] When \fBmark\fR action is specified, matching flows will have packet marking applied\[char46]
.RS
.IP \(bu
\fBdscp\fR: The value of this action should be in the range of 0 to 63 (inclusive)\[char46]
+.IP \(bu
+\fBmark\fR: The value of this action should be a positive integer\[char46]
.RE
.IP "\fBbandwidth\fR: map of string-integer pairs, key either \fBburst\fR or \fBrate\fR, value in range 1 to 4,294,967,295"
When specified, matching packets will have bandwidth metering applied\[char46] Traffic over the limit will be dropped\[char46]
@@ -1935,13 +2237,13 @@ Each row in this table represents a mirror that can be used for port mirroring\[
string (must be unique within table)
.TQ 3.00in
\fBfilter\fR
-string, either \fBfrom\-lport\fR or \fBto\-lport\fR
+string, one of \fBboth\fR, \fBfrom\-lport\fR, or \fBto\-lport\fR
.TQ 3.00in
\fBsink\fR
string
.TQ 3.00in
\fBtype\fR
-string, either \fBerspan\fR or \fBgre\fR
+string, one of \fBerspan\fR, \fBgre\fR, or \fBlocal\fR
.TQ 3.00in
\fBindex\fR
integer
@@ -1951,14 +2253,14 @@ map of string-string pairs
.SS "Details:
.IP "\fBname\fR: string (must be unique within table)"
Represents the name of the mirror\[char46]
-.IP "\fBfilter\fR: string, either \fBfrom\-lport\fR or \fBto\-lport\fR"
-The value of this field represents selection criteria of the mirror\[char46] \fBto\-lport\fR mirrors the packets coming into logical port\[char46] \fBfrom\-lport\fR mirrors the packets going out of logical port\[char46]
+.IP "\fBfilter\fR: string, one of \fBboth\fR, \fBfrom\-lport\fR, or \fBto\-lport\fR"
+The value of this field represents selection criteria of the mirror\[char46] \fBto\-lport\fR mirrors the packets coming into logical port\[char46] \fBfrom\-lport\fR mirrors the packets going out of logical port\[char46] \fBboth\fR mirrors for both directions\[char46]
.IP "\fBsink\fR: string"
-The value of this field represents the destination/sink of the mirror\[char46] The value it takes is an IP address of the sink port\[char46]
-.IP "\fBtype\fR: string, either \fBerspan\fR or \fBgre\fR"
-The value of this field represents the type of the tunnel used for sending the mirrored packets\[char46]
+The value of this field represents the destination/sink of the mirror\[char46] If the \fItype\fR is \fBgre\fR or \fBerspan\fR, the value indicates the tunnel remote IP (either IPv4 or IPv6)\[char46] For a \fItype\fR of \fBlocal\fR, this field defines a local interface on the OVS integration bridge to be used as the mirror destination\[char46] The interface must possess external-ids:mirror-id that matches this string\[char46]
+.IP "\fBtype\fR: string, one of \fBerspan\fR, \fBgre\fR, or \fBlocal\fR"
+The value of this field specifies the mirror type - \fBgre\fR, \fBerspan\fR or \fBlocal\fR\[char46]
.IP "\fBindex\fR: integer"
-The value of this field represents the tunnel ID\[char46] If the configured tunnel type is \fBgre\fR, this field represents the \fBGRE\fR key value and if the configured tunnel type is \fBerspan\fR it represents the \fBerspan_idx\fR value\[char46]
+The value of this field represents the tunnel ID\[char46] If the configured tunnel type is \fBgre\fR, this field represents the \fBGRE\fR key value and if the configured tunnel type is \fBerspan\fR it represents the \fBerspan_idx\fR value\[char46] It is ignored if the type is \fBlocal\fR\[char46]
.IP "\fBexternal_ids\fR: map of string-string pairs"
See \fBExternal IDs\fR at the beginning of this document\[char46]
.bp
@@ -2139,6 +2441,13 @@ optional string
\fBexternal_ids\fR
map of string-string pairs
.RE
+.TQ .25in
+\fIStatus:\fR
+.RS .25in
+.TQ 2.75in
+\fBstatus : hosting-chassis\fR
+optional string
+.RE
.SS "Details:
.IP "\fBname\fR: string (must be unique within table)"
A name for the logical router port\[char46]
@@ -2304,6 +2613,15 @@ For a router port attached to a logical switch, this column is empty\[char46]
See \fBExternal IDs\fR at the beginning of this document\[char46]
.IP
The \fBovn\-northd\fR program copies all these pairs into the \fBexternal_ids\fR column of the \fBPort_Binding\fR table in \fBOVN_Southbound\fR database\[char46]
+.ST "Status:"
+.PP
+.PP
+.PP
+Additional status about the logical router port\[char46]
+.IP "\fBstatus : hosting-chassis\fR: optional string"
+This option is populated by \fBovn\-northd\fR\[char46]
+.IP
+When a distributed gateway port is bound to a location in the OVN Southbound database \fBPort_Binding\fR \fBovn\-northd\fR will populate this key with the name of the Chassis that is currently hosting this port\[char46]
.bp
.SH "Logical_Router_Static_Route TABLE"
.PP
@@ -2428,6 +2746,9 @@ optional string
\fBnexthops\fR
set of strings
.TQ 3.00in
+\fBbfd_sessions\fR
+set of weak reference to \fBBFD\fRs
+.TQ 3.00in
\fBoptions : pkt_mark\fR
optional string
.TQ .25in
@@ -2462,6 +2783,8 @@ Next-hop IP address for this route, which should be the IP address of a connecte
Next-hop ECMP IP addresses for this route\[char46] Each IP in the list should be the IP address of a connected router port or the IP address of a logical port\[char46]
.IP
One IP from the list is selected as next hop\[char46]
+.IP "\fBbfd_sessions\fR: set of weak reference to \fBBFD\fRs"
+Reference to \fBBFD\fR row if the route policy has associated some BFD sessions\[char46]
.IP "\fBoptions : pkt_mark\fR: optional string"
Marks the packet with the value specified when the router policy is applied\[char46] CMS can inspect this packet marker and take some decisions if desired\[char46] This value is not preserved when the packet goes out on the wire\[char46]
.ST "Common Columns:"
@@ -2759,6 +3082,9 @@ optional string
.TQ 2.50in
\fBoptions : dhcpv6_stateless\fR
optional string
+.TQ 2.50in
+\fBoptions : fqdn\fR
+optional string
.RE
.RE
.TQ .25in
@@ -2925,6 +3251,8 @@ The DHCPv6 option code for this option is 24\[char46] This option specifies the
Example: \fB\(dqovn\[char46]org\(dq\fR\[char46]
.IP "\fBoptions : dhcpv6_stateless\fR: optional string"
This option specifies the OVN native DHCPv6 will work in stateless mode, which means OVN native DHCPv6 will not offer IPv6 addresses for VM/VIF ports, but only reply other configurations, such as DNS and domain search list\[char46] When setting this option with string value \(dqtrue\(dq, VM/VIF will configure IPv6 addresses by stateless way\[char46] Default value for this option is false\[char46]
+.IP "\fBoptions : fqdn\fR: optional string"
+The DHCPv6 option code for this option is 39\[char46] If set, indicates the DHCPv6 option \(dqFQDN\(dq\[char46]
.ST "Common Columns:"
.PP
.IP "\fBexternal_ids\fR: map of string-string pairs"
@@ -3111,6 +3439,9 @@ Each row in this table stores the DNS records\[char46] The \fBLogical_Switch\fR
\fBrecords\fR
map of string-string pairs
.TQ 3.00in
+\fBoptions : ovn-owned\fR
+optional string
+.TQ 3.00in
\fBexternal_ids\fR
map of string-string pairs
.SS "Details:
@@ -3120,6 +3451,10 @@ Key-value pair of DNS records with \fBDNS query name\fR as the key and value as
\fBExample: \fR \(dqvm1\[char46]ovn\[char46]org\(dq = \(dq10\[char46]0\[char46]0\[char46]4 aef0::4\(dq
.IP
\fBExample: \fR \(dq4\[char46]0\[char46]0\[char46]10\[char46]in-addr\[char46]arpa\(dq = \(dqvm1\[char46]ovn\[char46]org\(dq
+.IP "\fBoptions : ovn-owned\fR: optional string"
+If set to true, then the OVN will be the main responsible for \fBDNS Records\fR within this row\[char46]
+.IP
+A \fBDNS\fR row with this option set to \fBtrue\fR can be created for domains that the user needs to configure locally and don\(cqt care about IPv6 only interested in IPv4 or vice versa\[char46] This will let ovn send IPv4 DNS reply and reject/ignore IPv6 queries to save the waiting for a timeout on those uninteresting queries\[char46]
.IP "\fBexternal_ids\fR: map of string-string pairs"
See \fBExternal IDs\fR at the beginning of this document\[char46]
.bp
diff --git a/src/static/support/dist-docs/ovn-nb.5.html b/src/static/support/dist-docs/ovn-nb.5.html
index 505cdb99..681f5924 100644
--- a/src/static/support/dist-docs/ovn-nb.5.html
+++ b/src/static/support/dist-docs/ovn-nb.5.html
@@ -1,34 +1,32 @@
-ovn-nb(5) Open vSwitch Manual ovn-nb(5)
-
-
+ovn-nb(5) Open vSwitch Manual ovn-nb(5)
NAME
ovn-nb - OVN_Northbound database schema
This database is the interface between OVN and the cloud management
- system (CMS), such as OpenStack, running above it. The CMS produces
- almost all of the contents of the database. The ovn-northd program mon‐
- itors the database contents, transforms it, and stores it into the
+ system (CMS), such as OpenStack, running above it. The CMS produces al‐
+ most all of the contents of the database. The ovn-northd program moni‐
+ tors the database contents, transforms it, and stores it into the
OVN_Southbound database.
- We generally speak of ``the’’ CMS, but one can imagine scenarios in
+ We generally speak of ``the’’ CMS, but one can imagine scenarios in
which multiple CMSes manage different parts of an OVN deployment.
External IDs
- Each of the tables in this database contains a special column, named
- external_ids. This column has the same form and purpose each place it
+ 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 data‐
+ 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 data‐
base.
TABLE SUMMARY
- The following list summarizes the purpose of each of the tables in the
- OVN_Northbound database. Each table is described in more detail on a
+ The following list summarizes the purpose of each of the tables in the
+ OVN_Northbound database. Each table is described in more detail on a
later page.
Table Purpose
@@ -84,8 +82,8 @@
Chassis_Template_Var configuration.
NB_Global TABLE
- Northbound configuration for an OVN system. This table must have
- exactly one row.
+ Northbound configuration for an OVN system. This table must have ex‐
+ actly one row.
Summary:
Identity:
@@ -107,13 +105,24 @@
optional string
options : bfd-min-tx optional string
options : bfd-mult optional string
+ options : ignore_chassis_features
+ optional string
options : mac_prefix optional string
options : mac_binding_removal_limit
+ optional string, containing an integer,
+ in range 0 to 4,294,967,295
+ options : fdb_removal_limit
optional string, containing an integer,
in range 0 to 4,294,967,295
options : controller_event optional string, either true or false
options : northd_probe_interval
optional string
+ options : ic_probe_interval
+ optional string
+ options : nbctl_probe_interval
+ optional string
+ options : northd_trim_timeout
+ optional string
options : use_logical_dp_groups
optional string
options : use_parallel_build
@@ -125,6 +134,9 @@
optional string
options : debug_drop_collector_set
optional string
+ options : use_common_zone optional string, either true or false
+ options : northd-backoff-interval-ms
+ optional string
Options for configuring interconnection route advertisement:
options : ic-route-adv optional string
options : ic-route-learn optional string
@@ -167,16 +179,16 @@
To print the timestamp as a human-readable date:
- date -d "@$(ovn-nbctl get NB_Global . nb_cfg_timestamp | sed ’s/...$//’)"
+ date -d "@$(ovn-nbctl get NB_Global . nb_cfg_timestamp | sed ’’s/...$//’’)"
sb_cfg: integer
- Sequence number that ovn-northd sets to the value of nb_cfg
- after it finishes applying the corresponding configuration
- changes to the OVN_Southbound database.
+ Sequence number that ovn-northd sets to the value of nb_cfg af‐
+ ter it finishes applying the corresponding configuration changes
+ to the OVN_Southbound database.
sb_cfg_timestamp: integer
- The timestamp, in milliseconds since the epoch, when ovn-northd
+ The timestamp, in milliseconds since the epoch, when ovn-northd
finishes applying the corresponding configuration changes to the
OVN_Southbound database successfully.
@@ -189,10 +201,10 @@
This value can regress, if a chassis was removed from the system
and rejoins before catching up.
- If there are no chassis, then ovn-northd copies nb_cfg to
- hv_cfg. Thus, in this case, the (nonexistent) hypervisors are
- always considered to be caught up. This means that hypervisors
- can be "caught up" even in cases where sb_cfg would show that
+ If there are no chassis, then ovn-northd copies nb_cfg to
+ hv_cfg. Thus, in this case, the (nonexistent) hypervisors are
+ always considered to be caught up. This means that hypervisors
+ can be "caught up" even in cases where sb_cfg would show that
the southbound database is not. To detect when both the hypervi‐
sors and the southbound database are caught up, a client should
take the smaller of sb_cfg and hv_cfg.
@@ -224,46 +236,71 @@
mentation and not to OVN BFD one.
options : bfd-min-rx: optional string
- BFD option min-rx value to use when configuring BFD on tunnel
+ BFD option min-rx value to use when configuring BFD on tunnel
interfaces.
options : bfd-decay-min-rx: optional string
- BFD option decay-min-rx value to use when configuring BFD on
+ BFD option decay-min-rx value to use when configuring BFD on
tunnel interfaces.
options : bfd-min-tx: optional string
- BFD option min-tx value to use when configuring BFD on tunnel
+ BFD option min-tx value to use when configuring BFD on tunnel
interfaces.
options : bfd-mult: optional string
- BFD option mult value to use when configuring BFD on tunnel
- interfaces.
+ BFD option mult value to use when configuring BFD on tunnel in‐
+ terfaces.
+
+ options : ignore_chassis_features: optional string
+ When set to false, the ovn-northd will evaluate the features
+ supported by each chassis and will only activate features that
+ are universally supported by all chassis. This approach is cru‐
+ cial for maintaining backward compatibility during an upgrade
+ when the ovn-northd is updated prior to the ovn-controller. How‐
+ ever, if any chassis is poorly managed and the upgrade is unsuc‐
+ cessful, it will restrict ovn-northd from activating the new
+ features.
+
+ Alternatively, setting this option to true instructs ovn-northd
+ to bypass the support status of features on each chassis and to
+ directly implement the latest features. This approach safeguards
+ the operation of ovn-northd from being adversely affected by a
+ mismatched configuration of a chassis.
+
+ The default setting for this option is false.
options : mac_prefix: optional string
- Configure a given OUI to be used as prefix when L2 address is
+ Configure a given OUI to be used as prefix when L2 address is
dynamically assigned, e.g. 00:11:22
- options : mac_binding_removal_limit: optional string, containing an
- integer, in range 0 to 4,294,967,295
+ options : mac_binding_removal_limit: optional string, containing an in‐
+ teger, in range 0 to 4,294,967,295
MAC binding aging bulk removal limit. This limits how many rows
can expire in a single transaction. Default value is 0 which is
unlimited. When we hit the limit next batch removal is delayed
by 5 s.
+ options : fdb_removal_limit: optional string, containing an integer, in
+ range 0 to 4,294,967,295
+ FDB aging bulk removal limit. This limits how many rows can ex‐
+ pire in a single transaction. Default value is 0 which is unlim‐
+ ited. When we hit the limit next batch removal is delayed by 5
+ s.
+
options : controller_event: optional string, either true or false
- Value set by the CMS to enable/disable ovn-controller event
- reporting. Traffic into OVS can raise a ’controller’ event that
- results in a Controller_Event being written to the Con‐
+ Value set by the CMS to enable/disable ovn-controller event re‐
+ porting. Traffic into OVS can raise a ’controller’ event that
+ results in a Controller_Event being written to the Con‐‐
troller_Event table in SBDB. When the CMS has seen the event and
taken appropriate action, it can remove the corresponding row in
Controller_Event table. The intention is for a CMS to see the
- events and take some sort of action. Please see the Con‐
+ events and take some sort of action. Please see the Con‐‐
troller_Event table in SBDB. It is possible to associate a meter
to each controller event type in order to not overload the pinc‐
trl thread under heavy load. Each event type relies on a meter
with a defined name:
- · empty_lb_backends: event-elb
+ • empty_lb_backends: event-elb
options : northd_probe_interval: optional string
The inactivity probe interval of the connection to the OVN
@@ -274,13 +311,39 @@
If the value is nonzero, then it will be forced to a value of at
least 1000 ms.
+ options : ic_probe_interval: optional string
+ The inactivity probe interval of the connection to the OVN
+ Northbound and Southbound databases from ovn-ic, in millisec‐
+ onds. 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.
+
+ options : nbctl_probe_interval: optional string
+ The inactivity probe interval of the connection to the OVN
+ Northbound database from ovn-nbctl utility, in milliseconds. If
+ the value is zero, it disables the connection keepalive feature.
+
+ If the value is nonzero, then it will be forced to a value of at
+ least 1000 ms.
+
+ If the value is less than zero, then the default inactivity
+ probe interval for ovn-nbctl would be left intact (120000 ms).
+
+ options : northd_trim_timeout: optional string
+ When used, this configuration value specifies the time, in mil‐
+ liseconds, since the last ovn-northd active operation after
+ which memory trimming is performed. By default this is set to
+ 30000 (30 seconds).
+
options : use_logical_dp_groups: optional string
- Note: This option is deprecated, the only behavior is to always
- combine logical flows by datapath groups. Changing the value or
+ Note: This option is deprecated, the only behavior is to always
+ combine logical flows by datapath groups. Changing the value or
removing this option all toghether will have no effect.
- ovn-northd combines logical flows that differs only by logical
- datapath into a single logical flow with logical datapath group
+ ovn-northd combines logical flows that differs only by logical
+ datapath into a single logical flow with logical datapath group
attached.
options : use_parallel_build: optional string
@@ -293,13 +356,13 @@
The default value is false.
options : ignore_lsp_down: optional string
- If set to false, ARP/ND reply flows for logical switch ports
- will be installed only if the port is up, i.e. claimed by a
+ If set to false, ARP/ND reply flows for logical switch ports
+ will be installed only if the port is up, i.e. claimed by a
Chassis. If set to true, these flows are installed regardless of
the status of the port, which can result in a situation that ARP
- request to an IP is resolved even before the relevant VM/con‐
- tainer is running. For environments where this is not an issue,
- setting it to true can reduce the load and latency of the con‐
+ request to an IP is resolved even before the relevant VM/con‐
+ tainer is running. For environments where this is not an issue,
+ setting it to true can reduce the load and latency of the con‐
trol plane. The default value is true.
options : use_ct_inv_match: optional string
@@ -309,21 +372,21 @@
offloading ct_state inv flag, then the datapath flows matching
on this flag (either +inv or -inv) will not be offloaded. CMS
should consider setting use_ct_inv_match to false in such cases.
- This results in a side effect of the invalid packets getting
- delivered to the destination VIF, which otherwise would have
- been dropped by OVN.
+ This results in a side effect of the invalid packets getting de‐
+ livered to the destination VIF, which otherwise would have been
+ dropped by OVN.
options : default_acl_drop: optional string
If set to true., ovn-northd will generate a logical flow to drop
- all traffic in the ACL stages. By default this option is set to
+ all traffic in the ACL stages. By default this option is set to
false.
options : debug_drop_domain_id: optional string
If set to a 8-bit number and if debug_drop_collector_set is also
configured, ovn-northd will add a sample action to every logical
- flow that contains a ’drop’ action. The 8 most significant bits
- of the observation_domain_id field will be those specified in
- the debug_drop_domain_id. The 24 least significant bits of the
+ flow that contains a ’drop’ action. The 8 most significant bits
+ of the observation_domain_id field will be those specified in
+ the debug_drop_domain_id. The 24 least significant bits of the
observation_domain_id field will be the datapath’s key.
The observation_point_id will be set to the first 32 bits of the
@@ -331,16 +394,32 @@
options : debug_drop_collector_set: optional string
If set to a 32-bit number ovn-northd will add a sample action to
- every logical flow that contains a ’drop’ action. The sample
- action will have the specified collector_set_id. The value must
+ every logical flow that contains a ’drop’ action. The sample ac‐
+ tion will have the specified collector_set_id. The value must
match that of the local OVS configuration as described in
ovs-actions(7).
+ options : use_common_zone: optional string, either true or false
+ Default value is false. If set to true the SNAT and DNAT happens
+ in common zone, instead of happening in separate zones, depend‐
+ ing on the configuration. However, this option breaks traffic
+ when there is configuration of DGP + LB + SNAT on this LR. The
+ value true should be used only in case of HWOL compatibility
+ with GDP.
+
+ options : northd-backoff-interval-ms: optional string
+ Maximum interval that the northd incremental engine is delayed
+ by in milliseconds. Setting the value to nonzero delays the next
+ northd engine run by the previous run time, capped by the speci‐
+ fied value. If the value is zero the engine won’t be delayed at
+ all. The recommended period is smaller than 500 ms, beyond that
+ the latency of SB changes would be very noticeable.
+
Options for configuring interconnection route advertisement:
These options control how routes are advertised between OVN deployments
for interconnection. If enabled, ovn-ic from different OVN deployments
- exchanges routes between each other through the global OVN_IC_South‐
+ exchanges routes between each other through the global OVN_IC_South‐‐
bound database. Only routers with ports connected to interconnection
transit switches participate in route advertisement. For each of these
routers, there are two types of routes to be advertised:
@@ -348,13 +427,13 @@
Firstly, the static routes configured in the router are advertised.
Secondly, the networks configured in the logical router ports that are
- not on the transit switches are advertised. These are considered as
- directly connected subnets on the router.
+ not on the transit switches are advertised. These are considered as di‐
+ rectly connected subnets on the router.
- Link local prefixes (IPv4 169.254.0.0/16 and IPv6 FE80::/10) are never
+ Link local prefixes (IPv4 169.254.0.0/16 and IPv6 FE80::/10) are never
advertised.
- The learned routes are added to the static_routes column of the Logi‐
+ The learned routes are added to the static_routes column of the Logi‐‐
cal_Router table, with external_ids:ic-learned-route set to the uuid of
the row in Route table of the OVN_IC_Southbound database.
@@ -372,7 +451,7 @@
takes effect only when option ic-route-adv is true.
options : ic-route-learn-default: optional string
- A boolean value that enables learning default route from the
+ A boolean value that enables learning default route from the
global OVN_IC_Southbound database. Default is false. This option
takes effect only when option ic-route-learn is true.
@@ -386,7 +465,7 @@
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 Connec‐
+ for how these connections should be configured. See the Connec‐‐
tion table for more information.
ssl: optional SSL
@@ -426,6 +505,7 @@
meters : tcp-reset optional string
meters : bfd optional string
meters : reject optional string
+ meters : svc-monitor optional string
external_ids map of string-string pairs
Details:
@@ -441,37 +521,37 @@
hop (through ARP).
meters : dhcpv4-opts: optional string
- Rate limiting meter for packets that require adding DHCPv4
- options.
+ Rate limiting meter for packets that require adding DHCPv4 op‐
+ tions.
meters : dhcpv6-opts: optional string
- Rate limiting meter for packets that require adding DHCPv6
- options.
+ Rate limiting meter for packets that require adding DHCPv6 op‐
+ tions.
meters : dns: optional string
- Rate limiting meter for DNS query packets that need to be
+ Rate limiting meter for DNS query packets that need to be
replied to.
meters : event-elb: optional string
Rate limiting meter for empty load balancer events.
meters : icmp4-error: optional string
- Rate limiting meter for packets that require replying with an
+ Rate limiting meter for packets that require replying with an
ICMP error.
meters : icmp6-error: optional string
- Rate limiting meter for packets that require replying with an
+ Rate limiting meter for packets that require replying with an
ICMPv6 error.
meters : igmp: optional string
Rate limiting meter for IGMP packets.
meters : nd-na: optional string
- Rate limiting meter for ND neighbor advertisement packets used
+ Rate limiting meter for ND neighbor advertisement packets used
for learning neighbors.
meters : nd-ns: optional string
- Rate limiting meter for ND neighbor solicitation packets used
+ Rate limiting meter for ND neighbor solicitation packets used
for learning neighbors.
meters : nd-ns-resolve: optional string
@@ -492,23 +572,27 @@
meters : reject: optional string
Rate limiting meter for packets that trigger a reject action
+ meters : svc-monitor: optional string
+ Rate limiting meter for packets that are arriving to service
+ monitor MAC address.
+
external_ids: map of string-string pairs
See External IDs at the beginning of this document.
Logical_Switch TABLE
Each row represents one L2 logical switch.
- There are two kinds of logical switches, that is, ones that fully vir‐
- tualize the network (overlay logical switches) and ones that provide
- simple connectivity to physical networks (bridged logical switches).
- They work in the same way when providing connectivity between logical
- ports on same chassis, but differently when connecting remote logical
- ports. Overlay logical switches connect remote logical ports by tun‐
- nels, while bridged logical switches provide connectivity to remote
- ports by bridging the packets to directly connected physical L2 seg‐
- ments with the help of localnet ports. Each bridged logical switch has
- one or more localnet ports, which have only one special address
- unknown.
+ There are two kinds of logical switches, that is, ones that fully vir‐
+ tualize the network (overlay logical switches) and ones that provide
+ simple connectivity to physical networks (bridged logical switches).
+ They work in the same way when providing connectivity between logical
+ ports on same chassis, but differently when connecting remote logical
+ ports. Overlay logical switches connect remote logical ports by tun‐
+ nels, while bridged logical switches provide connectivity to remote
+ ports by bridging the packets to directly connected physical L2 seg‐
+ ments with the help of localnet ports. Each bridged logical switch has
+ one or more localnet ports, which have only one special address un‐‐
+ known.
Summary:
ports set of Logical_Switch_Ports
@@ -527,6 +611,9 @@
other_config : exclude_ips optional string
other_config : ipv6_prefix optional string
other_config : mac_only optional string, either true or false
+ other_config : fdb_age_threshold
+ optional string, containing an integer,
+ in range 0 to 4,294,967,295
IP Multicast Snooping Options:
other_config : mcast_snoop optional string, either true or false
other_config : mcast_querier
@@ -562,6 +649,8 @@
Other options:
other_config : vlan-passthru
optional string, either true or false
+ other_config : broadcast-arps-to-all-routers
+ optional string, either true or false
Common Columns:
external_ids map of string-string pairs
@@ -579,16 +668,16 @@
Set of load balancers groups associated to this logical switch.
acls: set of ACLs
- Access control rules that apply to packets within the logical
+ Access control rules that apply to packets within the logical
switch.
qos_rules: set of QoSes
- QoS marking and metering rules that apply to packets within the
+ QoS marking and metering rules that apply to packets within the
logical switch.
dns_records: set of weak reference to DNSes
- This column defines the DNS records to be used for resolving
- internal DNS queries within the logical switch by the native DNS
+ This column defines the DNS records to be used for resolving in‐
+ ternal DNS queries within the logical switch by the native DNS
resolver. Please see the DNS table.
forwarding_groups: set of Forwarding_Groups
@@ -604,9 +693,9 @@
logical switch, use its row UUID.)
(Originally, name was intended to serve the purpose of a human-friendly
- name, but the Neutron integration used it to uniquely identify its own
- switch object, in the format neutron-uuid. Later on, Neutron started
- propagating the friendly name of a switch as external_ids:neutron:net‐
+ name, but the Neutron integration used it to uniquely identify its own
+ switch object, in the format neutron-uuid. Later on, Neutron started
+ propagating the friendly name of a switch as external_ids:neutron:net‐‐
work_name. Perhaps this can be cleaned up someday.)
name: string
@@ -617,19 +706,19 @@
IP Address Assignment:
- These options control automatic IP address management (IPAM) for ports
- attached to the logical switch. To enable IPAM for IPv4, set other_con‐
+ These options control automatic IP address management (IPAM) for ports
+ attached to the logical switch. To enable IPAM for IPv4, set other_con‐‐
fig:subnet and optionally other_config:exclude_ips. To enable IPAM for
- IPv6, set other_config:ipv6_prefix. IPv4 and IPv6 may be enabled
- together or separately.
+ IPv6, set other_config:ipv6_prefix. IPv4 and IPv6 may be enabled to‐
+ gether or separately.
To request dynamic address assignment for a particular port, use the
- dynamic keyword in the addresses column of the port’s Logi‐
+ dynamic keyword in the addresses column of the port’s Logi‐‐
cal_Switch_Port row. This requests both an IPv4 and an IPv6 address, if
IPAM for IPv4 and IPv6 are both enabled.
other_config : subnet: optional string
- Set this to an IPv4 subnet, e.g. 192.168.0.0/24, to enable
+ Set this to an IPv4 subnet, e.g. 192.168.0.0/24, to enable
ovn-northd to automatically assign IP addresses within that sub‐
net.
@@ -645,55 +734,64 @@
Examples:
- · 192.168.0.2 192.168.0.10
+ • 192.168.0.2 192.168.0.10
- · 192.168.0.4 192.168.0.30..192.168.0.60
+ • 192.168.0.4 192.168.0.30..192.168.0.60
192.168.0.110..192.168.0.120
- · 192.168.0.110..192.168.0.120 192.168.0.25..192.168.0.30
+ • 192.168.0.110..192.168.0.120 192.168.0.25..192.168.0.30
192.168.0.144
other_config : ipv6_prefix: optional string
Set this to an IPv6 prefix to enable ovn-northd to automatically
- assign IPv6 addresses using this prefix. The assigned IPv6
- address will be generated using the IPv6 prefix and the MAC
- address (converted to an IEEE EUI64 identifier) of the port. The
- IPv6 prefix defined here should be a valid IPv6 address ending
+ assign IPv6 addresses using this prefix. The assigned IPv6 ad‐
+ dress will be generated using the IPv6 prefix and the MAC ad‐
+ dress (converted to an IEEE EUI64 identifier) of the port. The
+ IPv6 prefix defined here should be a valid IPv6 address ending
with ::.
Examples:
- · aef0::
+ • aef0::
- · bef0:1234:a890:5678::
+ • bef0:1234:a890:5678::
- · 8230:5678::
+ • 8230:5678::
other_config : mac_only: optional string, either true or false
- Value used to request to assign L2 address only if neither sub‐
+ Value used to request to assign L2 address only if neither sub‐
net nor ipv6_prefix are specified
+ other_config : fdb_age_threshold: optional string, containing an inte‐
+ ger, in range 0 to 4,294,967,295
+ FDB aging threshold value in seconds. FDB exceeding this timeout
+ will be automatically removed. The value defaults to 0, which
+ means disabled.
+
IP Multicast Snooping Options:
These options control IP Multicast Snooping configuration of the logi‐
- cal switch. To enable IP Multicast Snooping set other_con‐
- fig:mcast_snoop to true. To enable IP Multicast Querier set other_con‐
- fig:mcast_snoop to true. If IP Multicast Querier is enabled other_con‐
- fig:mcast_eth_src and other_config:mcast_ip4_src must be set.
+ cal switch. To enable IP Multicast Snooping set other_con‐‐
+ fig:mcast_snoop to true. To enable IP Multicast Querier set other_con‐‐
+ fig:mcast_querier to true. If IP Multicast Querier is enabled
+ other_config:mcast_eth_src and other_config:mcast_ip4_src must be set.
other_config : mcast_snoop: optional string, either true or false
- Enables/disables IP Multicast Snooping on the logical switch.
+ Enables/disables IP Multicast Snooping on the logical switch.
+ Default: false.
other_config : mcast_querier: optional string, either true or false
- Enables/disables IP Multicast Querier on the logical switch.
+ Enables/disables IP Multicast Querier on the logical switch.
+ Only applicable if other_config:mcast_snoop is enabled. Default:
+ true.
- other_config : mcast_flood_unregistered: optional string, either true
+ other_config : mcast_flood_unregistered: optional string, either true
or false
- Determines whether unregistered multicast traffic should be
- flooded or not. Only applicable if other_config:mcast_snoop is
+ Determines whether unregistered multicast traffic should be
+ flooded or not. Only applicable if other_config:mcast_snoop is
enabled. Default: false.
- other_config : mcast_table_size: optional string, containing an inte‐
+ other_config : mcast_table_size: optional string, containing an inte‐
ger, in range 1 to 32,766
Number of multicast groups to be stored. Default: 2048.
@@ -702,15 +800,15 @@
Configures the IP Multicast Snooping group idle timeout (in sec‐
onds). Default: 300 seconds.
- other_config : mcast_query_interval: optional string, containing an
- integer, in range 1 to 3,600
+ other_config : mcast_query_interval: optional string, containing an in‐
+ teger, in range 1 to 3,600
Configures the IP Multicast Querier interval between queries (in
seconds). Default: other_config:mcast_idle_timeout / 2.
other_config : mcast_query_max_response: optional string, containing an
integer, in range 1 to 10
- Configures the value of the "max-response" field in the multi‐
- cast queries originated by the logical switch. Default: 1 sec‐
+ Configures the value of the "max-response" field in the multi‐
+ cast queries originated by the logical switch. Default: 1 sec‐
ond.
other_config : mcast_eth_src: optional string
@@ -734,9 +832,9 @@
Tunnel Key:
- other_config : requested-tnl-key: optional string, containing an inte‐
+ other_config : requested-tnl-key: optional string, containing an inte‐
ger, in range 1 to 16,777,215
- Configures the datapath tunnel key for the logical switch. Usu‐
+ Configures the datapath tunnel key for the logical switch. Usu‐
ally this is not needed because ovn-northd will assign an unique
key for each datapath by itself. However, if it is configured,
ovn-northd honors the configured value. The typical use case is
@@ -746,20 +844,31 @@
from OVN_IC_Southbound through this config.
copp: optional weak reference to Copp
- The control plane protection policy from table Copp used for
- metering packets sent to ovn-controller from ports of this logi‐
- cal switch.
+ The control plane protection policy from table Copp used for me‐
+ tering packets sent to ovn-controller from ports of this logical
+ switch.
Other options:
other_config : vlan-passthru: optional string, either true or false
- Determines whether VLAN tagged incoming traffic should be
- allowed. Note that this may have security implications when
- enabled for a logical switch with a tag=0 localnet port. If not
+ Determines whether VLAN tagged incoming traffic should be al‐
+ lowed. Note that this may have security implications when en‐
+ abled for a logical switch with a tag=0 localnet port. If not
properly isolated from other localnet ports, fabric traffic that
- belongs to other tagged networks may be passed through such a
+ belongs to other tagged networks may be passed through such a
port.
+ other_config : broadcast-arps-to-all-routers: optional string, either
+ true or false
+ Determines whether arp requests and ipv6 neighbor solicitations
+ should be sent to all routers and other switchports (default) or
+ if it should only be sent to switchports where the ip/mac ad‐
+ dress is unknown. Setting this to false can significantly reduce
+ the load if the logical switch can receive arp requests for ips
+ it does not know about. However setting this to false also means
+ that garps are no longer forwarded to all routers and therefor
+ the mac bindings of the routers are no longer updated.
+
Common Columns:
external_ids: map of string-string pairs
@@ -780,6 +889,8 @@
options : exclude-lb-vips-from-garp
optional string
options : arp_proxy optional string
+ options : enable_router_port_acl
+ optional string, either true or false
Options for localnet ports:
options : network_name optional string
options : ethtype optional string
@@ -838,7 +949,7 @@
optional string
Tunnel Key:
options : requested-tnl-key
- optional string, containing an integer,
+ optional string, containing an integer,
in range 1 to 32,767
Common Columns:
external_ids map of string-string pairs
@@ -849,8 +960,8 @@
name: string (must be unique within table)
The logical port name.
- For entities (VMs or containers) that are spawned in the hyper‐
- visor, the name used here must match those used in the exter‐
+ For entities (VMs or containers) that are spawned in the hyper‐
+ visor, the name used here must match those used in the exter‐‐
nal_ids:iface-id in the Open_vSwitch database’s Interface table,
because hypervisors use external_ids:iface-id as a lookup key to
identify the network interface of that entity.
@@ -869,15 +980,15 @@
(empty string)
A VM (or VIF) interface.
- router A connection to a logical router. The value of
- options:router-port specifies the name of the Logi‐
+ router A connection to a logical router. The value of op‐‐
+ tions:router-port specifies the name of the Logi‐‐
cal_Router_Port to which this logical switch port is con‐
nected.
localnet
A connection to a locally accessible network from
ovn-controller instances that have a corresponding bridge
- mapping. A logical switch can have multiple localnet
+ mapping. A logical switch can have multiple localnet
ports attached. This type is used to model direct connec‐
tivity to existing networks. In this case, each chassis
should have a mapping for one of the physical networks
@@ -906,29 +1017,29 @@
DHCPv4/DHCPv6/DNS for this port. If ha_chassis_group is
defined, ovn-controller running in the master chassis of
the HA chassis group will bind this port to provide these
- native services. It is expected that this port belong to
+ native services. It is expected that this port belong to
a bridged logical switch (with a localnet port).
- It is recommended to use the same HA chassis group for
- all the external ports of a logical switch. Otherwise,
+ It is recommended to use the same HA chassis group for
+ all the external ports of a logical switch. Otherwise,
the physical switch might see MAC flap issue when differ‐
ent chassis provide the native services. For example when
supporting native DHCPv4 service, DHCPv4 server mac (con‐
- figured in options:server_mac column in table
- DHCP_Options) originating from different ports can cause
- MAC flap issue. The MAC of the logical router IP(s) can
- also flap if the same HA chassis group is not set for all
- the external ports of a logical switch.
+ figured in options:server_mac column in table DHCP_Op‐‐
+ tions) originating from different ports can cause MAC
+ flap issue. The MAC of the logical router IP(s) can also
+ flap if the same HA chassis group is not set for all the
+ external ports of a logical switch.
Below are some of the use cases where external ports can
be used.
- · VMs connected to SR-IOV nics - Traffic from these
- VMs by passes the kernel stack and local ovn-con‐
+ • VMs connected to SR-IOV nics - Traffic from these
+ VMs by passes the kernel stack and local ovn-con‐‐
troller do not bind these ports and cannot serve
the native services.
- · When CMS supports provisioning baremetal servers.
+ • When CMS supports provisioning baremetal servers.
virtual
Represents a logical port which does not have an OVS port
@@ -939,22 +1050,22 @@
One of the use case where virtual ports can be used is.
- · The virtual ip represents a load balancer vip and
+ • The virtual ip represents a load balancer vip and
the virtual parents provide load balancer service
in an active-standby setup with the active virtual
parent owning the virtual ip.
remote A remote port is to model a port that resides remotely on
another OVN, which is on the other side of a transit log‐
- ical switch for OVN interconnection. This type of ports
- are created by ovn-ic instead of by CMS. Any change to
+ ical switch for OVN interconnection. This type of ports
+ are created by ovn-ic instead of by CMS. Any change to
the port will be automatically overwritten by ovn-ic.
Options:
options: map of string-string pairs
- This column provides key/value settings specific to the logical
- port type. The type-specific options are described individually
+ This column provides key/value settings specific to the logical
+ port type. The type-specific options are described individually
below.
Options for router ports:
@@ -966,51 +1077,59 @@
ical switch port is connected.
options : nat-addresses: optional string
- This is used to send gratuitous ARPs for SNAT and DNAT IP
- addresses via the localnet port that is attached to the same
- logical switch as this type router port. This option is speci‐
- fied on a logical switch port that is connected to a gateway
- router, or a logical switch port that is connected to a distrib‐
- uted gateway port on a logical router.
+ This is used to send gratuitous ARPs for SNAT and DNAT IP ad‐
+ dresses via the localnet port that is attached to the same logi‐
+ cal switch as this type router port. This option is specified on
+ a logical switch port that is connected to a gateway router, or
+ a logical switch port that is connected to a distributed gateway
+ port on a logical router.
This must take one of the following forms:
router Gratuitous ARPs will be sent for all SNAT and DNAT exter‐
nal IP addresses and for all load balancer IP addresses
- defined on the options:router-port’s logical router,
- using the options:router-port’s MAC address.
+ defined on the options:router-port’s logical router, us‐
+ ing the options:router-port’s MAC address.
This form of options:nat-addresses is valid for logical
switch ports where options:router-port is the name of a
port on a gateway router, or the name of a distributed
gateway port.
- Supported only in OVN 2.8 and later. Earlier versions
- required NAT addresses to be manually synchronized.
+ Supported only in OVN 2.8 and later. Earlier versions re‐
+ quired NAT addresses to be manually synchronized.
Ethernet address followed by one or more IPv4 addresses
- Example: 80:fa:5b:06:72:b7 158.36.44.22 158.36.44.24.
+ Example: 80:fa:5b:06:72:b7 158.36.44.22 158.36.44.24.
This would result in generation of gratuitous ARPs for IP
- addresses 158.36.44.22 and 158.36.44.24 with a MAC
- address of 80:fa:5b:06:72:b7.
+ addresses 158.36.44.22 and 158.36.44.24 with a MAC ad‐
+ dress of 80:fa:5b:06:72:b7.
This form of options:nat-addresses is only valid for log‐
- ical switch ports where options:router-port is the name
+ ical switch ports where options:router-port is the name
of a port on a gateway router.
options : exclude-lb-vips-from-garp: optional string
- If options:nat-addresses is set to router, Gratuitous ARPs will
- be sent for all SNAT and DNAT external IP addresses defined on
- the options:router-port’s logical router, using the
- options:router-port’s MAC address, not cosidering configured
- load balancers.
+ If options:nat-addresses is set to router, Gratuitous ARPs will
+ be sent for all SNAT and DNAT external IP addresses defined on
+ the options:router-port’s logical router, using the op‐‐
+ tions:router-port’s MAC address, not cosidering configured load
+ balancers.
options : arp_proxy: optional string
- Optional. A list of IPv4 addresses that this logical switch
- router port will reply to ARP requests. Example: 169.254.239.254
- 169.254.239.2. The options:router-port’s logical router should
- have a route to forward packets sent to configured proxy ARP IPs
- to an appropriate destination.
+ Optional. A list of MAC and addresses/cidrs or just ad‐
+ dresses/cidrs that this logical switch router port will reply to
+ ARP/NDP requests. Examples: 169.254.239.254 169.254.239.2,
+ 0a:58:a9:fe:01:01 169.254.239.254 169.254.239.2
+ 169.254.238.0/24, fd7b:6b4d:7b25:d22f::1 fd7b:6b4d:7b25:d22f::2,
+ 0a:58:a9:fe:01:01 fd7b:6b4d:7b25:d22f::0/64. Theoptions:router-
+ port’s logical router should have a route to forward packets
+ sent to configured proxy ARP MAC/IPs to an appropriate destina‐
+ tion.
+
+ options : enable_router_port_acl: optional string, either true or false
+ Optional. Enable conntrack for the router port whose peer is
+ l3dgw_port if set to true. The default value is false.
Options for localnet ports:
@@ -1019,12 +1138,12 @@
options : network_name: optional string
Required. The name of the network to which the localnet port is
connected. Each hypervisor, via ovn-controller, uses its local
- configuration to determine exactly how to connect to this
- locally accessible network, if at all.
+ configuration to determine exactly how to connect to this lo‐
+ cally accessible network, if at all.
options : ethtype: optional string
Optional. VLAN EtherType field value for encapsulating VLAN
- headers. Supported values: 802.11q (default), 802.11ad.
+ headers. Supported values: 802.1q (default), 802.1ad.
options : localnet_learn_fdb: optional string, either true or false
Optional. Allows localnet port to learn MACs and store them in
@@ -1036,8 +1155,8 @@
options : network_name: optional string
Required. The name of the network to which the l2gateway port is
- connected. The L2 gateway, via ovn-controller, uses its local
- configuration to determine exactly how to connect to this net‐
+ connected. The L2 gateway, via ovn-controller, uses its local
+ configuration to determine exactly how to connect to this net‐
work.
options : l2gateway-chassis: optional string
@@ -1061,10 +1180,10 @@
options : requested-chassis: optional string
If set, identifies a specific chassis (by name or hostname) that
- is allowed to bind this port. Using this option will prevent
- thrashing between two chassis trying to bind the same port dur‐
- ing a live migration. It can also prevent similar thrashing due
- to a mis-configuration, if a port is accidentally created on
+ is allowed to bind this port. Using this option will prevent
+ thrashing between two chassis trying to bind the same port dur‐
+ ing a live migration. It can also prevent similar thrashing due
+ to a mis-configuration, if a port is accidentally created on
more than one chassis.
If set to a comma separated list, the first entry identifies the
@@ -1078,16 +1197,16 @@
MTU implications because the network used for tunneling must
have MTU larger than localnet for stable connectivity.
- If the same host co-hosts more than one controller instance
- (either belonging to the same or separate clusters), special
- attention should be given to consistently using unique chassis
- names used in this option. It is advised that chassis names -
- and not host names - are used for this option.
+ If the same host co-hosts more than one controller instance (ei‐
+ ther belonging to the same or separate clusters), special atten‐
+ tion should be given to consistently using unique chassis names
+ used in this option. It is advised that chassis names - and not
+ host names - are used for this option.
options : activation-strategy: optional string
If used with multiple chassis set in requested-chassis, speci‐
- fies an activation strategy for all additional chassis. By
- default, no activation strategy is used, meaning additional port
+ fies an activation strategy for all additional chassis. By de‐
+ fault, no activation strategy is used, meaning additional port
locations are immediately available for use. When set to "rarp",
the port is blocked for ingress and egress communication until a
RARP packet is sent from a new location. The "rarp" strategy is
@@ -1103,9 +1222,9 @@
sent from this interface, in bit/s.
options : qos_max_rate: optional string
- If set, indicates the maximum rate for data sent from this
- interface, in bit/s. The traffic will be shaped according to
- this limit.
+ If set, indicates the maximum rate for data sent from this in‐
+ terface, in bit/s. The traffic will be shaped according to this
+ limit.
options : qos_burst: optional string
If set, indicates the maximum burst size for data sent from this
@@ -1114,25 +1233,25 @@
options : hostname: optional string
If set, indicates the DHCPv4 option "Hostname" (option code 12)
associated for this Logical Switch Port. If DHCPv4 is enabled
- for this Logical Switch Port, hostname dhcp option will be
- included in DHCP reply.
+ for this Logical Switch Port, hostname dhcp option will be in‐
+ cluded in DHCP reply.
VIF Plugging Options:
options : vif-plug-type: optional string
- If set, OVN will attempt to perform plugging of this VIF. In
- order to get this port plugged by the OVN controller, OVN must
- be built with support for VIF plugging. The default behavior is
- for the CMS to do the VIF plugging. Each VIF plug provider have
+ If set, OVN will attempt to perform plugging of this VIF. In or‐
+ der to get this port plugged by the OVN controller, OVN must be
+ built with support for VIF plugging. The default behavior is for
+ the CMS to do the VIF plugging. Each VIF plug provider have
their own options namespaced by name, for example "vif-plug:rep‐
- resentor:key". Please refer to the VIF plug provider documenta‐
+ resentor:key". Please refer to the VIF plug provider documenta‐
tion located in Documentation/topics/vif-plug-providers/ for
more information.
options : vif-plug-mtu-request: optional string
- Requested MTU for plugged interfaces. When set the OVN con‐
- troller will fill the mtu_request column of the Open vSwitch
- database’s Interface table. This in turn will make OVS vswitchd
+ Requested MTU for plugged interfaces. When set the OVN con‐
+ troller will fill the mtu_request column of the Open vSwitch
+ database’s Interface table. This in turn will make OVS vswitchd
update the MTU of the linked interface.
Virtual port Options:
@@ -1146,7 +1265,7 @@
This options represents a set of logical port names (with in the
same logical switch) which can own the virtual ip configured in
the options:virtual-ip. All these virtual parents should add the
- virtual ip in the port_security if port security addressed are
+ virtual ip in the port_security if port security addressed are
enabled.
IP Multicast Snooping Options:
@@ -1172,56 +1291,61 @@
ical wire, even inside a tunnel, so they need not be unique except rel‐
ative to a single VM on a hypervisor.
- These columns are used for VIFs that represent nested containers using
- shared VIFs. For VMs and for containers that have dedicated VIFs, they
+ These columns are used for VIFs that represent nested containers using
+ shared VIFs. For VMs and for containers that have dedicated VIFs, they
are empty.
parent_name: optional string
- The VM interface through which the nested container sends its
- network traffic. This must match the name column for some other
- Logical_Switch_Port.
+ The VM interface through which the nested container sends its
+ network traffic. This must match the name column for some other
+ Logical_Switch_Port. Note: for performance of the OVN Southbound
+ database conditional monitoring, unlike for regular VIFs,
+ ovn-controller will register to get updates about all OVN South‐
+ bound database Port_Binding table records that correspond to
+ nested container ports even if external_ids:ovn-monitor-all is
+ set to false. See ovn-controller(8) for more information.
tag_request: optional integer, in range 0 to 4,095
The VLAN tag in the network traffic associated with a con‐
tainer’s network interface. The client can request ovn-northd to
- allocate a tag that is unique within the scope of a specific
- parent (specified in parent_name) by setting a value of 0 in
+ allocate a tag that is unique within the scope of a specific
+ parent (specified in parent_name) by setting a value of 0 in
this column. The allocated value is written by ovn-northd in the
- tag column. (Note that these tags are allocated and managed
- locally in ovn-northd, so they cannot be reconstructed in the
+ tag column. (Note that these tags are allocated and managed lo‐
+ cally in ovn-northd, so they cannot be reconstructed in the
event that the database is lost.) The client can also request a
specific non-zero tag and ovn-northd will honor it and copy that
value to the tag column.
- When type is set to localnet or l2gateway, this can be set to
- indicate that the port represents a connection to a specific
- VLAN on a locally accessible network. The VLAN ID is used to
+ When type is set to localnet or l2gateway, this can be set to
+ indicate that the port represents a connection to a specific
+ VLAN on a locally accessible network. The VLAN ID is used to
match incoming traffic and is also added to outgoing traffic.
tag: optional integer, in range 1 to 4,095
- The VLAN tag allocated by ovn-northd based on the contents of
+ The VLAN tag allocated by ovn-northd based on the contents of
the tag_request column.
Port State:
up: optional boolean
- This column is populated by ovn-northd, rather than by the CMS
+ This column is populated by ovn-northd, rather than by the CMS
plugin as is most of this database. When a logical port is bound
to a physical location in the OVN Southbound database Binding
table, ovn-northd sets this column to true; otherwise, or if the
- port becomes unbound later, it sets it to false. If this column
- is empty, the port is not considered up. This allows the CMS to
- wait for a VM’s (or container’s) networking to become active
- before it allows the VM (or container) to start.
+ port becomes unbound later, it sets it to false. If this column
+ is empty, the port is not considered up. This allows the CMS to
+ wait for a VM’s (or container’s) networking to become active be‐
+ fore it allows the VM (or container) to start.
Logical ports of router type are an exception to this rule. They
- are considered to be always up, that is this column is always
+ are considered to be always up, that is this column is always
set to true.
enabled: optional boolean
- This column is used to administratively set port state. If this
- column is empty or is set to true, the port is enabled. If this
- column is set to false, the port is disabled. A disabled port
+ This column is used to administratively set port state. If this
+ column is empty or is set to true, the port is enabled. If this
+ column is set to false, the port is disabled. A disabled port
has all ingress and egress traffic dropped.
Addressing:
@@ -1234,29 +1358,29 @@
Ethernet address followed by zero or more IPv4 or IPv6 addresses
(or both)
An Ethernet address defined is owned by the logical port.
- Like a physical Ethernet NIC, a logical port ordinarily
+ Like a physical Ethernet NIC, a logical port ordinarily
has a single fixed Ethernet address.
- When a OVN logical switch processes a unicast Ethernet
- frame whose destination MAC address is in a logical
- port’s addresses column, it delivers it only to that
- port, as if a MAC learning process had learned that MAC
+ When a OVN logical switch processes a unicast Ethernet
+ frame whose destination MAC address is in a logical
+ port’s addresses column, it delivers it only to that
+ port, as if a MAC learning process had learned that MAC
address on the port.
- If IPv4 or IPv6 address(es) (or both) are defined, it
- indicates that the logical port owns the given IP
- addresses.
+ If IPv4 or IPv6 address(es) (or both) are defined, it in‐
+ dicates that the logical port owns the given IP ad‐
+ dresses.
If IPv4 address(es) are defined, the OVN logical switch
- uses this information to synthesize responses to ARP
- requests without traversing the physical network. The OVN
+ uses this information to synthesize responses to ARP re‐
+ quests without traversing the physical network. The OVN
logical router connected to the logical switch, if any,
uses this information to avoid issuing ARP requests for
logical switch ports.
- Note that the order here is important. The Ethernet
- address must be listed before the IP address(es) if
- defined.
+ Note that the order here is important. The Ethernet ad‐
+ dress must be listed before the IP address(es) if de‐
+ fined.
Examples:
@@ -1272,38 +1396,38 @@
This indicates that the logical port owns the mac
address and 1 IPv6 address.
- 80:fa:5b:06:72:b7 10.0.0.4
+ 80:fa:5b:06:72:b7 10.0.0.4
fdaa:15f2:72cf:0:f816:3eff:fe20:3f41
- This indicates that the logical port owns the mac
+ This indicates that the logical port owns the mac
address and 1 IPv4 address and 1 IPv6 address.
unknown
- This indicates that the logical port has an unknown set
- of Ethernet addresses. When an OVN logical switch pro‐
- cesses a unicast Ethernet frame whose destination MAC
+ This indicates that the logical port has an unknown set
+ of Ethernet addresses. When an OVN logical switch
+ processes a unicast Ethernet frame whose destination MAC
address is not in any logical port’s addresses column, it
- delivers it to the port (or ports) whose addresses col‐
- umns include unknown.
+ delivers it to the port (or ports) whose addresses
+ columns include unknown.
dynamic
Use dynamic to make ovn-northd generate a globally unique
MAC address, choose an unused IPv4 address with the logi‐
cal port’s subnet (if other_config:subnet is set in the
port’s Logical_Switch), and generate an IPv6 address from
- the MAC address (if other_config:ipv6_prefix is set in
- the port’s Logical_Switch) and store them in the port’s
+ the MAC address (if other_config:ipv6_prefix is set in
+ the port’s Logical_Switch) and store them in the port’s
dynamic_addresses column.
- Only one element containing dynamic may appear in
- addresses.
+ Only one element containing dynamic may appear in ad‐‐
+ dresses.
dynamic ip
dynamic ipv6
dynamic ip ipv6
These act like dynamic alone but specify particular IPv4 or
IPv6 addresses to use. OVN IPAM will still automatically
- allocate the other address if configured appropriately.
- Example: dynamic 192.168.0.1 2001::1.
+ allocate the other address if configured appropriately. Ex‐
+ ample: dynamic 192.168.0.1 2001::1.
mac dynamic
This acts like dynamic alone but specifies a particular MAC
@@ -1326,54 +1450,54 @@
specified in nat with external_mac, then those addresses
are also used to populate the switch’s destination lookup.
- Supported only in OVN 2.7 and later. Earlier versions
- required router addresses to be manually synchronized.
+ Supported only in OVN 2.7 and later. Earlier versions re‐
+ quired router addresses to be manually synchronized.
dynamic_addresses: optional string
Addresses assigned to the logical port by ovn-northd, if dynamic
- is specified in addresses. Addresses will be of the same format
- as those that populate the addresses column. Note that dynami‐
- cally assigned addresses are constructed and managed locally in
- ovn-northd, so they cannot be reconstructed in the event that
+ is specified in addresses. Addresses will be of the same format
+ as those that populate the addresses column. Note that dynami‐
+ cally assigned addresses are constructed and managed locally in
+ ovn-northd, so they cannot be reconstructed in the event that
the database is lost.
port_security: set of strings
- This column controls the addresses from which the host attached
- to the logical port (``the host’’) is allowed to send packets
+ This column controls the addresses from which the host attached
+ to the logical port (``the host’’) is allowed to send packets
and to which it is allowed to receive packets. If this column is
empty, all addresses are permitted.
Each element in the set must begin with one Ethernet address.
This would restrict the host to sending packets from and receiv‐
- ing packets to the ethernet addresses defined in the logical
- port’s port_security column. It also restricts the inner source
- MAC addresses that the host may send in ARP and IPv6 Neighbor
+ ing packets to the ethernet addresses defined in the logical
+ port’s port_security column. It also restricts the inner source
+ MAC addresses that the host may send in ARP and IPv6 Neighbor
Discovery packets. The host is always allowed to receive packets
to multicast and broadcast Ethernet addresses.
Each element in the set may additionally contain one or more
IPv4 or IPv6 addresses (or both), with optional masks. If a mask
- is given, it must be a CIDR mask. In addition to the restric‐
- tions described for Ethernet addresses above, such an element
- restricts the IPv4 or IPv6 addresses from which the host may
- send and to which it may receive packets to the specified
- addresses. A masked address, if the host part is zero, indicates
- that the host is allowed to use any address in the subnet; if
- the host part is nonzero, the mask simply indicates the size of
+ is given, it must be a CIDR mask. In addition to the restric‐
+ tions described for Ethernet addresses above, such an element
+ restricts the IPv4 or IPv6 addresses from which the host may
+ send and to which it may receive packets to the specified ad‐
+ dresses. A masked address, if the host part is zero, indicates
+ that the host is allowed to use any address in the subnet; if
+ the host part is nonzero, the mask simply indicates the size of
the subnet. In addition:
- · If any IPv4 address is given, the host is also allowed to
+ • If any IPv4 address is given, the host is also allowed to
receive packets to the IPv4 local broadcast address
255.255.255.255 and to IPv4 multicast addresses
(224.0.0.0/4). If an IPv4 address with a mask is given,
the host is also allowed to receive packets to the broad‐
cast address in that specified subnet.
- If any IPv4 address is given, the host is additionally
- restricted to sending ARP packets with the specified
+ If any IPv4 address is given, the host is additionally
+ restricted to sending ARP packets with the specified
source IPv4 address. (RARP is not restricted.)
- · If any IPv6 address is given, the host is also allowed to
+ • If any IPv6 address is given, the host is also allowed to
receive packets to IPv6 multicast addresses (ff00::/8).
If any IPv6 address is given, the host is additionally
@@ -1383,16 +1507,16 @@
If an element includes an IPv4 address, but no IPv6 addresses,
then IPv6 traffic is not allowed. If an element includes an IPv6
- address, but no IPv4 address, then IPv4 and ARP traffic is not
+ address, but no IPv4 address, then IPv4 and ARP traffic is not
allowed.
- This column uses the same lexical syntax as the match column in
+ This column uses the same lexical syntax as the match column in
the OVN Southbound database’s Pipeline table. Multiple addresses
within an element may be space or comma separated.
This column is provided as a convenience to cloud management
- systems, but all of the features that it implements can be
- implemented as ACLs using the ACL table.
+ systems, but all of the features that it implements can be im‐
+ plemented as ACLs using the ACL table.
Examples:
@@ -1400,19 +1524,19 @@
The host may send traffic from and receive traffic to the
specified MAC address, and to receive traffic to Ethernet
multicast and broadcast addresses, but not otherwise. The
- host may not send ARP or IPv6 Neighbor Discovery packets
- with inner source Ethernet addresses other than the one
+ host may not send ARP or IPv6 Neighbor Discovery packets
+ with inner source Ethernet addresses other than the one
specified.
80:fa:5b:06:72:b7 192.168.1.10/24
- This adds further restrictions to the first example. The
- host may send IPv4 packets from or receive IPv4 packets
- to only 192.168.1.10, except that it may also receive
+ This adds further restrictions to the first example. The
+ host may send IPv4 packets from or receive IPv4 packets
+ to only 192.168.1.10, except that it may also receive
IPv4 packets to 192.168.1.255 (based on the subnet mask),
255.255.255.255, and any address in 224.0.0.0/4. The host
- may not send ARPs with a source Ethernet address other
- than 80:fa:5b:06:72:b7 or source IPv4 address other than
- 192.168.1.10. The host may not send or receive any IPv6
+ may not send ARPs with a source Ethernet address other
+ than 80:fa:5b:06:72:b7 or source IPv4 address other than
+ 192.168.1.10. The host may not send or receive any IPv6
(including IPv6 Neighbor Discovery) traffic.
"80:fa:5b:12:42:ba", "80:fa:5b:06:72:b7 192.168.1.10/24"
@@ -1445,7 +1569,7 @@
source. Please see the Mirror table.
ha_chassis_group: optional HA_Chassis_Group
- References a row in the OVN Northbound database’s HA_Chas‐
+ References a row in the OVN Northbound database’s HA_Chas‐‐
sis_Group table. It indicates the HA chassis group to use if the
type is set to external. If type is not external, this column is
ignored.
@@ -1458,7 +1582,7 @@
vide convenience for human interaction with the northbound data‐
base.
- Neutron copies this from its own port object’s name. (Neutron
+ Neutron copies this from its own port object’s name. (Neutron
ports do are not assigned human-friendly names by default, so it
will often be empty.)
@@ -1466,13 +1590,13 @@
options : requested-tnl-key: optional string, containing an integer, in
range 1 to 32,767
- Configures the port binding tunnel key for the port. Usually
- this is not needed because ovn-northd will assign an unique key
- for each port by itself. However, if it is configured,
- ovn-northd honors the configured value. The typical use case is
- for interconnection: the tunnel keys for ports on transit
- switches need to be unique globally, so they are maintained in
- the global OVN_IC_Southbound database, and ovn-ic simply syncs
+ Configures the port binding tunnel key for the port. Usually
+ this is not needed because ovn-northd will assign an unique key
+ for each port by itself. However, if it is configured,
+ ovn-northd honors the configured value. The typical use case is
+ for interconnection: the tunnel keys for ports on transit
+ switches need to be unique globally, so they are maintained in
+ the global OVN_IC_Southbound database, and ovn-ic simply syncs
the value from OVN_IC_Southbound through this config.
Common Columns:
@@ -1480,7 +1604,7 @@
external_ids: map of string-string pairs
See External IDs at the beginning of this document.
- The ovn-northd program copies all these pairs into the exter‐
+ The ovn-northd program copies all these pairs into the exter‐‐
nal_ids column of the Port_Binding table in OVN_Southbound data‐
base.
@@ -1499,8 +1623,8 @@
Details:
name: string
A name for the forwarding group. This name has no special mean‐
- ing or purpose other than to provide convenience for human
- interaction with the ovn-nb database.
+ ing or purpose other than to provide convenience for human in‐
+ teraction with the ovn-nb database.
vip: string
The virtual IP address assigned to the forwarding group. It will
@@ -1524,12 +1648,12 @@
Address_Set TABLE
Each row in this table represents a named set of addresses. An address
set may contain Ethernet, IPv4, or IPv6 addresses with optional bitwise
- or CIDR masks. Address set may ultimately be used in ACLs to compare
- against fields such as ip4.src or ip6.src. A single address set must
- contain addresses of the same type. As an example, the following would
+ or CIDR masks. Address set may ultimately be used in ACLs to compare
+ against fields such as ip4.src or ip6.src. A single address set must
+ contain addresses of the same type. As an example, the following would
create an address set with three IP addresses:
- ovn-nbctl create Address_Set name=set1 addresses=’10.0.0.1 10.0.0.2 10.0.0.3’
+ ovn-nbctl create Address_Set name=set1 addresses=’’10.0.0.1 10.0.0.2 10.0.0.3’’
Address sets may be used in the match column of the ACL table. For syn‐
@@ -1565,19 +1689,19 @@
the match column in the Logical_Flow table of the OVN_Southbound data‐
base.
- For each port group, there are two address sets generated to the
- Address_Set table of the OVN_Southbound database, containing the IP
- addresses of the group of ports, one for IPv4, and the other for IPv6,
+ For each port group, there are two address sets generated to the Ad‐‐
+ dress_Set table of the OVN_Southbound database, containing the IP ad‐
+ dresses of the group of ports, one for IPv4, and the other for IPv6,
with name being the name of the Port_Group followed by a suffix _ip4
for IPv4 and _ip6 for IPv6. The generated address sets can be used in
the same way as regular address sets in the match column of the ACL ta‐
ble. For syntax information, see the details of the expression language
- used for the match column in the Logical_Flow table of the OVN_South‐
+ used for the match column in the Logical_Flow table of the OVN_South‐‐
bound database.
Summary:
name string (must be unique within table)
- ports set of weak reference to Logi‐
+ ports set of weak reference to Logi‐‐
cal_Switch_Ports
acls set of ACLs
Common Columns:
@@ -1626,6 +1750,7 @@
options : template optional string
options : address-family optional string
options : affinity_timeout optional string
+ options : ct_flush optional string, either true or false
Details:
name: string
@@ -1638,20 +1763,20 @@
: as a separator) associated with this load balancer and their
corresponding endpoint IP addresses (and optional port numbers
with : as separators) separated by commas. If the destination IP
- address (and port number) of a packet leaving a container or a
- VM matches the virtual IP address (and port number) provided
- here as a key, then OVN will statefully replace the destination
- IP address by one of the provided IP address (and port number)
- in this map as a value. IPv4 and IPv6 addresses are supported
- for load balancing; however a VIP of one address family may not
- be mapped to a destination IP address of a different family. If
+ address (and port number) of a packet leaving a container or a
+ VM matches the virtual IP address (and port number) provided
+ here as a key, then OVN will statefully replace the destination
+ IP address by one of the provided IP address (and port number)
+ in this map as a value. IPv4 and IPv6 addresses are supported
+ for load balancing; however a VIP of one address family may not
+ be mapped to a destination IP address of a different family. If
specifying an IPv6 address with a port, the address portion must
be enclosed in square brackets. Examples for keys are
"192.168.1.4" and "[fd0f::1]:8800". Examples for value are
"10.0.0.1, 10.0.0.2" and "20.0.0.10:8800, 20.0.0.11:8800".
When the Load_Balancer is added to the logical_switch, the VIP
- has to be in a different subnet than the one used for the logi‐
+ has to be in a different subnet than the one used for the logi‐‐
cal_switch. Since VIP is in a different subnet, you should con‐
nect your logical switch to either a OVN logical router or a
real router (this is because the client can now send a packet
@@ -1666,47 +1791,52 @@
Health Checks:
- OVN supports health checks for load balancer endpoints, for IPv4 load
- balancers only. When health checks are enabled, the load balancer uses
- only healthy endpoints.
+ OVN supports health checks for load balancer endpoints. When health
+ checks are enabled, the load balancer uses only healthy endpoints.
- Suppose that vips contains a key-value pair
- 10.0.0.10:80=10.0.0.4:8080,20.0.0.4:8080. To enable health checks for
- this virtual’s endpoints, add two key-value pairs to ip_port_mappings,
+ Suppose that vips contains a key-value pair
+ 10.0.0.10:80=10.0.0.4:8080,20.0.0.4:8080. To enable health checks for
+ this virtual’s endpoints, add two key-value pairs to ip_port_mappings,
with keys 10.0.0.4 and 20.0.0.4, and add to health_check a reference to
- a Load_Balancer_Health_Check row whose vip is set to 10.0.0.10.
+ a Load_Balancer_Health_Check row whose vip is set to 10.0.0.10. The
+ same approach can be used for IPv6 as well.
health_check: set of Load_Balancer_Health_Checks
Load balancer health checks associated with this load balancer.
ip_port_mappings: map of string-string pairs
- Maps from endpoint IP to a colon-separated pair of logical port
- name and source IP, e.g. port_name:sourc_ip. Health checks are
- sent to this port with the specified source IP.
-
- For example, in the example above, IP to port mappings might be
- defined as 10.0.0.4=sw0-p1:10.0.0.2 and
- 20.0.0.4=sw1-p1:20.0.0.2, if the values given were suitable
+ Maps from endpoint IP to a colon-separated pair of logical port
+ name and source IP, e.g. port_name:sourc_ip for IPv4. Health
+ checks are sent to this port with the specified source IP. For
+ IPv6 square brackets must be used around IP address, e.g:
+ port_name:[sourc_ip]
+
+ For example, in the example above, IP to port mappings might be
+ defined as 10.0.0.4=sw0-p1:10.0.0.2 and
+ 20.0.0.4=sw1-p1:20.0.0.2, if the values given were suitable
ports and IP addresses.
- selection_fields: set of strings, one of eth_dst, eth_src, ip_dst,
+ For IPv6 IP to port mappings might be defined as
+ [2001::1]=sw0-p1:[2002::1].
+
+ selection_fields: set of strings, one of eth_dst, eth_src, ip_dst,
ip_src, tp_dst, or tp_src
- OVN native load balancers are supported using the OpenFlow
- groups of type select. OVS supports two selection methods:
- dp_hash and hash (with optional fields specified) in selecting
- the buckets of a group. Please see the OVS documentation (man
- ovs-ofctl) for more details on the selection methods. Each end‐
- point IP (and port if set) is mapped to a bucket in the group
+ OVN native load balancers are supported using the OpenFlow
+ groups of type select. OVS supports two selection methods:
+ dp_hash and hash (with optional fields specified) in selecting
+ the buckets of a group. Please see the OVS documentation (man
+ ovs-ofctl) for more details on the selection methods. Each end‐
+ point IP (and port if set) is mapped to a bucket in the group
flow.
- CMS can choose the hash selection method by setting the selec‐
- tion fields in this column. ovs-vswitchd uses the specified
+ CMS can choose the hash selection method by setting the selec‐
+ tion fields in this column. ovs-vswitchd uses the specified
fields in generating the hash.
dp_hash selection method uses the assistance of datapath to cal‐
culate the hash and it is expected to be faster than hash selec‐
- tion method. So CMS should take this into consideration before
- using the hash method. Please consult the OVS documentation and
+ tion method. So CMS should take this into consideration before
+ using the hash method. Please consult the OVS documentation and
OVS sources for the implementation details.
Common Columns:
@@ -1717,17 +1847,17 @@
Load_Balancer options:
options : reject: optional string, either true or false
- If the load balancer is created with --reject option and it has
- no active backends, a TCP reset segment (for tcp) or an ICMP
- port unreachable packet (for all other kind of traffic) will be
- sent whenever an incoming packet is received for this load-bal‐
- ancer. Please note using --reject option will disable empty_lb
+ If the load balancer is created with --reject option and it has
+ no active backends, a TCP reset segment (for tcp) or an ICMP
+ port unreachable packet (for all other kind of traffic) will be
+ sent whenever an incoming packet is received for this load-bal‐
+ ancer. Please note using --reject option will disable empty_lb
SB controller event for this load balancer.
options : hairpin_snat_ip: optional string
- IP to be used as source IP for packets that have been hair-
- pinned after load balancing. The default behavior when the
- option is not set is to use the load balancer VIP as source IP.
+ IP to be used as source IP for packets that have been hair-
+ pinned after load balancing. The default behavior when the op‐
+ tion is not set is to use the load balancer VIP as source IP.
This option may have exactly one IPv4 and/or one IPv6 address on
it, separated by a space character.
@@ -1741,20 +1871,20 @@
If set to true, then neighbor routers will have logical flows
added that will allow for routing to the VIP IP. It also will
have ARP resolution logical flows added. By setting this option,
- it means there is no reason to create a Logi‐
- cal_Router_Static_Route from neighbor routers to this NAT
- address. It also means that no ARP request is required for
- neighbor routers to learn the IP-MAC mapping for this VIP IP.
- For more information about what flows are added for IP routes,
- please see the ovn-northd manpage section on IP Routing.
+ it means there is no reason to create a Logical_Router_Sta‐‐
+ tic_Route from neighbor routers to this NAT address. It also
+ means that no ARP request is required for neighbor routers to
+ learn the IP-MAC mapping for this VIP IP. For more information
+ about what flows are added for IP routes, please see the
+ ovn-northd manpage section on IP Routing.
options : neighbor_responder: optional string
- If set to all, then routers on which the load balancer is
- applied reply to ARP/neighbor discovery requests for all VIPs of
- the load balancer. If set to reachable, then routers on which
- the load balancer is applied reply to ARP/neighbor discovery
- requests only for VIPs that are part of a router’s subnet. If
- set to none, then routers on which the load balancer is applied
+ If set to all, then routers on which the load balancer is ap‐
+ plied reply to ARP/neighbor discovery requests for all VIPs of
+ the load balancer. If set to reachable, then routers on which
+ the load balancer is applied reply to ARP/neighbor discovery re‐
+ quests only for VIPs that are part of a router’s subnet. If set
+ to none, then routers on which the load balancer is applied
never reply to ARP/neighbor discovery requests for any of the
load balancer VIPs. Load balancers with options:template=true do
not support reachable as a valid mode. The default value of this
@@ -1763,7 +1893,7 @@
options : template: optional string
Option to be set to true, if the load balancer is a template.
- The load balancer VIPs and backends must be using Chassis_Tem‐
+ The load balancer VIPs and backends must be using Chassis_Tem‐‐
plate_Var in their definitions.
Load balancer template VIP supported formats are:
@@ -1785,27 +1915,34 @@
^BACKENDS_VAR1,^BACKENDS_VAR2
- where BACKEND_VAR1, PORT_VAR1, BACKEND_VAR2, PORT_VAR2, BACK‐
+ where BACKEND_VAR1, PORT_VAR1, BACKEND_VAR2, PORT_VAR2, BACK‐‐
ENDS_VAR1 and BACKENDS_VAR2 are keys of the Chassis_Template_Var
variables records.
options : address-family: optional string
- Address family used by the load balancer. Supported values are
- ipv4 and ipv6. The address-family is only used for load bal‐
- ancers with options:template=true. For explicit load balancers,
+ Address family used by the load balancer. Supported values are
+ ipv4 and ipv6. The address-family is only used for load bal‐
+ ancers with options:template=true. For explicit load balancers,
setting the address-family has no effect.
options : affinity_timeout: optional string
- If the CMS provides a positive value (in seconds) for affin‐
- ity_timeout, OVN will dnat connections received from the same
- client to this lb to the same backend if received in the affin‐
+ If the CMS provides a positive value (in seconds) for affin‐‐
+ ity_timeout, OVN will dnat connections received from the same
+ client to this lb to the same backend if received in the affin‐
ity timeslot. Max supported affinity_timeout is 65535 seconds.
+ options : ct_flush: optional string, either true or false
+ The value indicates whether ovn-controller should flush CT en‐
+ tries that are related to this LB. The flush happens if the LB
+ is removed, any of the backends is updated/removed or the LB is
+ not considered local anymore by the ovn-controller. This option
+ is set to false by default.
+
Load_Balancer_Group TABLE
- Each row represents a logical grouping of load balancers. It is up to
- the CMS to decide the criteria on which load balancers are grouped
- together. To simplify configuration and to optimize its processing load
- balancers that must be associated to the same set of logical switches
+ Each row represents a logical grouping of load balancers. It is up to
+ the CMS to decide the criteria on which load balancers are grouped to‐
+ gether. To simplify configuration and to optimize its processing load
+ balancers that must be associated to the same set of logical switches
and/or logical routers should be grouped together.
Summary:
@@ -1814,16 +1951,15 @@
Details:
name: string (must be unique within table)
- A name for the load balancer group. This name has no special
- meaning or purpose other than to provide convenience for human
+ A name for the load balancer group. This name has no special
+ meaning or purpose other than to provide convenience for human
interaction with the ovn-nb database.
load_balancer: set of weak reference to Load_Balancers
A set of load balancers.
Load_Balancer_Health_Check TABLE
- Each row represents one load balancer health check. Health checks are
- supported for IPv4 load balancers only.
+ Each row represents one load balancer health check.
Summary:
vip string
@@ -1863,9 +1999,9 @@
ACL TABLE
Each row in this table represents one ACL rule for a logical switch or
a port group that points to it through its acls column. The action col‐
- umn for the highest-priority matching row in this table determines a
- packet’s treatment. If no row matches, packets are allowed by default.
- (Default-deny treatment is possible: add a rule with priority 0, 1 as
+ umn for the highest-priority matching row in this table determines a
+ packet’s treatment. If no row matches, packets are allowed by default.
+ (Default-deny treatment is possible: add a rule with priority 0, 1 as
match, and deny as action.)
Summary:
@@ -1873,8 +2009,10 @@
priority integer, in range 0 to 32,767
direction string, either from-lport or to-lport
match string
- action string, one of allow-related,
- allow-stateless, allow, drop, or reject
+ action string, one of allow-related, al‐‐
+ low-stateless, allow, drop, pass, or re‐‐
+ ject
+ tier integer, in range 0 to 3
options:
options : apply-after-lb optional string
Logging:
@@ -1902,7 +2040,7 @@
allow-related actions.
priority: integer, in range 0 to 32,767
- The ACL rule’s priority. Rules with numerically higher priority
+ The ACL rule’s priority. Rules with numerically higher priority
take precedence over those with lower. If two ACL rules with the
same priority both match, then the one actually applied to a
packet is undefined.
@@ -1911,64 +2049,86 @@
cannot be changed through an ACL.
allow-stateless flows always take precedence before stateful
- ACLs, regardless of their priority. (Both allow and
- allow-related ACLs can be stateful.)
+ ACLs, regardless of their priority. (Both allow and allow-re‐‐
+ lated ACLs can be stateful.)
direction: string, either from-lport or to-lport
Direction of the traffic to which this rule should apply:
- · from-lport: Used to implement filters on traffic arriving
+ • from-lport: Used to implement filters on traffic arriving
from a logical port. These rules are applied to the logi‐
cal switch’s ingress pipeline.
- · to-lport: Used to implement filters on traffic forwarded
+ • to-lport: Used to implement filters on traffic forwarded
to a logical port. These rules are applied to the logical
switch’s egress pipeline.
match: string
- The packets that the ACL should match, in the same expression
- language used for the match column in the OVN Southbound data‐
- base’s Logical_Flow table. The outport logical port is only
- available in the to-lport direction (the inport is available in
+ The packets that the ACL should match, in the same expression
+ language used for the match column in the OVN Southbound data‐
+ base’s Logical_Flow table. The outport logical port is only
+ available in the to-lport direction (the inport is available in
both directions).
- By default all traffic is allowed. When writing a more restric‐
- tive policy, it is important to remember to allow flows such as
+ By default all traffic is allowed. When writing a more restric‐
+ tive policy, it is important to remember to allow flows such as
ARP and IPv6 neighbor discovery packets.
- Note that you can not create an ACL matching on a port with
+ Note that you can not create an ACL matching on a port with
type=router or type=localnet.
- action: string, one of allow-related, allow-stateless, allow, drop, or
- reject
+ action: string, one of allow-related, allow-stateless, allow, drop,
+ pass, or reject
The action to take when the ACL rule matches:
- · allow-stateless: Always forward the packet in stateless
+ • allow-stateless: Always forward the packet in stateless
manner, omitting connection tracking mechanism, regard‐
less of other rules defined for the switch. May require
defining additional rules for inbound replies. For exam‐
ple, if you define a rule to allow outgoing TCP traffic
directed to an IP address, then you probably also want to
- define another rule to allow incoming TCP traffic coming
- from this same IP address. In addition, traffic that
+ define another rule to allow incoming TCP traffic coming
+ from this same IP address. In addition, traffic that
matches stateless ACLs will bypass load-balancer DNAT/un-
DNAT processing. Stateful ACLs should be used instead if
the traffic is supposed to be load-balanced.
- · allow: Forward the packet. It will also send the packets
- through connection tracking when allow-related rules
- exist on the logical switch. Otherwise, it’s equivalent
- to allow-stateless.
+ • allow: Forward the packet. It will also send the packets
+ through connection tracking when allow-related rules ex‐
+ ist on the logical switch. Otherwise, it’s equivalent to
+ allow-stateless.
- · allow-related: Forward the packet and related traffic
+ • allow-related: Forward the packet and related traffic
(e.g. inbound replies to an outbound connection).
- · drop: Silently drop the packet.
+ • drop: Silently drop the packet.
- · reject: Drop the packet, replying with a RST for TCP or
+ • reject: Drop the packet, replying with a RST for TCP or
ICMPv4/ICMPv6 unreachable message for other
IPv4/IPv6-based protocols.
+ • pass: Pass to the next ACL tier. If using multiple ACL
+ tiers, a match on this ACL will stop evaluating ACLs at
+ the current tier and move to the next one. If not using
+ ACL tiers or if a pass ACL is matched at the final tier,
+ then the options:default_acl_drop option from the
+ NB_Global table is used to determine how to proceed.
+
+ tier: integer, in range 0 to 3
+ The hierarchical tier that this ACL belongs to.
+
+ ACLs can be assigned to numerical tiers. When evaluating ACLs,
+ an internal counter is used to determine which tier of ACLs
+ should be evaluated. Tier 0 ACLs are evaluated first. If no ver‐
+ dict can be determined, then tier 1 ACLs are evaluated next.
+ This continues until the maximum tier value is reached. If all
+ tiers of ACLs are evaluated and no verdict is reached, then the
+ options:default_acl_drop option from table NB_Global is used to
+ determine how to proceed.
+
+ In this version of OVN, the maximum tier value for ACLs is 3,
+ meaning there are 4 tiers of ACLs allowed (0-3).
+
options:
ACLs options.
@@ -1983,20 +2143,20 @@
OVN will apply the from-lport ACLs in two stages. ACLs without
this option apply-after-lb set, will be applied before the load
- balancer stage and ACLs with this option set will be applied
- after the load balancer stage. The priorities are indepedent
- between these stages and may not be obvious to the CMS. Hence
- CMS should be extra careful when using this option and should
- carefully evaluate the priorities of all the ACLs and the
- default deny/allow ACLs if any.
+ balancer stage and ACLs with this option set will be applied af‐
+ ter the load balancer stage. The priorities are indepedent be‐
+ tween these stages and may not be obvious to the CMS. Hence CMS
+ should be extra careful when using this option and should care‐
+ fully evaluate the priorities of all the ACLs and the default
+ deny/allow ACLs if any.
Logging:
- These columns control whether and how OVN logs packets that match an
+ These columns control whether and how OVN logs packets that match an
ACL.
log: boolean
- If set to true, packets that match the ACL will trigger a log
+ If set to true, packets that match the ACL will trigger a log
message on the transport node or nodes that perform ACL process‐
ing. Logging may be combined with any action.
@@ -2008,23 +2168,23 @@
provides the administrator and the cloud management system a way
to associate a log record with a particular ACL.
- severity: optional string, one of alert, debug, info, notice, or warn‐
+ severity: optional string, one of alert, debug, info, notice, or warn‐‐
ing
The severity of the ACL. The severity levels match those of sys‐
- log, in decreasing level of severity: alert, warning, notice,
+ log, in decreasing level of severity: alert, warning, notice,
info, or debug. When the column is empty, the default is info.
meter: optional string
- The name of a meter to rate-limit log messages for the ACL. The
- string must match the name column of a row in the Meter table.
- By default, log messages are not rate-limited. In order to
- ensure that the same Meter rate limits multiple ACL logs sepa‐
+ The name of a meter to rate-limit log messages for the ACL. The
+ string must match the name column of a row in the Meter table.
+ By default, log messages are not rate-limited. In order to en‐
+ sure that the same Meter rate limits multiple ACL logs sepa‐
rately, set the fair column.
Common Columns:
options: map of string-string pairs
- This column provides general key/value settings. The supported
+ This column provides general key/value settings. The supported
options are described individually below.
ACL configuration options:
@@ -2035,12 +2195,12 @@
the log option must be set to true and a label must be set, and
it must be unique to the ACL. The label is necessary as it is
the only means to associate the reply traffic with the ACL to
- which it belongs. It must be unique, because otherwise it is
- ambiguous which ACL will be matched. Note: If this option is
- enabled, an extra flow is installed in order to log the related
- traffic. Therefore, if this is enabled on all ACLs, then the
- total number of flows necessary to log the ACL traffic is dou‐
- bled, compared to if this option is not enabled.
+ which it belongs. It must be unique, because otherwise it is am‐
+ biguous which ACL will be matched. Note: If this option is en‐
+ abled, an extra flow is installed in order to log the related
+ traffic. Therefore, if this is enabled on all ACLs, then the to‐
+ tal number of flows necessary to log the ACL traffic is doubled,
+ compared to if this option is not enabled.
external_ids: map of string-string pairs
See External IDs at the beginning of this document.
@@ -2072,13 +2232,12 @@
options : always_learn_from_arp_request
optional string, either true or false
options : requested-tnl-key
- optional string, containing an integer,
+ optional string, containing an integer,
in range 1 to 16,777,215
- options : snat-ct-zone optional string, containing an integer,
+ options : snat-ct-zone optional string, containing an integer,
in range 0 to 65,535
options : mac_binding_age_threshold
- optional string, containing an integer,
- in range 0 to 4,294,967,295
+ optional string
Common Columns:
external_ids map of string-string pairs
@@ -2115,14 +2274,14 @@
These columns provide names for the logical router. From OVN’s perspec‐
tive, these names have no special meaning or purpose other than to pro‐
- vide convenience for human interaction with the northbound database.
- There is no requirement for the name to be unique. (For a unique iden‐
+ vide convenience for human interaction with the northbound database.
+ There is no requirement for the name to be unique. (For a unique iden‐
tifier for a logical router, use its row UUID.)
(Originally, name was intended to serve the purpose of a human-friendly
name, but the Neutron integration used it to uniquely identify its own
router object, in the format neutron-uuid. Later on, Neutron started
- propagating the friendly name of a router as external_ids:neu‐
+ propagating the friendly name of a router as external_ids:neu‐‐
tron:router_name. Perhaps this can be cleaned up someday.)
name: string
@@ -2132,9 +2291,9 @@
Another name for the logical router.
copp: optional weak reference to Copp
- The control plane protection policy from table Copp used for
- metering packets sent to ovn-controller from logical ports of
- this router.
+ The control plane protection policy from table Copp used for me‐
+ tering packets sent to ovn-controller from logical ports of this
+ router.
Options:
@@ -2142,25 +2301,25 @@
options : chassis: optional string
If set, indicates that the logical router in question is a Gate‐
- way router (which is centralized) and resides in the set chas‐
- sis. The same value is also used by ovn-controller to uniquely
- identify the chassis in the OVN deployment and comes from exter‐
+ way router (which is centralized) and resides in the set chas‐
+ sis. The same value is also used by ovn-controller to uniquely
+ identify the chassis in the OVN deployment and comes from exter‐‐
nal_ids:system-id in the Open_vSwitch table of Open_vSwitch
database.
The Gateway router can only be connected to a distributed router
- via a switch if SNAT and DNAT are to be configured in the Gate‐
+ via a switch if SNAT and DNAT are to be configured in the Gate‐
way router.
options : dnat_force_snat_ip: optional string
- If set, indicates a set of IP addresses to use to force SNAT a
- packet that has already been DNATed in the gateway router. When
- multiple gateway routers are configured, a packet can poten‐
- tially enter any of the gateway router, get DNATted and eventu‐
+ If set, indicates a set of IP addresses to use to force SNAT a
+ packet that has already been DNATed in the gateway router. When
+ multiple gateway routers are configured, a packet can poten‐
+ tially enter any of the gateway router, get DNATted and eventu‐
ally reach the logical switch port. For the return traffic to go
back to the same gateway router (for unDNATing), the packet
needs a SNAT in the first place. This can be achieved by setting
- the above option with a gateway specific set of IP addresses.
+ the above option with a gateway specific set of IP addresses.
This option may have exactly one IPv4 and/or one IPv6 address on
it, separated by a a space.
@@ -2168,16 +2327,16 @@
If set, this option can take two possible type of values. Either
a set of IP addresses or the string value - router_ip.
- If a set of IP addresses are configured, it indicates to use to
- force SNAT a packet that has already been load-balanced in the
- gateway router. When multiple gateway routers are configured, a
- packet can potentially enter any of the gateway routers, get
- DNATted as part of the load-balancing and eventually reach the
- logical switch port. For the return traffic to go back to the
- same gateway router (for unDNATing), the packet needs a SNAT in
- the first place. This can be achieved by setting the above
- option with a gateway specific set of IP addresses. This option
- may have exactly one IPv4 and/or one IPv6 address on it, sepa‐
+ If a set of IP addresses are configured, it indicates to use to
+ force SNAT a packet that has already been load-balanced in the
+ gateway router. When multiple gateway routers are configured, a
+ packet can potentially enter any of the gateway routers, get
+ DNATted as part of the load-balancing and eventually reach the
+ logical switch port. For the return traffic to go back to the
+ same gateway router (for unDNATing), the packet needs a SNAT in
+ the first place. This can be achieved by setting the above op‐
+ tion with a gateway specific set of IP addresses. This option
+ may have exactly one IPv4 and/or one IPv6 address on it, sepa‐
rated by a space character.
If it is configured with the value router_ip, then the load bal‐
@@ -2186,29 +2345,29 @@
routing decision.
options : mcast_relay: optional string, either true or false
- Enables/disables IP multicast relay between logical switches
+ Enables/disables IP multicast relay between logical switches
connected to the logical router. Default: False.
options : dynamic_neigh_routers: optional string, either true or false
- If set to true, the router will resolve neighbor routers’ MAC
- addresses only by dynamic ARP/ND, instead of prepopulating
- static mappings for all neighbor routers in the ARP/ND Resolu‐
- tion stage. This reduces number of flows, but requires ARP/ND
- messages to resolve the IP-MAC bindings when needed. It is false
- by default. It is recommended to set to true when a large number
- of logical routers are connected to the same logical switch but
- most of them never need to send traffic between each other. By
- default, ovn-northd does not create mappings to NAT and load
+ If set to true, the router will resolve neighbor routers’ MAC
+ addresses only by dynamic ARP/ND, instead of prepopulating sta‐
+ tic mappings for all neighbor routers in the ARP/ND Resolution
+ stage. This reduces number of flows, but requires ARP/ND mes‐
+ sages to resolve the IP-MAC bindings when needed. It is false by
+ default. It is recommended to set to true when a large number of
+ logical routers are connected to the same logical switch but
+ most of them never need to send traffic between each other. By
+ default, ovn-northd does not create mappings to NAT and load
balancer addresess. However, for NAT and load balancer addresses
that have the add_route option added, ovn-northd will create
logical flows that map NAT and load balancer IP addresses to the
- appropriate MAC address. Setting dynamic_neigh_routers to true
+ appropriate MAC address. Setting dynamic_neigh_routers to true
will prevent the automatic creation of these logical flows.
- options : always_learn_from_arp_request: optional string, either true
+ options : always_learn_from_arp_request: optional string, either true
or false
- This option controls the behavior when handling IPv4 ARP
- requests or IPv6 ND-NS packets - whether a dynamic neighbor (MAC
+ This option controls the behavior when handling IPv4 ARP re‐
+ quests or IPv6 ND-NS packets - whether a dynamic neighbor (MAC
binding) entry is added/updated.
true - Always learn the MAC-IP binding, and add/update the MAC
@@ -2226,23 +2385,56 @@
options : requested-tnl-key: optional string, containing an integer, in
range 1 to 16,777,215
- Configures the datapath tunnel key for the logical router. This
- is not needed because ovn-northd will assign an unique key for
- each datapath by itself. However, if it is configured,
+ Configures the datapath tunnel key for the logical router. This
+ is not needed because ovn-northd will assign an unique key for
+ each datapath by itself. However, if it is configured,
ovn-northd honors the configured value.
- options : snat-ct-zone: optional string, containing an integer, in
+ options : snat-ct-zone: optional string, containing an integer, in
range 0 to 65,535
Use the requested conntrack zone for SNAT with this router. This
- can be useful if egress traffic from the host running OVN comes
- from both OVN and other sources. This way, OVN and the other
+ can be useful if egress traffic from the host running OVN comes
+ from both OVN and other sources. This way, OVN and the other
sources can make use of the same conntrack zone.
- options : mac_binding_age_threshold: optional string, containing an
- integer, in range 0 to 4,294,967,295
- MAC binding aging threshold value in seconds. MAC binding
- exceeding this timeout will be automatically removed. The value
- defaults to 0, which means disabled.
+ options : mac_binding_age_threshold: optional string
+ Specifies the MAC binding aging thresholds based on CIDRs, with
+ the format: entry[;entry[...]], where each entry has the format:
+ [cidr:]threshold
+
+ • cidr: Can be either an IPv4 or IPv6 CIDR.
+
+ • threshold: Threshold value in seconds. MAC bindings with
+ IP addresses matching the specified CIDR that exceed this
+ timeout will be automatically removed.
+
+ If an entry is provided without an CIDR (just the threshold
+ value), it specifies the default threshold for MAC bindings that
+ don’t match any of the given CIDRs. If there are multiple de‐
+ fault threshold entries in the option, the behavior is unde‐
+ fined.
+
+ If there are multiple CIDRs matching a MAC binding IP, the one
+ with the longest prefix length takes effect. If there are multi‐
+ ple entries with the same CIDR in the option, the behavior is
+ undefined.
+
+ If no matching CIDR is found for a MAC binding IP, and no de‐
+ fault threshold is specified, the behavior defaults to the orig‐
+ inal: the binding will not be removed based on age.
+
+ The value can also default to an empty string, which means that
+ the aging threshold is disabled. Any string not in the above
+ format is regarded as invalid and the aging is disabled.
+
+ Example: 192.168.0.0/16:300;192.168.10.0/24:0;fe80::/10:600;1200
+
+ This sets a threshold of 300 seconds for MAC bindings with IP
+ addresses in the 192.168.0.0/16 range, excluding the
+ 192.168.1.0/24 range (for which the aging is disabled), a
+ threshold of 600 seconds for MAC bindings with IP addresses in
+ the fe80::/10 IPv6 range, and a default threshold of 1200 sec‐
+ onds for all other MAC bindings.
Common Columns:
@@ -2250,22 +2442,23 @@
See External IDs at the beginning of this document.
QoS TABLE
- Each row in this table represents one QoS rule for a logical switch
- that points to it through its qos_rules column. Two types of QoS are
+ Each row in this table represents one QoS rule for a logical switch
+ that points to it through its qos_rules column. Two types of QoS are
supported: DSCP marking and metering. A match with the highest-priority
will have QoS applied to it. If the action column is specified, then
matching packets will have DSCP marking applied. If the bandwidth col‐
- umn is specified, then matching packets will have metering applied.
- action and bandwidth are not exclusive, so both marking and metering by
- defined for the same QoS entry. If no row matches, packets will not
+ umn is specified, then matching packets will have metering applied. ac‐‐
+ tion and bandwidth are not exclusive, so both marking and metering by
+ defined for the same QoS entry. If no row matches, packets will not
have any QoS applied.
Summary:
priority integer, in range 0 to 32,767
direction string, either from-lport or to-lport
match string
- action map of string-integer pairs, key must be
- dscp, value in range 0 to 63
+ action map of string-integer pairs, key either
+ dscp or mark, value in range 0 to
+ 4,294,967,295
bandwidth map of string-integer pairs, key either
burst or rate, value in range 1 to
4,294,967,295
@@ -2275,11 +2468,11 @@
priority: integer, in range 0 to 32,767
The QoS rule’s priority. Rules with numerically higher priority
take precedence over those with lower. If two QoS rules with the
- same priority both match, then the one actually applied to a
+ same priority both match, then the one actually applied to a
packet is undefined.
direction: string, either from-lport or to-lport
- The value of this field is similar to ACL column in the OVN
+ The value of this field is similar to ACL column in the OVN
Northbound database’s ACL table.
match: string
@@ -2289,36 +2482,42 @@
available in the to-lport direction (the inport is available in
both directions).
- action: map of string-integer pairs, key must be dscp, value in range 0
- to 63
- When specified, matching flows will have DSCP marking applied.
+ action: map of string-integer pairs, key either dscp or mark, value in
+ range 0 to 4,294,967,295
+ When dscp action is specified, matching flows will have have
+ DSCP marking applied. When mark action is specified, matching
+ flows will have packet marking applied.
- · dscp: The value of this action should be in the range of
+ • dscp: The value of this action should be in the range of
0 to 63 (inclusive).
+ • mark: The value of this action should be a positive inte‐
+ ger.
+
bandwidth: map of string-integer pairs, key either burst or rate, value
in range 1 to 4,294,967,295
When specified, matching packets will have bandwidth metering
applied. Traffic over the limit will be dropped.
- · rate: The value of rate limit in kbps.
+ • rate: The value of rate limit in kbps.
- · burst: The value of burst rate limit in kilobits. This is
+ • burst: The value of burst rate limit in kilobits. This is
optional and needs to specify the rate.
external_ids: map of string-string pairs
See External IDs at the beginning of this document.
Mirror TABLE
- Each row in this table represents a mirror that can be used for port
- mirroring. These mirrors are referenced by the mirror_rules column in
+ Each row in this table represents a mirror that can be used for port
+ mirroring. These mirrors are referenced by the mirror_rules column in
the Logical_Switch_Port table.
Summary:
name string (must be unique within table)
- filter string, either from-lport or to-lport
+ filter string, one of both, from-lport, or
+ to-lport
sink string
- type string, either erspan or gre
+ type string, one of erspan, gre, or local
index integer
external_ids map of string-string pairs
@@ -2326,30 +2525,35 @@
name: string (must be unique within table)
Represents the name of the mirror.
- filter: string, either from-lport or to-lport
+ filter: string, one of both, from-lport, or to-lport
The value of this field represents selection criteria of the
mirror. to-lport mirrors the packets coming into logical port.
- from-lport mirrors the packets going out of logical port.
+ from-lport mirrors the packets going out of logical port. both
+ mirrors for both directions.
sink: string
- The value of this field represents the destination/sink of the
- mirror. The value it takes is an IP address of the sink port.
+ The value of this field represents the destination/sink of the
+ mirror. If the type is gre or erspan, the value indicates the
+ tunnel remote IP (either IPv4 or IPv6). For a type of local,
+ this field defines a local interface on the OVS integration
+ bridge to be used as the mirror destination. The interface must
+ possess external-ids:mirror-id that matches this string.
- type: string, either erspan or gre
- The value of this field represents the type of the tunnel used
- for sending the mirrored packets.
+ type: string, one of erspan, gre, or local
+ The value of this field specifies the mirror type - gre, erspan
+ or local.
index: integer
The value of this field represents the tunnel ID. If the config‐
ured tunnel type is gre, this field represents the GRE key value
- and if the configured tunnel type is erspan it represents the
- erspan_idx value.
+ and if the configured tunnel type is erspan it represents the
+ erspan_idx value. It is ignored if the type is local.
external_ids: map of string-string pairs
See External IDs at the beginning of this document.
Meter TABLE
- Each row in this table represents a meter that can be used for QoS or
+ Each row in this table represents a meter that can be used for QoS or
rate-limiting.
Summary:
@@ -2363,12 +2567,12 @@
name: string (must be unique within table)
A name for this meter.
- Names that begin with "__" (two underscores) are reserved for
+ Names that begin with "__" (two underscores) are reserved for
OVN internal use and should not be added manually.
unit: string, either kbps or pktps
- The unit for rate and burst_rate parameters in the bands entry.
- kbps specifies kilobits per second, and pktps specifies packets
+ The unit for rate and burst_rate parameters in the bands entry.
+ kbps specifies kilobits per second, and pktps specifies packets
per second.
bands: set of 1 or more Meter_Bands
@@ -2380,9 +2584,9 @@
fair: optional boolean
This column is used to further describe the desired behavior of
the meter when there are multiple references to it. If this col‐
- umn is empty or is set to false, the rate will be shared across
- all rows that refer to the same Meter name. Conversely, when
- this column is set to true, each user of the same Meter will be
+ umn is empty or is set to false, the rate will be shared across
+ all rows that refer to the same Meter name. Conversely, when
+ this column is set to true, each user of the same Meter will be
rate-limited on its own.
external_ids: map of string-string pairs
@@ -2422,7 +2626,7 @@
Logical_Router_Port TABLE
A port within an L3 logical router.
- Exactly one Logical_Router row must reference a given logical router
+ Exactly one Logical_Router row must reference a given logical router
port.
Summary:
@@ -2436,7 +2640,7 @@
Options for Physical VLAN MTU Issues:
options : reside-on-redirect-chassis
optional string, either true or false
- options : redirect-type optional string, either bridged or over‐
+ options : redirect-type optional string, either bridged or over‐‐
lay
ipv6_prefix set of strings
ipv6_ra_configs:
@@ -2458,13 +2662,13 @@
Options:
options : mcast_flood optional string, either true or false
options : requested-tnl-key
- optional string, containing an integer,
+ optional string, containing an integer,
in range 1 to 32,767
options : prefix_delegation
optional string, either true or false
options : prefix optional string, either true or false
options : route_table optional string
- options : gateway_mtu optional string, containing an integer,
+ options : gateway_mtu optional string, containing an integer,
in range 68 to 65,535
options : gateway_mtu_bypass
optional string
@@ -2472,28 +2676,30 @@
peer optional string
Common Columns:
external_ids map of string-string pairs
+ Status:
+ status : hosting-chassis optional string
Details:
name: string (must be unique within table)
A name for the logical router port.
- In addition to provide convenience for human interaction with
+ In addition to provide convenience for human interaction with
the northbound database, this column is used as reference by its
patch port in Logical_Switch_Port or another logical router port
in Logical_Router_Port.
- A logical router port may not have the same name as a logical
+ A logical router port may not have the same name as a logical
switch port, but the database schema cannot enforce this.
networks: set of 1 or more strings
- The IP addresses and netmasks of the router. For example,
- 192.168.0.1/24 indicates that the router’s IP address is
- 192.168.0.1 and that packets destined to 192.168.0.x should be
+ The IP addresses and netmasks of the router. For example,
+ 192.168.0.1/24 indicates that the router’s IP address is
+ 192.168.0.1 and that packets destined to 192.168.0.x should be
routed to this port.
- A logical router port always adds a link-local IPv6 address
- (fe80::/64) automatically generated from the interface’s MAC
- address using the modified EUI-64 format.
+ A logical router port always adds a link-local IPv6 address
+ (fe80::/64) automatically generated from the interface’s MAC ad‐
+ dress using the modified EUI-64 format.
mac: string
The Ethernet address that belongs to this router port.
@@ -2514,24 +2720,24 @@
exist for historical reasons. Both of them produce the same kind of OVN
southbound records and the same behavior in practice.
- If either of these are set, this logical router port represents a dis‐
- tributed gateway port that connects this router to a logical switch
+ If either of these are set, this logical router port represents a dis‐
+ tributed gateway port that connects this router to a logical switch
with a localnet port or a connection to another OVN deployment.
Also mentioned in the OVN architecture guide, distributed gateway ports
can also be used for scalability reasons in deployments where logical
switches are dedicated to chassises rather than distributed.
- The preferred way to configure a gateway is ha_chassis_group, but gate‐
- way_chassis is also supported for backward compatibility. Only one of
- these should be set at a time on a given LRP, since they configure the
+ The preferred way to configure a gateway is ha_chassis_group, but gate‐‐
+ way_chassis is also supported for backward compatibility. Only one of
+ these should be set at a time on a given LRP, since they configure the
same features.
Even when a gateway is configured, the logical router port still effec‐
tively resides on each chassis. However, due to the implications of the
use of L2 learning in the physical network, as well as the need to sup‐
port advanced features such as one-to-many NAT (aka IP masquerading), a
- subset of the logical router processing is handled in a centralized
+ subset of the logical router processing is handled in a centralized
manner on the gateway chassis.
There can be more than one distributed gateway ports configured on each
@@ -2539,26 +2745,26 @@
ing is not yet supported on logical routers with more than one distrib‐
uted gateway ports.
- For each distributed gateway port, it may have more than one gateway
- chassises. When more than one gateway chassis is specified, OVN only
- uses one at a time. OVN can rely on OVS BFD implementation to monitor
- gateway connectivity, preferring the highest-priority gateway that is
- online. Priorities are specified in the priority column of Gate‐
+ For each distributed gateway port, it may have more than one gateway
+ chassises. When more than one gateway chassis is specified, OVN only
+ uses one at a time. OVN can rely on OVS BFD implementation to monitor
+ gateway connectivity, preferring the highest-priority gateway that is
+ online. Priorities are specified in the priority column of Gate‐‐
way_Chassis or HA_Chassis.
- ovn-northd programs the external_mac rules specified in the LRP’s LR
- into the peer logical switch’s destination lookup on the chassis where
+ ovn-northd programs the external_mac rules specified in the LRP’s LR
+ into the peer logical switch’s destination lookup on the chassis where
the logical_port resides. In addition, the logical router’s MAC address
is automatically programmed in the peer logical switch’s destination
lookup flow on the gateway chasssis. If it is desired to generate gra‐
- tuitous ARPs for NAT addresses, then set the peer LSP’s options:nat-
- addresses to router.
+ tuitous ARPs for NAT addresses, then set the peer LSP’s options:nat-ad‐‐
+ dresses to router.
- OVN 20.03 and earlier supported a third way to configure distributed
- gateway ports using options:redirect-chassis to specify the gateway
+ OVN 20.03 and earlier supported a third way to configure distributed
+ gateway ports using options:redirect-chassis to specify the gateway
chassis. This method is no longer supported. Any remaining users should
switch to one of the newer methods instead. A gateway_chassis may be
- easily configured from the command line, e.g. ovn-nbctl lrp-set-gate‐
+ easily configured from the command line, e.g. ovn-nbctl lrp-set-gate‐‐
way-chassis lrp chassis.
ha_chassis_group: optional HA_Chassis_Group
@@ -2576,52 +2782,52 @@
Physical VLAN MTU Issues in the OVN architecture document. The follow‐
ing options, which are alternatives, provide solutions. Both of them
cause packets to be sent over localnet instead of tunnels, but they
- differ in whether some or all packets are sent this way. The most prom‐
- inent tradeoff between these options is that reside-on-redirect-chassis
- is easier to configure and that redirect-type performs better for east-
- west traffic.
+ differ in whether some or all packets are sent this way. The most
+ prominent tradeoff between these options is that reside-on-redi‐‐
+ rect-chassis is easier to configure and that redirect-type performs
+ better for east-west traffic.
- options : reside-on-redirect-chassis: optional string, either true or
+ options : reside-on-redirect-chassis: optional string, either true or
false
- If set to true, this option forces all traffic across the logi‐
- cal router port to pass through the gateway chassis using a hop
+ If set to true, this option forces all traffic across the logi‐
+ cal router port to pass through the gateway chassis using a hop
across a localnet port. This changes behavior in two ways:
- · Without this option, east-west traffic passes directly
- between source and destination chassis (or even within a
- single chassis, for co-located VMs). With this option,
+ • Without this option, east-west traffic passes directly
+ between source and destination chassis (or even within a
+ single chassis, for co-located VMs). With this option,
all east-west traffic passes through the gateway chassis.
- · Without this option, traffic between the gateway chassis
- and other chassis is encapsulated in tunnels. With this
+ • Without this option, traffic between the gateway chassis
+ and other chassis is encapsulated in tunnels. With this
option, traffic passes over a localnet interface.
- This option may usefully be set only on logical router ports
- that connect a distributed logical router to a logical switch
+ This option may usefully be set only on logical router ports
+ that connect a distributed logical router to a logical switch
with VIFs. It should not be set on a distributed gateway port.
- OVN honors this option only if the logical router has one and
- only one distributed gateway port and if the LRP’s peer switch
+ OVN honors this option only if the logical router has one and
+ only one distributed gateway port and if the LRP’s peer switch
has a localnet port.
options : redirect-type: optional string, either bridged or overlay
- If set to bridged on a distributed gateway port, this option
- causes OVN to redirect packets to the gateway chassis over a
- localnet port instead of a tunnel. The relevant chassis must
- share a localnet port.
-
- This feature requires the administrator or the CMS to configure
- each participating chassis with a unique Ethernet address for
- the logical router by setting ovn-chassis-mac-mappings in the
+ If set to bridged on a distributed gateway port, this option
+ causes OVN to redirect packets to the gateway chassis over a lo‐‐
+ calnet port instead of a tunnel. The relevant chassis must share
+ a localnet port.
+
+ This feature requires the administrator or the CMS to configure
+ each participating chassis with a unique Ethernet address for
+ the logical router by setting ovn-chassis-mac-mappings in the
Open vSwitch database, for use by ovn-controller.
- Setting this option to overlay or leaving it unset has no
- effect. This option may usefully be set only on a distributed
- gateway port when there is one and only one distributed gateway
+ Setting this option to overlay or leaving it unset has no ef‐
+ fect. This option may usefully be set only on a distributed
+ gateway port when there is one and only one distributed gateway
port on the logical router. It is otherwise ignored.
ipv6_prefix: set of strings
- This column contains IPv6 prefix obtained by prefix delegation
+ This column contains IPv6 prefix obtained by prefix delegation
router according to RFC 3633
ipv6_ra_configs:
@@ -2631,30 +2837,30 @@
tion requests.
ipv6_ra_configs : address_mode: optional string
- The address mode to be used for IPv6 address configuration. The
+ The address mode to be used for IPv6 address configuration. The
supported values are:
- · slaac: Address configuration using Router Advertisement
- (RA) packet. The IPv6 prefixes defined in the Logi‐
- cal_Router_Port table’s networks column will be included
+ • slaac: Address configuration using Router Advertisement
+ (RA) packet. The IPv6 prefixes defined in the Logi‐‐
+ cal_Router_Port table’s networks column will be included
in the RA’s ICMPv6 option - Prefix information.
- · dhcpv6_stateful: Address configuration using DHCPv6.
+ • dhcpv6_stateful: Address configuration using DHCPv6.
- · dhcpv6_stateless: Address configuration using Router
- Advertisement (RA) packet. Other IPv6 options are pro‐
- vided by DHCPv6.
+ • dhcpv6_stateless: Address configuration using Router Ad‐
+ vertisement (RA) packet. Other IPv6 options are provided
+ by DHCPv6.
ipv6_ra_configs : router_preference: optional string
Default Router Preference (PRF) indicates whether to prefer this
router over other default routers (RFC 4191). Possible values
are:
- · HIGH: mapped to 0x01 in RA PRF field
+ • HIGH: mapped to 0x01 in RA PRF field
- · MEDIUM: mapped to 0x00 in RA PRF field
+ • MEDIUM: mapped to 0x00 in RA PRF field
- · LOW: mapped to 0x11 in RA PRF field
+ • LOW: mapped to 0x11 in RA PRF field
ipv6_ra_configs : route_info: optional string
Route Info is used to configure Route Info Option sent in Router
@@ -2663,41 +2869,41 @@
given route (e.g: HIGH-aef1::11/48,LOW-aef2::11/96) Possible PRF
values are:
- · HIGH: mapped to 0x01 in RA PRF field
+ • HIGH: mapped to 0x01 in RA PRF field
- · MEDIUM: mapped to 0x00 in RA PRF field
+ • MEDIUM: mapped to 0x00 in RA PRF field
- · LOW: mapped to 0x11 in RA PRF field
+ • LOW: mapped to 0x11 in RA PRF field
ipv6_ra_configs : mtu: optional string
- The recommended MTU for the link. Default is 0, which means no
- MTU Option will be included in RA packet replied by ovn-con‐
+ The recommended MTU for the link. Default is 0, which means no
+ MTU Option will be included in RA packet replied by ovn-con‐
troller. Per RFC 2460, the mtu value is recommended no less than
1280, so any mtu value less than 1280 will be considered as no
MTU Option.
ipv6_ra_configs : send_periodic: optional string
- If set to true, then this router interface will send router
- advertisements periodically. The default is false.
+ If set to true, then this router interface will send router ad‐
+ vertisements periodically. The default is false.
ipv6_ra_configs : max_interval: optional string
The maximum number of seconds to wait between sending periodic
- router advertisements. This option has no effect if ipv6_ra_con‐
+ router advertisements. This option has no effect if ipv6_ra_con‐‐
figs:send_periodic is false. The default is 600.
ipv6_ra_configs : min_interval: optional string
- The minimum number of seconds to wait between sending periodic
- router advertisements. This option has no effect if ipv6_ra_con‐
+ The minimum number of seconds to wait between sending periodic
+ router advertisements. This option has no effect if ipv6_ra_con‐‐
figs:send_periodic is false. The default is one-third of
ipv6_ra_configs:max_interval, i.e. 200 seconds if that key is
unset.
ipv6_ra_configs : rdnss: optional string
- IPv6 address of RDNSS server announced in RA packets. At the
- moment OVN supports just one RDNSS server.
+ IPv6 address of RDNSS server announced in RA packets. At the mo‐
+ ment OVN supports just one RDNSS server.
ipv6_ra_configs : dnssl: optional string
- DNS Search List announced in RA packets. Multiple DNS Search
+ DNS Search List announced in RA packets. Multiple DNS Search
List must be ’comma’ separated (e.g. "a.b.c, d.e.f")
Options:
@@ -2715,24 +2921,24 @@
options : requested-tnl-key: optional string, containing an integer, in
range 1 to 32,767
- Configures the port binding tunnel key for the port. Usually
- this is not needed because ovn-northd will assign an unique key
- for each port by itself. However, if it is configured,
+ Configures the port binding tunnel key for the port. Usually
+ this is not needed because ovn-northd will assign an unique key
+ for each port by itself. However, if it is configured,
ovn-northd honors the configured value.
options : prefix_delegation: optional string, either true or false
- If set to true, enable IPv6 prefix delegation state machine on
- this logical router port (RFC3633). IPv6 prefix delegation is
+ If set to true, enable IPv6 prefix delegation state machine on
+ this logical router port (RFC3633). IPv6 prefix delegation is
available just on a gateway router or on a gateway router port.
options : prefix: optional string, either true or false
- If set to true, this interface will receive an IPv6 prefix
- according to RFC3663
+ If set to true, this interface will receive an IPv6 prefix ac‐
+ cording to RFC3663
options : route_table: optional string
- Designates lookup Logical_Router_Static_Routes with specified
- route_table value. Routes to directly connected networks from
- same Logical Router and routes without route_table option set
+ Designates lookup Logical_Router_Static_Routes with specified
+ route_table value. Routes to directly connected networks from
+ same Logical Router and routes without route_table option set
have higher priority than routes with route_table option set.
options : gateway_mtu: optional string, containing an integer, in range
@@ -2745,25 +2951,25 @@
This allows for Path MTU Discovery.
options : gateway_mtu_bypass: optional string
- When configured, represents a match expression, in the same
- expression language used for the match column in the OVN South‐
- bound database’s Logical_Flow table. Packets matching this
- expression will bypass the length check configured through the
- options:gateway_mtu option.
+ When configured, represents a match expression, in the same ex‐
+ pression language used for the match column in the OVN South‐
+ bound database’s Logical_Flow table. Packets matching this ex‐
+ pression will bypass the length check configured through the op‐‐
+ tions:gateway_mtu option.
Attachment:
A given router port serves one of two purposes:
- · To attach a logical switch to a logical router. A logical
- router port of this type is referenced by exactly one
- Logical_Switch_Port of type router. The value of name is
- set as router-port in column options of Logi‐
+ • To attach a logical switch to a logical router. A logical
+ router port of this type is referenced by exactly one
+ Logical_Switch_Port of type router. The value of name is
+ set as router-port in column options of Logi‐‐
cal_Switch_Port. In this case peer column is empty.
- · To connect one logical router to another. This requires a
+ • To connect one logical router to another. This requires a
pair of logical router ports, each connected to a differ‐
- ent router. Each router port in the pair specifies the
+ ent router. Each router port in the pair specifies the
other in its peer column. No Logical_Switch refers to the
router port.
@@ -2779,9 +2985,22 @@
external_ids: map of string-string pairs
See External IDs at the beginning of this document.
- The ovn-northd program copies all these pairs into the exter‐
+ The ovn-northd program copies all these pairs into the exter‐‐
nal_ids column of the Port_Binding table in OVN_Southbound data‐
base.
+
+ Status:
+
+ Additional status about the logical router port.
+
+ status : hosting-chassis: optional string
+ This option is populated by ovn-northd.
+
+ When a distributed gateway port is bound to a location in the
+ OVN Southbound database Port_Binding ovn-northd will populate
+ this key with the name of the Chassis that is currently hosting
+ this port.
+
Logical_Router_Static_Route TABLE
Each record represents a static route.
@@ -2819,10 +3038,10 @@
make routing decisions. This setting must be one of the follow‐
ing strings:
- · src-ip: This policy sends the packet to the nexthop when
+ • src-ip: This policy sends the packet to the nexthop when
the packet’s source IP address matches ip_prefix.
- · dst-ip: This policy sends the packet to the nexthop when
+ • dst-ip: This policy sends the packet to the nexthop when
the packet’s destination IP address matches ip_prefix.
If not specified, the default is dst-ip.
@@ -2839,7 +3058,7 @@
will automatically figure this out based on the nexthop. When
this is specified and there are multiple IP addresses on the
router port and none of them are in the same subnet of nexthop,
- OVN chooses the first IP address as the one via which the nex‐
+ OVN chooses the first IP address as the one via which the nex‐‐
thop is reachable.
bfd: optional weak reference to BFD
@@ -2848,21 +3067,21 @@
route_table: string
Any string to place route to separate routing table. If Logical
Router Port has configured value in options:route_table other
- than empty string, OVN performs route lookup for all packets
- entering Logical Router ingress pipeline from this port in the
+ than empty string, OVN performs route lookup for all packets en‐
+ tering Logical Router ingress pipeline from this port in the
following manner:
- · 1. First lookup among "global" routes: routes without
- route_table value set and routes to directly connected
+ • 1. First lookup among "global" routes: routes without
+ route_table value set and routes to directly connected
networks.
- · 2. Next lookup among routes with same route_table value
+ • 2. Next lookup among routes with same route_table value
as specified in LRP’s options:route_table field.
external_ids : ic-learned-route: optional string
- ovn-ic populates this key if the route is learned from the
- global OVN_IC_Southbound database. In this case the value will
- be set to the uuid of the row in Route table of the
+ ovn-ic populates this key if the route is learned from the
+ global OVN_IC_Southbound database. In this case the value will
+ be set to the uuid of the row in Route table of the
OVN_IC_Southbound database.
Common Columns:
@@ -2873,7 +3092,7 @@
Common options:
options: map of string-string pairs
- This column provides general key/value settings. The supported
+ This column provides general key/value settings. The supported
options are described individually below.
options : ecmp_symmetric_reply: optional string
@@ -2888,7 +3107,7 @@
In case ovn-interconnection has been learned this route, it will
have its origin set: either "connected" or "static". This key is
supposed to be written only by ovn-ic daemon. ovn-northd then
- checks this value when generating Logical Flows. Logi‐
+ checks this value when generating Logical Flows. Logi‐‐
cal_Router_Static_Route records with same ip_prefix within same
Logical Router will have next lookup order based on origin key
value:
@@ -2896,13 +3115,12 @@
1. connected
2. static
-
Logical_Router_Policy TABLE
Each row in this table represents one routing policy for a logical
router that points to it through its policies column. The action column
- for the highest-priority matching row in this table determines a
- packet’s treatment. If no row matches, packets are allowed by default.
- (Default-deny treatment is possible: add a rule with priority 0, 1 as
+ for the highest-priority matching row in this table determines a
+ packet’s treatment. If no row matches, packets are allowed by default.
+ (Default-deny treatment is possible: add a rule with priority 0, 1 as
match, and drop as action.)
Summary:
@@ -2911,53 +3129,58 @@
action string, one of allow, drop, or reroute
nexthop optional string
nexthops set of strings
+ bfd_sessions set of weak reference to BFDs
options : pkt_mark optional string
Common Columns:
external_ids map of string-string pairs
Details:
priority: integer, in range 0 to 32,767
- The routing policy’s priority. Rules with numerically higher
- priority take precedence over those with lower. A rule is
+ The routing policy’s priority. Rules with numerically higher
+ priority take precedence over those with lower. A rule is
uniquely identified by the priority and match string.
match: string
- The packets that the routing policy should match, in the same
- expression language used for the match column in the OVN South‐
+ The packets that the routing policy should match, in the same
+ expression language used for the match column in the OVN South‐
bound database’s Logical_Flow table.
- By default all traffic is allowed. When writing a more restric‐
- tive policy, it is important to remember to allow flows such as
+ By default all traffic is allowed. When writing a more restric‐
+ tive policy, it is important to remember to allow flows such as
ARP and IPv6 neighbor discovery packets.
action: string, one of allow, drop, or reroute
The action to take when the routing policy matches:
- · allow: Forward the packet.
+ • allow: Forward the packet.
- · drop: Silently drop the packet.
+ • drop: Silently drop the packet.
- · reroute: Reroute packet to nexthop or nexthops.
+ • reroute: Reroute packet to nexthop or nexthops.
nexthop: optional string
Note: This column is deprecated in favor of nexthops.
- Next-hop IP address for this route, which should be the IP
- address of a connected router port or the IP address of a logi‐
- cal port.
+ Next-hop IP address for this route, which should be the IP ad‐
+ dress of a connected router port or the IP address of a logical
+ port.
nexthops: set of strings
- Next-hop ECMP IP addresses for this route. Each IP in the list
- should be the IP address of a connected router port or the IP
+ Next-hop ECMP IP addresses for this route. Each IP in the list
+ should be the IP address of a connected router port or the IP
address of a logical port.
One IP from the list is selected as next hop.
+ bfd_sessions: set of weak reference to BFDs
+ Reference to BFD row if the route policy has associated some BFD
+ sessions.
+
options : pkt_mark: optional string
Marks the packet with the value specified when the router policy
- is applied. CMS can inspect this packet marker and take some
- decisions if desired. This value is not preserved when the
- packet goes out on the wire.
+ is applied. CMS can inspect this packet marker and take some de‐
+ cisions if desired. This value is not preserved when the packet
+ goes out on the wire.
Common Columns:
@@ -2968,7 +3191,7 @@
Each record represents a NAT rule.
Summary:
- type string, one of dnat, dnat_and_snat, or
+ type string, one of dnat, dnat_and_snat, or
snat
external_ip string
external_mac optional string
@@ -2977,7 +3200,7 @@
logical_port optional string
allowed_ext_ips optional Address_Set
exempted_ext_ips optional Address_Set
- gateway_port optional weak reference to Logi‐
+ gateway_port optional weak reference to Logi‐‐
cal_Router_Port
options : stateless optional string
options : add_route optional string
@@ -2988,20 +3211,20 @@
type: string, one of dnat, dnat_and_snat, or snat
Type of the NAT rule.
- · When type is dnat, the externally visible IP address
- external_ip is DNATted to the IP address logical_ip in
- the logical space.
+ • When type is dnat, the externally visible IP address ex‐‐
+ ternal_ip is DNATted to the IP address logical_ip in the
+ logical space.
- · When type is snat, IP packets with their source IP
- address that either matches the IP address in logical_ip
- or is in the network provided by logical_ip is SNATed
- into the IP address in external_ip.
+ • When type is snat, IP packets with their source IP ad‐
+ dress that either matches the IP address in logical_ip or
+ is in the network provided by logical_ip is SNATed into
+ the IP address in external_ip.
- · When type is dnat_and_snat, the externally visible IP
- address external_ip is DNATted to the IP address logi‐
- cal_ip in the logical space. In addition, IP packets with
- the source IP address that matches logical_ip is SNATed
- into the IP address in external_ip.
+ • When type is dnat_and_snat, the externally visible IP ad‐
+ dress external_ip is DNATted to the IP address logical_ip
+ in the logical space. In addition, IP packets with the
+ source IP address that matches logical_ip is SNATed into
+ the IP address in external_ip.
external_ip: string
An IPv4 address.
@@ -3013,11 +3236,11 @@
This must be specified in order for the NAT rule to be processed
in a distributed manner on all chassis. If this is not specified
for a NAT rule on a distributed router, then this NAT rule will
- be processed in a centralized manner on the gateway port
- instance on the gateway chassis.
+ be processed in a centralized manner on the gateway port in‐
+ stance on the gateway chassis.
This MAC address must be unique on the logical switch that the
- gateway port is attached to. If the MAC address used on the log‐
+ gateway port is attached to. If the MAC address used on the log‐‐
ical_port is globally unique, then that MAC address can be spec‐
ified as this external_mac.
@@ -3025,8 +3248,8 @@
L4 source port range
Range of ports, from which a port number will be picked that
- will replace the source port of to be NATed packet. This is
- basically PAT (port address translation).
+ will replace the source port of to be NATed packet. This is ba‐
+ sically PAT (port address translation).
Value of the column is in the format, port_lo-port_hi. For exam‐
ple: external_port_range : "1-30000"
@@ -3042,15 +3265,15 @@
This is only used on distributed routers. This must be specified
in order for the NAT rule to be processed in a distributed man‐
ner on all chassis. If this is not specified for a NAT rule on a
- distributed router, then this NAT rule will be processed in a
- centralized manner on the gateway port instance on the gateway
+ distributed router, then this NAT rule will be processed in a
+ centralized manner on the gateway port instance on the gateway
chassis.
allowed_ext_ips: optional Address_Set
- It represents Address Set of external ips that NAT rule is
- applicable to. For SNAT type NAT rules, this refers to destina‐
- tion addresses. For DNAT type NAT rules, this refers to source
- addresses.
+ It represents Address Set of external ips that NAT rule is ap‐
+ plicable to. For SNAT type NAT rules, this refers to destination
+ addresses. For DNAT type NAT rules, this refers to source ad‐
+ dresses.
This configuration overrides the default NAT behavior of apply‐
ing a rule solely based on internal IP. Without this configura‐
@@ -3081,49 +3304,48 @@
with RULE2, then a logical ip which matches both 50.0.0.0/24 and
50.0.0.0/25 may get the RULE2 applied to it instead of RULE1.
- allowed_ext_ips and exempted_ext_ips are mutually exclusive to
- each other. If both Address Sets are set for a rule, then the
+ allowed_ext_ips and exempted_ext_ips are mutually exclusive to
+ each other. If both Address Sets are set for a rule, then the
NAT rule is not considered.
gateway_port: optional weak reference to Logical_Router_Port
- A distributed gateway port in the Logical_Router_Port table
+ A distributed gateway port in the Logical_Router_Port table
where the NAT rule needs to be applied.
- When multiple distributed gateway ports are configured on a Log‐
+ When multiple distributed gateway ports are configured on a Log‐‐
ical_Router, applying a NAT rule at each of the distributed
gateway ports might not be desired. Consider the case where a
logical router has 2 distributed gateway port, one with networks
- 50.0.0.10/24 and the other with networks 60.0.0.10/24. If the
- logical router has a NAT rule of type snat, logical_ip
- 10.1.1.0/24 and external_ip 50.1.1.20/24, the rule needs to be
+ 50.0.0.10/24 and the other with networks 60.0.0.10/24. If the
+ logical router has a NAT rule of type snat, logical_ip
+ 10.1.1.0/24 and external_ip 50.1.1.20/24, the rule needs to be
selectively applied on matching packets entering/leaving through
the distributed gateway port with networks 50.0.0.10/24.
When a logical router has multiple distributed gateway ports and
- this column is not set for a NAT rule, then the rule will be
- applied at the distributed gateway port which is in the same
- network as the external_ip of the NAT rule, if such a router
- port exists. If logical router has a single distributed gateway
- port and this column is not set for a NAT rule, the rule will be
- applied at the distributed gateway port even if the router port
- is not in the same network as the external_ip of the NAT rule.
+ this column is not set for a NAT rule, then the rule will be ap‐
+ plied at the distributed gateway port which is in the same net‐
+ work as the external_ip of the NAT rule, if such a router port
+ exists. If logical router has a single distributed gateway port
+ and this column is not set for a NAT rule, the rule will be ap‐
+ plied at the distributed gateway port even if the router port is
+ not in the same network as the external_ip of the NAT rule.
options : stateless: optional string
- Indicates if a dnat_and_snat rule should lead to connection
+ Indicates if a dnat_and_snat rule should lead to connection
tracking state or not.
options : add_route: optional string
- If set to true, then neighbor routers will have logical flows
- added that will allow for routing to the NAT address. It also
- will have ARP resolution logical flows added. By setting this
- option, it means there is no reason to create a Logi‐
- cal_Router_Static_Route from neighbor routers to this NAT
- address. It also means that no ARP request is required for
- neighbor routers to learn the IP-MAC mapping for this NAT
- address. This option only applies to NATs of type dnat and
- dnat_and_snat. For more information about what flows are added
- for IP routes, please see the ovn-northd manpage section on IP
- Routing.
+ If set to true, then neighbor routers will have logical flows
+ added that will allow for routing to the NAT address. It also
+ will have ARP resolution logical flows added. By setting this
+ option, it means there is no reason to create a Logi‐‐
+ cal_Router_Static_Route from neighbor routers to this NAT ad‐
+ dress. It also means that no ARP request is required for neigh‐
+ bor routers to learn the IP-MAC mapping for this NAT address.
+ This option only applies to NATs of type dnat and dnat_and_snat.
+ For more information about what flows are added for IP routes,
+ please see the ovn-northd manpage section on IP Routing.
Common Columns:
@@ -3131,14 +3353,13 @@
See External IDs at the beginning of this document.
DHCP_Options TABLE
- OVN implements native DHCPv4 support which caters to the common use
- case of providing an IPv4 address to a booting instance by providing
- stateless replies to DHCPv4 requests based on statically configured
- address mappings. To do this it allows a short list of DHCPv4 options
- to be configured and applied at each compute host running ovn-con‐
- troller.
-
- OVN also implements native DHCPv6 support which provides stateless
+ OVN implements native DHCPv4 support which caters to the common use
+ case of providing an IPv4 address to a booting instance by providing
+ stateless replies to DHCPv4 requests based on statically configured ad‐
+ dress mappings. To do this it allows a short list of DHCPv4 options to
+ be configured and applied at each compute host running ovn-controller.
+
+ OVN also implements native DHCPv6 support which provides stateless
replies to DHCPv6 requests.
Summary:
@@ -3147,7 +3368,7 @@
Mandatory DHCPv4 options:
options : server_id optional string
options : server_mac optional string
- options : lease_time optional string, containing an integer,
+ options : lease_time optional string, containing an integer,
in range 0 to 4,294,967,295
IPv4 DHCP Options:
options : router optional string
@@ -3175,24 +3396,24 @@
optional string, either 0 or 1
options : ethernet_encap optional string, either 0 or 1
Integer DHCP Options:
- options : default_ttl optional string, containing an integer,
+ options : default_ttl optional string, containing an integer,
in range 0 to 255
- options : tcp_ttl optional string, containing an integer,
+ options : tcp_ttl optional string, containing an integer,
in range 0 to 255
- options : mtu optional string, containing an integer,
+ options : mtu optional string, containing an integer,
in range 68 to 65,535
- options : T1 optional string, containing an integer,
+ options : T1 optional string, containing an integer,
in range 68 to 4,294,967,295
- options : T2 optional string, containing an integer,
+ options : T2 optional string, containing an integer,
in range 68 to 4,294,967,295
options : arp_cache_timeout
- optional string, containing an integer,
+ optional string, containing an integer,
in range 0 to 255
options : tcp_keepalive_interval
- optional string, containing an integer,
+ optional string, containing an integer,
in range 0 to 255
options : netbios_node_type
- optional string, containing an integer,
+ optional string, containing an integer,
in range 0 to 255
String DHCP Options:
options : wpad optional string
@@ -3220,19 +3441,20 @@
options : domain_search optional string
options : dhcpv6_stateless
optional string
+ options : fqdn optional string
Common Columns:
external_ids map of string-string pairs
Details:
cidr: string
- The DHCPv4/DHCPv6 options will be included if the logical port
+ The DHCPv4/DHCPv6 options will be included if the logical port
has its IP address in this cidr.
DHCPv4 options:
- The CMS should define the set of DHCPv4 options as key/value pairs in
- the options column of this table. For ovn-controller to include these
- DHCPv4 options, the dhcpv4_options of Logical_Switch_Port should refer
+ The CMS should define the set of DHCPv4 options as key/value pairs in
+ the options column of this table. For ovn-controller to include these
+ DHCPv4 options, the dhcpv4_options of Logical_Switch_Port should refer
to an entry in this table.
Mandatory DHCPv4 options:
@@ -3241,13 +3463,13 @@
options : server_id: optional string
The IP address for the DHCP server to use. This should be in the
- subnet of the offered IP. This is also included in the DHCP
- offer as option 54, ``server identifier.’’
+ subnet of the offered IP. This is also included in the DHCP of‐
+ fer as option 54, ``server identifier.’’
options : server_mac: optional string
The Ethernet address for the DHCP server to use.
- options : lease_time: optional string, containing an integer, in range
+ options : lease_time: optional string, containing an integer, in range
0 to 4,294,967,295
The offered lease time in seconds,
@@ -3255,14 +3477,14 @@
IPv4 DHCP Options:
- Below are the supported DHCPv4 options whose values are an IPv4
- address, e.g. 192.168.1.1. Some options accept multiple IPv4 addresses
- enclosed within curly braces, e.g. {192.168.1.2, 192.168.1.3}. Please
+ Below are the supported DHCPv4 options whose values are an IPv4 ad‐
+ dress, e.g. 192.168.1.1. Some options accept multiple IPv4 addresses
+ enclosed within curly braces, e.g. {192.168.1.2, 192.168.1.3}. Please
refer to RFC 2132 for more details on DHCPv4 options and their codes.
options : router: optional string
- The IP address of a gateway for the client to use. This should
- be in the subnet of the offered IP. The DHCPv4 option code for
+ The IP address of a gateway for the client to use. This should
+ be in the subnet of the offered IP. The DHCPv4 option code for
this option is 3.
options : netmask: optional string
@@ -3306,7 +3528,7 @@
Example: {30.0.0.0/24,10.0.0.10, 0.0.0.0/0,10.0.0.1}
options : ms_classless_static_route: optional string
- The DHCPv4 option code for this option is 249. This option is
+ The DHCPv4 option code for this option is 249. This option is
similar to classless_static_route supported by Microsoft Windows
DHCPv4 clients.
@@ -3336,32 +3558,32 @@
0 to 255
The DHCPv4 option code for this option is 23.
- options : tcp_ttl: optional string, containing an integer, in range 0
+ options : tcp_ttl: optional string, containing an integer, in range 0
to 255
The DHCPv4 option code for this option is 37.
- options : mtu: optional string, containing an integer, in range 68 to
+ options : mtu: optional string, containing an integer, in range 68 to
65,535
The DHCPv4 option code for this option is 26.
- options : T1: optional string, containing an integer, in range 68 to
+ options : T1: optional string, containing an integer, in range 68 to
4,294,967,295
- This specifies the time interval from address assignment until
+ This specifies the time interval from address assignment until
the client begins trying to renew its address. The DHCPv4 option
code for this option is 58.
- options : T2: optional string, containing an integer, in range 68 to
+ options : T2: optional string, containing an integer, in range 68 to
4,294,967,295
- This specifies the time interval from address assignment until
- the client begins trying to rebind its address. The DHCPv4
- option code for this option is 59.
+ This specifies the time interval from address assignment until
+ the client begins trying to rebind its address. The DHCPv4 op‐
+ tion code for this option is 59.
options : arp_cache_timeout: optional string, containing an integer, in
range 0 to 255
The DHCPv4 option code for this option is 35. This option speci‐
fies the timeout in seconds for ARP cache entries.
- options : tcp_keepalive_interval: optional string, containing an inte‐
+ options : tcp_keepalive_interval: optional string, containing an inte‐
ger, in range 0 to 255
The DHCPv4 option code for this option is 38. This option speci‐
fies the interval that the client TCP should wait before sending
@@ -3376,18 +3598,18 @@
These options accept a string value.
options : wpad: optional string
- The DHCPv4 option code for this option is 252. This option is
- used as part of web proxy auto discovery to provide a URL for a
+ The DHCPv4 option code for this option is 252. This option is
+ used as part of web proxy auto discovery to provide a URL for a
web proxy.
options : bootfile_name: optional string
- The DHCPv4 option code for this option is 67. This option is
+ The DHCPv4 option code for this option is 67. This option is
used to identify a bootfile.
options : path_prefix: optional string
The DHCPv4 option code for this option is 210. In PXELINUX’ case
- this option is used to set a common path prefix, instead of
- deriving it from the bootfile name.
+ this option is used to set a common path prefix, instead of de‐
+ riving it from the bootfile name.
options : tftp_server_address: optional string
The DHCPv4 option code for this option is 150. The option con‐
@@ -3396,11 +3618,11 @@
this requirement is option 66 (tftp_server).
options : hostname: optional string
- The DHCPv4 option code for this option is 12. If set, indicates
- the DHCPv4 option "Hostname". Alternatively, this option can be
- configured in options:hostname column in table Logi‐
- cal_Switch_Port. If Hostname option value is set in both con‐
- flicting Logical_Switch_Port and DHCP_Options tables, Logi‐
+ The DHCPv4 option code for this option is 12. If set, indicates
+ the DHCPv4 option "Hostname". Alternatively, this option can be
+ configured in options:hostname column in table Logi‐‐
+ cal_Switch_Port. If Hostname option value is set in both con‐
+ flicting Logical_Switch_Port and DHCP_Options tables, Logi‐‐
cal_Switch_Port takes precedence.
options : domain_name: optional string
@@ -3409,7 +3631,7 @@
names via the Domain Name System.
options : bootfile_name_alt: optional string
- "bootfile_name_alt" option is used to support iPXE. When both
+ "bootfile_name_alt" option is used to support iPXE. When both
"bootfile_name" and "bootfile_name_alt" are provided by the CMS,
"bootfile_name" will be used for option 67 if the dhcp request
contains etherboot option (175), otherwise "bootfile_name_alt"
@@ -3428,7 +3650,7 @@
DHCP Options of type domains:
- These options accept string value which is a comma separated list of
+ These options accept string value which is a comma separated list of
domain names. The domain names are encoded based on RFC 1035.
options : domain_search_list: optional string
@@ -3436,28 +3658,28 @@
DHCPv6 options:
- OVN also implements native DHCPv6 support. The CMS should define the
- set of DHCPv6 options as key/value pairs. The define DHCPv6 options
- will be included in the DHCPv6 response to the DHCPv6
- Solicit/Request/Confirm packet from the logical ports having the IPv6
- addresses in the cidr.
+ OVN also implements native DHCPv6 support. The CMS should define the
+ set of DHCPv6 options as key/value pairs. The define DHCPv6 options
+ will be included in the DHCPv6 response to the DHCPv6 Solicit/Re‐
+ quest/Confirm packet from the logical ports having the IPv6 addresses
+ in the cidr.
Mandatory DHCPv6 options:
The following options must be defined.
options : server_id: optional string
- The Ethernet address for the DHCP server to use. This is also
- included in the DHCPv6 reply as option 2, ``Server Identifier’’
- to carry a DUID identifying a server between a client and a
- server. ovn-controller defines DUID based on Link-layer Address
+ The Ethernet address for the DHCP server to use. This is also
+ included in the DHCPv6 reply as option 2, ``Server Identifier’’
+ to carry a DUID identifying a server between a client and a
+ server. ovn-controller defines DUID based on Link-layer Address
[DUID-LL].
IPv6 DHCPv6 options:
- Below are the supported DHCPv6 options whose values are an IPv6
- address, e.g. aef0::4. Some options accept multiple IPv6 addresses
- enclosed within curly braces, e.g. {aef0::4, aef0::5}. Please refer to
+ Below are the supported DHCPv6 options whose values are an IPv6 ad‐
+ dress, e.g. aef0::4. Some options accept multiple IPv6 addresses en‐
+ closed within curly braces, e.g. {aef0::4, aef0::5}. Please refer to
RFC 3315 for more details on DHCPv6 options and their codes.
options : dns_server: optional string
@@ -3470,33 +3692,37 @@
options : domain_search: optional string
The DHCPv6 option code for this option is 24. This option speci‐
- fies the domain search list the client should use to resolve
+ fies the domain search list the client should use to resolve
hostnames with DNS.
Example: "ovn.org".
options : dhcpv6_stateless: optional string
- This option specifies the OVN native DHCPv6 will work in state‐
- less mode, which means OVN native DHCPv6 will not offer IPv6
- addresses for VM/VIF ports, but only reply other configurations,
+ This option specifies the OVN native DHCPv6 will work in state‐
+ less mode, which means OVN native DHCPv6 will not offer IPv6 ad‐
+ dresses for VM/VIF ports, but only reply other configurations,
such as DNS and domain search list. When setting this option
with string value "true", VM/VIF will configure IPv6 addresses
by stateless way. Default value for this option is false.
+ options : fqdn: optional string
+ The DHCPv6 option code for this option is 39. If set, indicates
+ the DHCPv6 option "FQDN".
+
Common Columns:
external_ids: map of string-string pairs
See External IDs at the beginning of this document.
Connection TABLE
- Configuration for a database connection to an Open vSwitch database
+ Configuration for a database connection to an Open vSwitch database
(OVSDB) client.
- This table primarily configures the Open vSwitch database server
+ This table primarily configures the Open vSwitch database server
(ovsdb-server).
- The Open vSwitch database server can initiate and maintain active con‐
- nections to remote clients. It can also listen for database connec‐
+ The Open vSwitch database server can initiate and maintain active con‐
+ nections to remote clients. It can also listen for database connec‐
tions.
Summary:
@@ -3508,17 +3734,17 @@
Status:
is_connected boolean
status : last_error optional string
- status : state optional string, one of ACTIVE, BACKOFF,
+ status : state optional string, one of ACTIVE, BACKOFF,
CONNECTING, IDLE, or VOID
- status : sec_since_connect optional string, containing an integer,
+ status : sec_since_connect optional string, containing an integer,
at least 0
status : sec_since_disconnect
- optional string, containing an integer,
+ 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,
+ status : n_connections optional string, containing an integer,
at least 2
status : bound_port optional string, containing an integer
Common Columns:
@@ -3534,9 +3760,9 @@
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
+ The specified SSL port on the host at the given host,
+ which can either be a DNS name (if built with unbound li‐
+ brary) 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 ta‐
ble.
@@ -3548,9 +3774,9 @@
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.
+ which can either be a DNS name (if built with unbound li‐
+ brary) 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.
@@ -3558,8 +3784,8 @@
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
+ DNS name (if built with unbound library) or an IP ad‐
+ dress, 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
@@ -3576,13 +3802,13 @@
ptcp:[port][:host]
Listens for connections on the specified TCP port. Spec‐
ify 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.
+ 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 re‐
+ solved 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.
@@ -3592,17 +3818,17 @@
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.
+ Maximum number of milliseconds to wait between connection at‐
+ tempts. 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 recon‐
- nect. Default is implementation-specific. A value of 0 disables
+ 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 recon‐
+ nect. Default is implementation-specific. A value of 0 disables
inactivity probes.
Status:
@@ -3611,12 +3837,12 @@
in the status columns may be updated depends on the target type.
When target specifies a connection method that listens for inbound con‐
- nections (e.g. ptcp: or punix:), both n_connections and is_connected
+ nections (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 omit‐
+ 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 omit‐
ted.
is_connected: boolean
@@ -3627,7 +3853,7 @@
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,
+ status : state: optional string, one of ACTIVE, BACKOFF, CONNECTING,
IDLE, or VOID
The state of the connection to the manager:
@@ -3643,78 +3869,88 @@
IDLE Connection is idle. Waiting for response to keep-alive.
- These values may change in the future. They are provided only
+ These values may change in the future. They are provided only
for human consumption.
- status : sec_since_connect: optional string, containing an integer, at
+ 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,
+ 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 dis‐
+ The amount of time since this client last disconnected from the
+ database (in seconds). Value is empty if client has never dis‐
connected.
status : locks_held: optional string
- Space-separated list of the names of OVSDB locks that the con‐
- nection holds. Omitted if the connection does not hold any
+ Space-separated list of the names of OVSDB locks that the con‐
+ nection 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 con‐
- nection is currently waiting to acquire. Omitted if the connec‐
+ Space-separated list of the names of OVSDB locks that the con‐
+ nection is currently waiting to acquire. Omitted if the connec‐
tion is not waiting for any locks.
status : locks_lost: optional string
- Space-separated list of the names of OVSDB locks that the con‐
- nection has had stolen by another OVSDB client. Omitted if no
+ Space-separated list of the names of OVSDB locks that the con‐
+ nection 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
+ 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 con‐
+ When target specifies a connection method that listens for in‐
+ bound connections (e.g. ptcp: or pssl:) and more than one con‐
nection 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
+ 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
+ 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
-
DNS TABLE
- Each row in this table stores the DNS records. The Logical_Switch ta‐
+ Each row in this table stores the DNS records. The Logical_Switch ta‐
ble’s dns_records references these records.
Summary:
records map of string-string pairs
+ options : ovn-owned optional string
external_ids map of string-string pairs
Details:
records: map of string-string pairs
Key-value pair of DNS records with DNS query name as the key and
value as a string of IP address(es) separated by comma or space.
- For PTR requests, the key-value pair can be Reverse IPv4
- address.in-addr.arpa and the value DNS domain name. For IPv6
- addresses, the key has to be Reverse IPv6 address.ip6.arpa.
+ For PTR requests, the key-value pair can be Reverse IPv4 ad‐‐
+ dress.in-addr.arpa and the value DNS domain name. For IPv6 ad‐
+ dresses, the key has to be Reverse IPv6 address.ip6.arpa.
Example: "vm1.ovn.org" = "10.0.0.4 aef0::4"
Example: "4.0.0.10.in-addr.arpa" = "vm1.ovn.org"
+ options : ovn-owned: optional string
+ If set to true, then the OVN will be the main responsible for
+ DNS Records within this row.
+
+ A DNS row with this option set to true can be created for do‐
+ mains that the user needs to configure locally and don’t care
+ about IPv6 only interested in IPv4 or vice versa. This will let
+ ovn send IPv4 DNS reply and reject/ignore IPv6 queries to save
+ the waiting for a timeout on those uninteresting queries.
+
external_ids: map of string-string pairs
See External IDs at the beginning of this document.
@@ -3739,27 +3975,27 @@
certificate: string
Name of a PEM file containing a certificate, signed by the cer‐
tificate authority (CA) used by the controller and manager, that
- certifies the switch’s private key, identifying a trustworthy
+ 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
+ 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 bootstrap‐
+ 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 im‐
+ mediately 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 bootstrap‐
ping.
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.
+ List of SSL protocols to be enabled for SSL connections. The de‐
+ fault when this option is omitted is TLSv1,TLSv1.1,TLSv1.2.
ssl_ciphers: string
List of ciphers (in OpenSSL cipher string format) to be sup‐
@@ -3772,7 +4008,6 @@
at the beginning of this document.
external_ids: map of string-string pairs
-
Gateway_Chassis TABLE
Association of a chassis to a logical router port. The traffic going
out through an specific router port will be redirected to a chassis, or
@@ -3799,8 +4034,8 @@
name column of the Chassis table in the OVN_Southbound database.
priority: integer, in range 0 to 32,767
- This is the priority of a chassis among all Gateway_Chassis
- belonging to the same logical router port.
+ This is the priority of a chassis among all Gateway_Chassis be‐
+ longing to the same logical router port.
options: map of string-string pairs
Reserved for future use.
@@ -3812,11 +4047,11 @@
HA_Chassis_Group TABLE
Table representing a group of chassis which can provide high availabil‐
- ity services. Each chassis in the group is represented by the table
- HA_Chassis. The HA chassis with highest priority will be the master of
- this group. If the master chassis failover is detected, the HA chassis
- with the next higher priority takes over the responsibility of provid‐
- ing the HA. If a distributed gateway router port references a row in
+ ity services. Each chassis in the group is represented by the table
+ HA_Chassis. The HA chassis with highest priority will be the master of
+ this group. If the master chassis failover is detected, the HA chassis
+ with the next higher priority takes over the responsibility of provid‐
+ ing the HA. If a distributed gateway router port references a row in
this table, then the master HA chassis in this group provides the gate‐
way functionality.
@@ -3862,12 +4097,12 @@
BFD TABLE
Contains BFD parameter for ovn-controller BFD configuration. OVN BFD
- implementation is used to provide detection of failures in the path
- between adjacent forwarding engines, including the OVN interfaces. OVN
- BFD provides link status info to OVN northd in order to update logical
- flows according to the status of BFD endpoints. In the current imple‐
- mentation OVN BFD is used to check next-hop status for ECMP routes.
- Please note BFD table refers to OVN BFD implementation and not to OVS
+ implementation is used to provide detection of failures in the path be‐
+ tween adjacent forwarding engines, including the OVN interfaces. OVN
+ BFD provides link status info to OVN northd in order to update logical
+ flows according to the status of BFD endpoints. In the current imple‐
+ mentation OVN BFD is used to check next-hop status for ECMP routes.
+ Please note BFD table refers to OVN BFD implementation and not to OVS
legacy one.
Summary:
@@ -3925,14 +4160,13 @@
status: optional string, one of admin_down, down, init, or up
BFD port logical states. Possible values are:
- · admin_down
-
- · down
+ • admin_down
- · init
+ • down
- · up
+ • init
+ • up
Static_MAC_Binding TABLE
Each record represents a Static_MAC_Binding entry for a logical router.
@@ -3965,16 +4199,16 @@
One record per chassis, each containing a map, variables, between tem‐
plate variable names and their value for that specific chassis. A tem‐
plate variable has a name and potentially different values on different
- hypervisors in the OVN cluster. For example, two rows, R1 = (.chas‐
- sis=C1, variables={(N: V1)} and R2 = (.chassis=C2, variables={(N: V2)}
- will make ovn-controller running on chassis C1 and C2 interpret the
- token N either as V1 (on C1) or as V2 (on C2). Users can refer to tem‐
+ hypervisors in the OVN cluster. For example, two rows, R1 = (.chas‐‐
+ sis=C1, variables={(N: V1)} and R2 = (.chassis=C2, variables={(N: V2)}
+ will make ovn-controller running on chassis C1 and C2 interpret the to‐
+ ken N either as V1 (on C1) or as V2 (on C2). Users can refer to tem‐
plate variables from within other logical components, e.g., within ACL,
- QoS or Logical_Router_Policy matches or from Load_Balancer VIP and
+ QoS or Logical_Router_Policy matches or from Load_Balancer VIP and
backend definitions.
- If a template variable is referenced on a chassis for which that vari‐
- able is not defined then ovn-controller running on that chassis will
+ If a template variable is referenced on a chassis for which that vari‐
+ able is not defined then ovn-controller running on that chassis will
just interpret it as a raw string literal.
Summary:
@@ -3995,7 +4229,5 @@
external_ids: map of string-string pairs
See External IDs at the beginning of this document.
-
-
-Open vSwitch 22.12.90 DB Schema 7.0.0 ovn-nb(5)
+Open vSwitch 24.03.90 DB Schema 7.3.0 ovn-nb(5)
diff --git a/src/static/support/dist-docs/ovn-nb.5.pdf b/src/static/support/dist-docs/ovn-nb.5.pdf
index 12794cec..c1550683 100644
Binary files a/src/static/support/dist-docs/ovn-nb.5.pdf and b/src/static/support/dist-docs/ovn-nb.5.pdf differ
diff --git a/src/static/support/dist-docs/ovn-nb.5.txt b/src/static/support/dist-docs/ovn-nb.5.txt
index 5051d81e..85fd1e6e 100644
--- a/src/static/support/dist-docs/ovn-nb.5.txt
+++ b/src/static/support/dist-docs/ovn-nb.5.txt
@@ -1,33 +1,31 @@
ovn-nb(5) Open vSwitch Manual ovn-nb(5)
-
-
NAME
ovn-nb - OVN_Northbound database schema
This database is the interface between OVN and the cloud management
- system (CMS), such as OpenStack, running above it. The CMS produces
- almost all of the contents of the database. The ovn-northd program mon‐
- itors the database contents, transforms it, and stores it into the
+ system (CMS), such as OpenStack, running above it. The CMS produces al‐
+ most all of the contents of the database. The ovn-northd program moni‐
+ tors the database contents, transforms it, and stores it into the
OVN_Southbound database.
- We generally speak of ``the’’ CMS, but one can imagine scenarios in
+ We generally speak of ``the’’ CMS, but one can imagine scenarios in
which multiple CMSes manage different parts of an OVN deployment.
External IDs
- Each of the tables in this database contains a special column, named
- external_ids. This column has the same form and purpose each place it
+ 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 data‐
+ 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 data‐
base.
TABLE SUMMARY
- The following list summarizes the purpose of each of the tables in the
- OVN_Northbound database. Each table is described in more detail on a
+ The following list summarizes the purpose of each of the tables in the
+ OVN_Northbound database. Each table is described in more detail on a
later page.
Table Purpose
@@ -83,8 +81,8 @@ TABLE SUMMARY
Chassis_Template_Var configuration.
NB_Global TABLE
- Northbound configuration for an OVN system. This table must have
- exactly one row.
+ Northbound configuration for an OVN system. This table must have ex‐
+ actly one row.
Summary:
Identity:
@@ -106,13 +104,24 @@ NB_Global TABLE
optional string
options : bfd-min-tx optional string
options : bfd-mult optional string
+ options : ignore_chassis_features
+ optional string
options : mac_prefix optional string
options : mac_binding_removal_limit
+ optional string, containing an integer,
+ in range 0 to 4,294,967,295
+ options : fdb_removal_limit
optional string, containing an integer,
in range 0 to 4,294,967,295
options : controller_event optional string, either true or false
options : northd_probe_interval
optional string
+ options : ic_probe_interval
+ optional string
+ options : nbctl_probe_interval
+ optional string
+ options : northd_trim_timeout
+ optional string
options : use_logical_dp_groups
optional string
options : use_parallel_build
@@ -124,6 +133,9 @@ NB_Global TABLE
optional string
options : debug_drop_collector_set
optional string
+ options : use_common_zone optional string, either true or false
+ options : northd-backoff-interval-ms
+ optional string
Options for configuring interconnection route advertisement:
options : ic-route-adv optional string
options : ic-route-learn optional string
@@ -166,16 +178,16 @@ NB_Global TABLE
To print the timestamp as a human-readable date:
- date -d "@$(ovn-nbctl get NB_Global . nb_cfg_timestamp | sed ’s/...$//’)"
+ date -d "@$(ovn-nbctl get NB_Global . nb_cfg_timestamp | sed ’s/...$//’)"
sb_cfg: integer
- Sequence number that ovn-northd sets to the value of nb_cfg
- after it finishes applying the corresponding configuration
- changes to the OVN_Southbound database.
+ Sequence number that ovn-northd sets to the value of nb_cfg af‐
+ ter it finishes applying the corresponding configuration changes
+ to the OVN_Southbound database.
sb_cfg_timestamp: integer
- The timestamp, in milliseconds since the epoch, when ovn-northd
+ The timestamp, in milliseconds since the epoch, when ovn-northd
finishes applying the corresponding configuration changes to the
OVN_Southbound database successfully.
@@ -188,10 +200,10 @@ NB_Global TABLE
This value can regress, if a chassis was removed from the system
and rejoins before catching up.
- If there are no chassis, then ovn-northd copies nb_cfg to
- hv_cfg. Thus, in this case, the (nonexistent) hypervisors are
- always considered to be caught up. This means that hypervisors
- can be "caught up" even in cases where sb_cfg would show that
+ If there are no chassis, then ovn-northd copies nb_cfg to
+ hv_cfg. Thus, in this case, the (nonexistent) hypervisors are
+ always considered to be caught up. This means that hypervisors
+ can be "caught up" even in cases where sb_cfg would show that
the southbound database is not. To detect when both the hypervi‐
sors and the southbound database are caught up, a client should
take the smaller of sb_cfg and hv_cfg.
@@ -223,46 +235,71 @@ NB_Global TABLE
mentation and not to OVN BFD one.
options : bfd-min-rx: optional string
- BFD option min-rx value to use when configuring BFD on tunnel
+ BFD option min-rx value to use when configuring BFD on tunnel
interfaces.
options : bfd-decay-min-rx: optional string
- BFD option decay-min-rx value to use when configuring BFD on
+ BFD option decay-min-rx value to use when configuring BFD on
tunnel interfaces.
options : bfd-min-tx: optional string
- BFD option min-tx value to use when configuring BFD on tunnel
+ BFD option min-tx value to use when configuring BFD on tunnel
interfaces.
options : bfd-mult: optional string
- BFD option mult value to use when configuring BFD on tunnel
- interfaces.
+ BFD option mult value to use when configuring BFD on tunnel in‐
+ terfaces.
+
+ options : ignore_chassis_features: optional string
+ When set to false, the ovn-northd will evaluate the features
+ supported by each chassis and will only activate features that
+ are universally supported by all chassis. This approach is cru‐
+ cial for maintaining backward compatibility during an upgrade
+ when the ovn-northd is updated prior to the ovn-controller. How‐
+ ever, if any chassis is poorly managed and the upgrade is unsuc‐
+ cessful, it will restrict ovn-northd from activating the new
+ features.
+
+ Alternatively, setting this option to true instructs ovn-northd
+ to bypass the support status of features on each chassis and to
+ directly implement the latest features. This approach safeguards
+ the operation of ovn-northd from being adversely affected by a
+ mismatched configuration of a chassis.
+
+ The default setting for this option is false.
options : mac_prefix: optional string
- Configure a given OUI to be used as prefix when L2 address is
+ Configure a given OUI to be used as prefix when L2 address is
dynamically assigned, e.g. 00:11:22
- options : mac_binding_removal_limit: optional string, containing an
- integer, in range 0 to 4,294,967,295
+ options : mac_binding_removal_limit: optional string, containing an in‐
+ teger, in range 0 to 4,294,967,295
MAC binding aging bulk removal limit. This limits how many rows
can expire in a single transaction. Default value is 0 which is
unlimited. When we hit the limit next batch removal is delayed
by 5 s.
+ options : fdb_removal_limit: optional string, containing an integer, in
+ range 0 to 4,294,967,295
+ FDB aging bulk removal limit. This limits how many rows can ex‐
+ pire in a single transaction. Default value is 0 which is unlim‐
+ ited. When we hit the limit next batch removal is delayed by 5
+ s.
+
options : controller_event: optional string, either true or false
- Value set by the CMS to enable/disable ovn-controller event
- reporting. Traffic into OVS can raise a ’controller’ event that
- results in a Controller_Event being written to the Con‐
+ Value set by the CMS to enable/disable ovn-controller event re‐
+ porting. Traffic into OVS can raise a ’controller’ event that
+ results in a Controller_Event being written to the Con‐
troller_Event table in SBDB. When the CMS has seen the event and
taken appropriate action, it can remove the corresponding row in
Controller_Event table. The intention is for a CMS to see the
- events and take some sort of action. Please see the Con‐
+ events and take some sort of action. Please see the Con‐
troller_Event table in SBDB. It is possible to associate a meter
to each controller event type in order to not overload the pinc‐
trl thread under heavy load. Each event type relies on a meter
with a defined name:
- · empty_lb_backends: event-elb
+ • empty_lb_backends: event-elb
options : northd_probe_interval: optional string
The inactivity probe interval of the connection to the OVN
@@ -273,13 +310,39 @@ NB_Global TABLE
If the value is nonzero, then it will be forced to a value of at
least 1000 ms.
+ options : ic_probe_interval: optional string
+ The inactivity probe interval of the connection to the OVN
+ Northbound and Southbound databases from ovn-ic, in millisec‐
+ onds. 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.
+
+ options : nbctl_probe_interval: optional string
+ The inactivity probe interval of the connection to the OVN
+ Northbound database from ovn-nbctl utility, in milliseconds. If
+ the value is zero, it disables the connection keepalive feature.
+
+ If the value is nonzero, then it will be forced to a value of at
+ least 1000 ms.
+
+ If the value is less than zero, then the default inactivity
+ probe interval for ovn-nbctl would be left intact (120000 ms).
+
+ options : northd_trim_timeout: optional string
+ When used, this configuration value specifies the time, in mil‐
+ liseconds, since the last ovn-northd active operation after
+ which memory trimming is performed. By default this is set to
+ 30000 (30 seconds).
+
options : use_logical_dp_groups: optional string
- Note: This option is deprecated, the only behavior is to always
- combine logical flows by datapath groups. Changing the value or
+ Note: This option is deprecated, the only behavior is to always
+ combine logical flows by datapath groups. Changing the value or
removing this option all toghether will have no effect.
- ovn-northd combines logical flows that differs only by logical
- datapath into a single logical flow with logical datapath group
+ ovn-northd combines logical flows that differs only by logical
+ datapath into a single logical flow with logical datapath group
attached.
options : use_parallel_build: optional string
@@ -292,13 +355,13 @@ NB_Global TABLE
The default value is false.
options : ignore_lsp_down: optional string
- If set to false, ARP/ND reply flows for logical switch ports
- will be installed only if the port is up, i.e. claimed by a
+ If set to false, ARP/ND reply flows for logical switch ports
+ will be installed only if the port is up, i.e. claimed by a
Chassis. If set to true, these flows are installed regardless of
the status of the port, which can result in a situation that ARP
- request to an IP is resolved even before the relevant VM/con‐
- tainer is running. For environments where this is not an issue,
- setting it to true can reduce the load and latency of the con‐
+ request to an IP is resolved even before the relevant VM/con‐
+ tainer is running. For environments where this is not an issue,
+ setting it to true can reduce the load and latency of the con‐
trol plane. The default value is true.
options : use_ct_inv_match: optional string
@@ -308,21 +371,21 @@ NB_Global TABLE
offloading ct_state inv flag, then the datapath flows matching
on this flag (either +inv or -inv) will not be offloaded. CMS
should consider setting use_ct_inv_match to false in such cases.
- This results in a side effect of the invalid packets getting
- delivered to the destination VIF, which otherwise would have
- been dropped by OVN.
+ This results in a side effect of the invalid packets getting de‐
+ livered to the destination VIF, which otherwise would have been
+ dropped by OVN.
options : default_acl_drop: optional string
If set to true., ovn-northd will generate a logical flow to drop
- all traffic in the ACL stages. By default this option is set to
+ all traffic in the ACL stages. By default this option is set to
false.
options : debug_drop_domain_id: optional string
If set to a 8-bit number and if debug_drop_collector_set is also
configured, ovn-northd will add a sample action to every logical
- flow that contains a ’drop’ action. The 8 most significant bits
- of the observation_domain_id field will be those specified in
- the debug_drop_domain_id. The 24 least significant bits of the
+ flow that contains a ’drop’ action. The 8 most significant bits
+ of the observation_domain_id field will be those specified in
+ the debug_drop_domain_id. The 24 least significant bits of the
observation_domain_id field will be the datapath’s key.
The observation_point_id will be set to the first 32 bits of the
@@ -330,16 +393,32 @@ NB_Global TABLE
options : debug_drop_collector_set: optional string
If set to a 32-bit number ovn-northd will add a sample action to
- every logical flow that contains a ’drop’ action. The sample
- action will have the specified collector_set_id. The value must
+ every logical flow that contains a ’drop’ action. The sample ac‐
+ tion will have the specified collector_set_id. The value must
match that of the local OVS configuration as described in
ovs-actions(7).
+ options : use_common_zone: optional string, either true or false
+ Default value is false. If set to true the SNAT and DNAT happens
+ in common zone, instead of happening in separate zones, depend‐
+ ing on the configuration. However, this option breaks traffic
+ when there is configuration of DGP + LB + SNAT on this LR. The
+ value true should be used only in case of HWOL compatibility
+ with GDP.
+
+ options : northd-backoff-interval-ms: optional string
+ Maximum interval that the northd incremental engine is delayed
+ by in milliseconds. Setting the value to nonzero delays the next
+ northd engine run by the previous run time, capped by the speci‐
+ fied value. If the value is zero the engine won’t be delayed at
+ all. The recommended period is smaller than 500 ms, beyond that
+ the latency of SB changes would be very noticeable.
+
Options for configuring interconnection route advertisement:
These options control how routes are advertised between OVN deployments
for interconnection. If enabled, ovn-ic from different OVN deployments
- exchanges routes between each other through the global OVN_IC_South‐
+ exchanges routes between each other through the global OVN_IC_South‐
bound database. Only routers with ports connected to interconnection
transit switches participate in route advertisement. For each of these
routers, there are two types of routes to be advertised:
@@ -347,13 +426,13 @@ NB_Global TABLE
Firstly, the static routes configured in the router are advertised.
Secondly, the networks configured in the logical router ports that are
- not on the transit switches are advertised. These are considered as
- directly connected subnets on the router.
+ not on the transit switches are advertised. These are considered as di‐
+ rectly connected subnets on the router.
- Link local prefixes (IPv4 169.254.0.0/16 and IPv6 FE80::/10) are never
+ Link local prefixes (IPv4 169.254.0.0/16 and IPv6 FE80::/10) are never
advertised.
- The learned routes are added to the static_routes column of the Logi‐
+ The learned routes are added to the static_routes column of the Logi‐
cal_Router table, with external_ids:ic-learned-route set to the uuid of
the row in Route table of the OVN_IC_Southbound database.
@@ -371,7 +450,7 @@ NB_Global TABLE
takes effect only when option ic-route-adv is true.
options : ic-route-learn-default: optional string
- A boolean value that enables learning default route from the
+ A boolean value that enables learning default route from the
global OVN_IC_Southbound database. Default is false. This option
takes effect only when option ic-route-learn is true.
@@ -385,7 +464,7 @@ NB_Global TABLE
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 Connec‐
+ for how these connections should be configured. See the Connec‐
tion table for more information.
ssl: optional SSL
@@ -425,6 +504,7 @@ Copp TABLE
meters : tcp-reset optional string
meters : bfd optional string
meters : reject optional string
+ meters : svc-monitor optional string
external_ids map of string-string pairs
Details:
@@ -440,37 +520,37 @@ Copp TABLE
hop (through ARP).
meters : dhcpv4-opts: optional string
- Rate limiting meter for packets that require adding DHCPv4
- options.
+ Rate limiting meter for packets that require adding DHCPv4 op‐
+ tions.
meters : dhcpv6-opts: optional string
- Rate limiting meter for packets that require adding DHCPv6
- options.
+ Rate limiting meter for packets that require adding DHCPv6 op‐
+ tions.
meters : dns: optional string
- Rate limiting meter for DNS query packets that need to be
+ Rate limiting meter for DNS query packets that need to be
replied to.
meters : event-elb: optional string
Rate limiting meter for empty load balancer events.
meters : icmp4-error: optional string
- Rate limiting meter for packets that require replying with an
+ Rate limiting meter for packets that require replying with an
ICMP error.
meters : icmp6-error: optional string
- Rate limiting meter for packets that require replying with an
+ Rate limiting meter for packets that require replying with an
ICMPv6 error.
meters : igmp: optional string
Rate limiting meter for IGMP packets.
meters : nd-na: optional string
- Rate limiting meter for ND neighbor advertisement packets used
+ Rate limiting meter for ND neighbor advertisement packets used
for learning neighbors.
meters : nd-ns: optional string
- Rate limiting meter for ND neighbor solicitation packets used
+ Rate limiting meter for ND neighbor solicitation packets used
for learning neighbors.
meters : nd-ns-resolve: optional string
@@ -491,23 +571,27 @@ Copp TABLE
meters : reject: optional string
Rate limiting meter for packets that trigger a reject action
+ meters : svc-monitor: optional string
+ Rate limiting meter for packets that are arriving to service
+ monitor MAC address.
+
external_ids: map of string-string pairs
See External IDs at the beginning of this document.
Logical_Switch TABLE
Each row represents one L2 logical switch.
- There are two kinds of logical switches, that is, ones that fully vir‐
- tualize the network (overlay logical switches) and ones that provide
- simple connectivity to physical networks (bridged logical switches).
- They work in the same way when providing connectivity between logical
- ports on same chassis, but differently when connecting remote logical
- ports. Overlay logical switches connect remote logical ports by tun‐
- nels, while bridged logical switches provide connectivity to remote
- ports by bridging the packets to directly connected physical L2 seg‐
- ments with the help of localnet ports. Each bridged logical switch has
- one or more localnet ports, which have only one special address
- unknown.
+ There are two kinds of logical switches, that is, ones that fully vir‐
+ tualize the network (overlay logical switches) and ones that provide
+ simple connectivity to physical networks (bridged logical switches).
+ They work in the same way when providing connectivity between logical
+ ports on same chassis, but differently when connecting remote logical
+ ports. Overlay logical switches connect remote logical ports by tun‐
+ nels, while bridged logical switches provide connectivity to remote
+ ports by bridging the packets to directly connected physical L2 seg‐
+ ments with the help of localnet ports. Each bridged logical switch has
+ one or more localnet ports, which have only one special address un‐
+ known.
Summary:
ports set of Logical_Switch_Ports
@@ -526,6 +610,9 @@ Logical_Switch TABLE
other_config : exclude_ips optional string
other_config : ipv6_prefix optional string
other_config : mac_only optional string, either true or false
+ other_config : fdb_age_threshold
+ optional string, containing an integer,
+ in range 0 to 4,294,967,295
IP Multicast Snooping Options:
other_config : mcast_snoop optional string, either true or false
other_config : mcast_querier
@@ -561,6 +648,8 @@ Logical_Switch TABLE
Other options:
other_config : vlan-passthru
optional string, either true or false
+ other_config : broadcast-arps-to-all-routers
+ optional string, either true or false
Common Columns:
external_ids map of string-string pairs
@@ -578,16 +667,16 @@ Logical_Switch TABLE
Set of load balancers groups associated to this logical switch.
acls: set of ACLs
- Access control rules that apply to packets within the logical
+ Access control rules that apply to packets within the logical
switch.
qos_rules: set of QoSes
- QoS marking and metering rules that apply to packets within the
+ QoS marking and metering rules that apply to packets within the
logical switch.
dns_records: set of weak reference to DNSes
- This column defines the DNS records to be used for resolving
- internal DNS queries within the logical switch by the native DNS
+ This column defines the DNS records to be used for resolving in‐
+ ternal DNS queries within the logical switch by the native DNS
resolver. Please see the DNS table.
forwarding_groups: set of Forwarding_Groups
@@ -603,9 +692,9 @@ Logical_Switch TABLE
logical switch, use its row UUID.)
(Originally, name was intended to serve the purpose of a human-friendly
- name, but the Neutron integration used it to uniquely identify its own
- switch object, in the format neutron-uuid. Later on, Neutron started
- propagating the friendly name of a switch as external_ids:neutron:net‐
+ name, but the Neutron integration used it to uniquely identify its own
+ switch object, in the format neutron-uuid. Later on, Neutron started
+ propagating the friendly name of a switch as external_ids:neutron:net‐
work_name. Perhaps this can be cleaned up someday.)
name: string
@@ -616,19 +705,19 @@ Logical_Switch TABLE
IP Address Assignment:
- These options control automatic IP address management (IPAM) for ports
- attached to the logical switch. To enable IPAM for IPv4, set other_con‐
+ These options control automatic IP address management (IPAM) for ports
+ attached to the logical switch. To enable IPAM for IPv4, set other_con‐
fig:subnet and optionally other_config:exclude_ips. To enable IPAM for
- IPv6, set other_config:ipv6_prefix. IPv4 and IPv6 may be enabled
- together or separately.
+ IPv6, set other_config:ipv6_prefix. IPv4 and IPv6 may be enabled to‐
+ gether or separately.
To request dynamic address assignment for a particular port, use the
- dynamic keyword in the addresses column of the port’s Logi‐
+ dynamic keyword in the addresses column of the port’s Logi‐
cal_Switch_Port row. This requests both an IPv4 and an IPv6 address, if
IPAM for IPv4 and IPv6 are both enabled.
other_config : subnet: optional string
- Set this to an IPv4 subnet, e.g. 192.168.0.0/24, to enable
+ Set this to an IPv4 subnet, e.g. 192.168.0.0/24, to enable
ovn-northd to automatically assign IP addresses within that sub‐
net.
@@ -644,55 +733,64 @@ Logical_Switch TABLE
Examples:
- · 192.168.0.2 192.168.0.10
+ • 192.168.0.2 192.168.0.10
- · 192.168.0.4 192.168.0.30..192.168.0.60
+ • 192.168.0.4 192.168.0.30..192.168.0.60
192.168.0.110..192.168.0.120
- · 192.168.0.110..192.168.0.120 192.168.0.25..192.168.0.30
+ • 192.168.0.110..192.168.0.120 192.168.0.25..192.168.0.30
192.168.0.144
other_config : ipv6_prefix: optional string
Set this to an IPv6 prefix to enable ovn-northd to automatically
- assign IPv6 addresses using this prefix. The assigned IPv6
- address will be generated using the IPv6 prefix and the MAC
- address (converted to an IEEE EUI64 identifier) of the port. The
- IPv6 prefix defined here should be a valid IPv6 address ending
+ assign IPv6 addresses using this prefix. The assigned IPv6 ad‐
+ dress will be generated using the IPv6 prefix and the MAC ad‐
+ dress (converted to an IEEE EUI64 identifier) of the port. The
+ IPv6 prefix defined here should be a valid IPv6 address ending
with ::.
Examples:
- · aef0::
+ • aef0::
- · bef0:1234:a890:5678::
+ • bef0:1234:a890:5678::
- · 8230:5678::
+ • 8230:5678::
other_config : mac_only: optional string, either true or false
- Value used to request to assign L2 address only if neither sub‐
+ Value used to request to assign L2 address only if neither sub‐
net nor ipv6_prefix are specified
+ other_config : fdb_age_threshold: optional string, containing an inte‐
+ ger, in range 0 to 4,294,967,295
+ FDB aging threshold value in seconds. FDB exceeding this timeout
+ will be automatically removed. The value defaults to 0, which
+ means disabled.
+
IP Multicast Snooping Options:
These options control IP Multicast Snooping configuration of the logi‐
- cal switch. To enable IP Multicast Snooping set other_con‐
- fig:mcast_snoop to true. To enable IP Multicast Querier set other_con‐
- fig:mcast_snoop to true. If IP Multicast Querier is enabled other_con‐
- fig:mcast_eth_src and other_config:mcast_ip4_src must be set.
+ cal switch. To enable IP Multicast Snooping set other_con‐
+ fig:mcast_snoop to true. To enable IP Multicast Querier set other_con‐
+ fig:mcast_querier to true. If IP Multicast Querier is enabled
+ other_config:mcast_eth_src and other_config:mcast_ip4_src must be set.
other_config : mcast_snoop: optional string, either true or false
- Enables/disables IP Multicast Snooping on the logical switch.
+ Enables/disables IP Multicast Snooping on the logical switch.
+ Default: false.
other_config : mcast_querier: optional string, either true or false
- Enables/disables IP Multicast Querier on the logical switch.
+ Enables/disables IP Multicast Querier on the logical switch.
+ Only applicable if other_config:mcast_snoop is enabled. Default:
+ true.
- other_config : mcast_flood_unregistered: optional string, either true
+ other_config : mcast_flood_unregistered: optional string, either true
or false
- Determines whether unregistered multicast traffic should be
- flooded or not. Only applicable if other_config:mcast_snoop is
+ Determines whether unregistered multicast traffic should be
+ flooded or not. Only applicable if other_config:mcast_snoop is
enabled. Default: false.
- other_config : mcast_table_size: optional string, containing an inte‐
+ other_config : mcast_table_size: optional string, containing an inte‐
ger, in range 1 to 32,766
Number of multicast groups to be stored. Default: 2048.
@@ -701,15 +799,15 @@ Logical_Switch TABLE
Configures the IP Multicast Snooping group idle timeout (in sec‐
onds). Default: 300 seconds.
- other_config : mcast_query_interval: optional string, containing an
- integer, in range 1 to 3,600
+ other_config : mcast_query_interval: optional string, containing an in‐
+ teger, in range 1 to 3,600
Configures the IP Multicast Querier interval between queries (in
seconds). Default: other_config:mcast_idle_timeout / 2.
other_config : mcast_query_max_response: optional string, containing an
integer, in range 1 to 10
- Configures the value of the "max-response" field in the multi‐
- cast queries originated by the logical switch. Default: 1 sec‐
+ Configures the value of the "max-response" field in the multi‐
+ cast queries originated by the logical switch. Default: 1 sec‐
ond.
other_config : mcast_eth_src: optional string
@@ -733,9 +831,9 @@ Logical_Switch TABLE
Tunnel Key:
- other_config : requested-tnl-key: optional string, containing an inte‐
+ other_config : requested-tnl-key: optional string, containing an inte‐
ger, in range 1 to 16,777,215
- Configures the datapath tunnel key for the logical switch. Usu‐
+ Configures the datapath tunnel key for the logical switch. Usu‐
ally this is not needed because ovn-northd will assign an unique
key for each datapath by itself. However, if it is configured,
ovn-northd honors the configured value. The typical use case is
@@ -745,20 +843,31 @@ Logical_Switch TABLE
from OVN_IC_Southbound through this config.
copp: optional weak reference to Copp
- The control plane protection policy from table Copp used for
- metering packets sent to ovn-controller from ports of this logi‐
- cal switch.
+ The control plane protection policy from table Copp used for me‐
+ tering packets sent to ovn-controller from ports of this logical
+ switch.
Other options:
other_config : vlan-passthru: optional string, either true or false
- Determines whether VLAN tagged incoming traffic should be
- allowed. Note that this may have security implications when
- enabled for a logical switch with a tag=0 localnet port. If not
+ Determines whether VLAN tagged incoming traffic should be al‐
+ lowed. Note that this may have security implications when en‐
+ abled for a logical switch with a tag=0 localnet port. If not
properly isolated from other localnet ports, fabric traffic that
- belongs to other tagged networks may be passed through such a
+ belongs to other tagged networks may be passed through such a
port.
+ other_config : broadcast-arps-to-all-routers: optional string, either
+ true or false
+ Determines whether arp requests and ipv6 neighbor solicitations
+ should be sent to all routers and other switchports (default) or
+ if it should only be sent to switchports where the ip/mac ad‐
+ dress is unknown. Setting this to false can significantly reduce
+ the load if the logical switch can receive arp requests for ips
+ it does not know about. However setting this to false also means
+ that garps are no longer forwarded to all routers and therefor
+ the mac bindings of the routers are no longer updated.
+
Common Columns:
external_ids: map of string-string pairs
@@ -779,6 +888,8 @@ Logical_Switch_Port TABLE
options : exclude-lb-vips-from-garp
optional string
options : arp_proxy optional string
+ options : enable_router_port_acl
+ optional string, either true or false
Options for localnet ports:
options : network_name optional string
options : ethtype optional string
@@ -837,7 +948,7 @@ Logical_Switch_Port TABLE
optional string
Tunnel Key:
options : requested-tnl-key
- optional string, containing an integer,
+ optional string, containing an integer,
in range 1 to 32,767
Common Columns:
external_ids map of string-string pairs
@@ -848,8 +959,8 @@ Logical_Switch_Port TABLE
name: string (must be unique within table)
The logical port name.
- For entities (VMs or containers) that are spawned in the hyper‐
- visor, the name used here must match those used in the exter‐
+ For entities (VMs or containers) that are spawned in the hyper‐
+ visor, the name used here must match those used in the exter‐
nal_ids:iface-id in the Open_vSwitch database’s Interface table,
because hypervisors use external_ids:iface-id as a lookup key to
identify the network interface of that entity.
@@ -868,15 +979,15 @@ Logical_Switch_Port TABLE
(empty string)
A VM (or VIF) interface.
- router A connection to a logical router. The value of
- options:router-port specifies the name of the Logi‐
+ router A connection to a logical router. The value of op‐
+ tions:router-port specifies the name of the Logi‐
cal_Router_Port to which this logical switch port is con‐
nected.
localnet
A connection to a locally accessible network from
ovn-controller instances that have a corresponding bridge
- mapping. A logical switch can have multiple localnet
+ mapping. A logical switch can have multiple localnet
ports attached. This type is used to model direct connec‐
tivity to existing networks. In this case, each chassis
should have a mapping for one of the physical networks
@@ -905,29 +1016,29 @@ Logical_Switch_Port TABLE
DHCPv4/DHCPv6/DNS for this port. If ha_chassis_group is
defined, ovn-controller running in the master chassis of
the HA chassis group will bind this port to provide these
- native services. It is expected that this port belong to
+ native services. It is expected that this port belong to
a bridged logical switch (with a localnet port).
- It is recommended to use the same HA chassis group for
- all the external ports of a logical switch. Otherwise,
+ It is recommended to use the same HA chassis group for
+ all the external ports of a logical switch. Otherwise,
the physical switch might see MAC flap issue when differ‐
ent chassis provide the native services. For example when
supporting native DHCPv4 service, DHCPv4 server mac (con‐
- figured in options:server_mac column in table
- DHCP_Options) originating from different ports can cause
- MAC flap issue. The MAC of the logical router IP(s) can
- also flap if the same HA chassis group is not set for all
- the external ports of a logical switch.
+ figured in options:server_mac column in table DHCP_Op‐
+ tions) originating from different ports can cause MAC
+ flap issue. The MAC of the logical router IP(s) can also
+ flap if the same HA chassis group is not set for all the
+ external ports of a logical switch.
Below are some of the use cases where external ports can
be used.
- · VMs connected to SR-IOV nics - Traffic from these
- VMs by passes the kernel stack and local ovn-con‐
+ • VMs connected to SR-IOV nics - Traffic from these
+ VMs by passes the kernel stack and local ovn-con‐
troller do not bind these ports and cannot serve
the native services.
- · When CMS supports provisioning baremetal servers.
+ • When CMS supports provisioning baremetal servers.
virtual
Represents a logical port which does not have an OVS port
@@ -938,22 +1049,22 @@ Logical_Switch_Port TABLE
One of the use case where virtual ports can be used is.
- · The virtual ip represents a load balancer vip and
+ • The virtual ip represents a load balancer vip and
the virtual parents provide load balancer service
in an active-standby setup with the active virtual
parent owning the virtual ip.
remote A remote port is to model a port that resides remotely on
another OVN, which is on the other side of a transit log‐
- ical switch for OVN interconnection. This type of ports
- are created by ovn-ic instead of by CMS. Any change to
+ ical switch for OVN interconnection. This type of ports
+ are created by ovn-ic instead of by CMS. Any change to
the port will be automatically overwritten by ovn-ic.
Options:
options: map of string-string pairs
- This column provides key/value settings specific to the logical
- port type. The type-specific options are described individually
+ This column provides key/value settings specific to the logical
+ port type. The type-specific options are described individually
below.
Options for router ports:
@@ -965,51 +1076,59 @@ Logical_Switch_Port TABLE
ical switch port is connected.
options : nat-addresses: optional string
- This is used to send gratuitous ARPs for SNAT and DNAT IP
- addresses via the localnet port that is attached to the same
- logical switch as this type router port. This option is speci‐
- fied on a logical switch port that is connected to a gateway
- router, or a logical switch port that is connected to a distrib‐
- uted gateway port on a logical router.
+ This is used to send gratuitous ARPs for SNAT and DNAT IP ad‐
+ dresses via the localnet port that is attached to the same logi‐
+ cal switch as this type router port. This option is specified on
+ a logical switch port that is connected to a gateway router, or
+ a logical switch port that is connected to a distributed gateway
+ port on a logical router.
This must take one of the following forms:
router Gratuitous ARPs will be sent for all SNAT and DNAT exter‐
nal IP addresses and for all load balancer IP addresses
- defined on the options:router-port’s logical router,
- using the options:router-port’s MAC address.
+ defined on the options:router-port’s logical router, us‐
+ ing the options:router-port’s MAC address.
This form of options:nat-addresses is valid for logical
switch ports where options:router-port is the name of a
port on a gateway router, or the name of a distributed
gateway port.
- Supported only in OVN 2.8 and later. Earlier versions
- required NAT addresses to be manually synchronized.
+ Supported only in OVN 2.8 and later. Earlier versions re‐
+ quired NAT addresses to be manually synchronized.
Ethernet address followed by one or more IPv4 addresses
- Example: 80:fa:5b:06:72:b7 158.36.44.22 158.36.44.24.
+ Example: 80:fa:5b:06:72:b7 158.36.44.22 158.36.44.24.
This would result in generation of gratuitous ARPs for IP
- addresses 158.36.44.22 and 158.36.44.24 with a MAC
- address of 80:fa:5b:06:72:b7.
+ addresses 158.36.44.22 and 158.36.44.24 with a MAC ad‐
+ dress of 80:fa:5b:06:72:b7.
This form of options:nat-addresses is only valid for log‐
- ical switch ports where options:router-port is the name
+ ical switch ports where options:router-port is the name
of a port on a gateway router.
options : exclude-lb-vips-from-garp: optional string
- If options:nat-addresses is set to router, Gratuitous ARPs will
- be sent for all SNAT and DNAT external IP addresses defined on
- the options:router-port’s logical router, using the
- options:router-port’s MAC address, not cosidering configured
- load balancers.
+ If options:nat-addresses is set to router, Gratuitous ARPs will
+ be sent for all SNAT and DNAT external IP addresses defined on
+ the options:router-port’s logical router, using the op‐
+ tions:router-port’s MAC address, not cosidering configured load
+ balancers.
options : arp_proxy: optional string
- Optional. A list of IPv4 addresses that this logical switch
- router port will reply to ARP requests. Example: 169.254.239.254
- 169.254.239.2. The options:router-port’s logical router should
- have a route to forward packets sent to configured proxy ARP IPs
- to an appropriate destination.
+ Optional. A list of MAC and addresses/cidrs or just ad‐
+ dresses/cidrs that this logical switch router port will reply to
+ ARP/NDP requests. Examples: 169.254.239.254 169.254.239.2,
+ 0a:58:a9:fe:01:01 169.254.239.254 169.254.239.2
+ 169.254.238.0/24, fd7b:6b4d:7b25:d22f::1 fd7b:6b4d:7b25:d22f::2,
+ 0a:58:a9:fe:01:01 fd7b:6b4d:7b25:d22f::0/64. Theoptions:router-
+ port’s logical router should have a route to forward packets
+ sent to configured proxy ARP MAC/IPs to an appropriate destina‐
+ tion.
+
+ options : enable_router_port_acl: optional string, either true or false
+ Optional. Enable conntrack for the router port whose peer is
+ l3dgw_port if set to true. The default value is false.
Options for localnet ports:
@@ -1018,12 +1137,12 @@ Logical_Switch_Port TABLE
options : network_name: optional string
Required. The name of the network to which the localnet port is
connected. Each hypervisor, via ovn-controller, uses its local
- configuration to determine exactly how to connect to this
- locally accessible network, if at all.
+ configuration to determine exactly how to connect to this lo‐
+ cally accessible network, if at all.
options : ethtype: optional string
Optional. VLAN EtherType field value for encapsulating VLAN
- headers. Supported values: 802.11q (default), 802.11ad.
+ headers. Supported values: 802.1q (default), 802.1ad.
options : localnet_learn_fdb: optional string, either true or false
Optional. Allows localnet port to learn MACs and store them in
@@ -1035,8 +1154,8 @@ Logical_Switch_Port TABLE
options : network_name: optional string
Required. The name of the network to which the l2gateway port is
- connected. The L2 gateway, via ovn-controller, uses its local
- configuration to determine exactly how to connect to this net‐
+ connected. The L2 gateway, via ovn-controller, uses its local
+ configuration to determine exactly how to connect to this net‐
work.
options : l2gateway-chassis: optional string
@@ -1060,10 +1179,10 @@ Logical_Switch_Port TABLE
options : requested-chassis: optional string
If set, identifies a specific chassis (by name or hostname) that
- is allowed to bind this port. Using this option will prevent
- thrashing between two chassis trying to bind the same port dur‐
- ing a live migration. It can also prevent similar thrashing due
- to a mis-configuration, if a port is accidentally created on
+ is allowed to bind this port. Using this option will prevent
+ thrashing between two chassis trying to bind the same port dur‐
+ ing a live migration. It can also prevent similar thrashing due
+ to a mis-configuration, if a port is accidentally created on
more than one chassis.
If set to a comma separated list, the first entry identifies the
@@ -1077,16 +1196,16 @@ Logical_Switch_Port TABLE
MTU implications because the network used for tunneling must
have MTU larger than localnet for stable connectivity.
- If the same host co-hosts more than one controller instance
- (either belonging to the same or separate clusters), special
- attention should be given to consistently using unique chassis
- names used in this option. It is advised that chassis names -
- and not host names - are used for this option.
+ If the same host co-hosts more than one controller instance (ei‐
+ ther belonging to the same or separate clusters), special atten‐
+ tion should be given to consistently using unique chassis names
+ used in this option. It is advised that chassis names - and not
+ host names - are used for this option.
options : activation-strategy: optional string
If used with multiple chassis set in requested-chassis, speci‐
- fies an activation strategy for all additional chassis. By
- default, no activation strategy is used, meaning additional port
+ fies an activation strategy for all additional chassis. By de‐
+ fault, no activation strategy is used, meaning additional port
locations are immediately available for use. When set to "rarp",
the port is blocked for ingress and egress communication until a
RARP packet is sent from a new location. The "rarp" strategy is
@@ -1102,9 +1221,9 @@ Logical_Switch_Port TABLE
sent from this interface, in bit/s.
options : qos_max_rate: optional string
- If set, indicates the maximum rate for data sent from this
- interface, in bit/s. The traffic will be shaped according to
- this limit.
+ If set, indicates the maximum rate for data sent from this in‐
+ terface, in bit/s. The traffic will be shaped according to this
+ limit.
options : qos_burst: optional string
If set, indicates the maximum burst size for data sent from this
@@ -1113,25 +1232,25 @@ Logical_Switch_Port TABLE
options : hostname: optional string
If set, indicates the DHCPv4 option "Hostname" (option code 12)
associated for this Logical Switch Port. If DHCPv4 is enabled
- for this Logical Switch Port, hostname dhcp option will be
- included in DHCP reply.
+ for this Logical Switch Port, hostname dhcp option will be in‐
+ cluded in DHCP reply.
VIF Plugging Options:
options : vif-plug-type: optional string
- If set, OVN will attempt to perform plugging of this VIF. In
- order to get this port plugged by the OVN controller, OVN must
- be built with support for VIF plugging. The default behavior is
- for the CMS to do the VIF plugging. Each VIF plug provider have
+ If set, OVN will attempt to perform plugging of this VIF. In or‐
+ der to get this port plugged by the OVN controller, OVN must be
+ built with support for VIF plugging. The default behavior is for
+ the CMS to do the VIF plugging. Each VIF plug provider have
their own options namespaced by name, for example "vif-plug:rep‐
- resentor:key". Please refer to the VIF plug provider documenta‐
+ resentor:key". Please refer to the VIF plug provider documenta‐
tion located in Documentation/topics/vif-plug-providers/ for
more information.
options : vif-plug-mtu-request: optional string
- Requested MTU for plugged interfaces. When set the OVN con‐
- troller will fill the mtu_request column of the Open vSwitch
- database’s Interface table. This in turn will make OVS vswitchd
+ Requested MTU for plugged interfaces. When set the OVN con‐
+ troller will fill the mtu_request column of the Open vSwitch
+ database’s Interface table. This in turn will make OVS vswitchd
update the MTU of the linked interface.
Virtual port Options:
@@ -1145,7 +1264,7 @@ Logical_Switch_Port TABLE
This options represents a set of logical port names (with in the
same logical switch) which can own the virtual ip configured in
the options:virtual-ip. All these virtual parents should add the
- virtual ip in the port_security if port security addressed are
+ virtual ip in the port_security if port security addressed are
enabled.
IP Multicast Snooping Options:
@@ -1171,56 +1290,61 @@ Logical_Switch_Port TABLE
ical wire, even inside a tunnel, so they need not be unique except rel‐
ative to a single VM on a hypervisor.
- These columns are used for VIFs that represent nested containers using
- shared VIFs. For VMs and for containers that have dedicated VIFs, they
+ These columns are used for VIFs that represent nested containers using
+ shared VIFs. For VMs and for containers that have dedicated VIFs, they
are empty.
parent_name: optional string
- The VM interface through which the nested container sends its
- network traffic. This must match the name column for some other
- Logical_Switch_Port.
+ The VM interface through which the nested container sends its
+ network traffic. This must match the name column for some other
+ Logical_Switch_Port. Note: for performance of the OVN Southbound
+ database conditional monitoring, unlike for regular VIFs,
+ ovn-controller will register to get updates about all OVN South‐
+ bound database Port_Binding table records that correspond to
+ nested container ports even if external_ids:ovn-monitor-all is
+ set to false. See ovn-controller(8) for more information.
tag_request: optional integer, in range 0 to 4,095
The VLAN tag in the network traffic associated with a con‐
tainer’s network interface. The client can request ovn-northd to
- allocate a tag that is unique within the scope of a specific
- parent (specified in parent_name) by setting a value of 0 in
+ allocate a tag that is unique within the scope of a specific
+ parent (specified in parent_name) by setting a value of 0 in
this column. The allocated value is written by ovn-northd in the
- tag column. (Note that these tags are allocated and managed
- locally in ovn-northd, so they cannot be reconstructed in the
+ tag column. (Note that these tags are allocated and managed lo‐
+ cally in ovn-northd, so they cannot be reconstructed in the
event that the database is lost.) The client can also request a
specific non-zero tag and ovn-northd will honor it and copy that
value to the tag column.
- When type is set to localnet or l2gateway, this can be set to
- indicate that the port represents a connection to a specific
- VLAN on a locally accessible network. The VLAN ID is used to
+ When type is set to localnet or l2gateway, this can be set to
+ indicate that the port represents a connection to a specific
+ VLAN on a locally accessible network. The VLAN ID is used to
match incoming traffic and is also added to outgoing traffic.
tag: optional integer, in range 1 to 4,095
- The VLAN tag allocated by ovn-northd based on the contents of
+ The VLAN tag allocated by ovn-northd based on the contents of
the tag_request column.
Port State:
up: optional boolean
- This column is populated by ovn-northd, rather than by the CMS
+ This column is populated by ovn-northd, rather than by the CMS
plugin as is most of this database. When a logical port is bound
to a physical location in the OVN Southbound database Binding
table, ovn-northd sets this column to true; otherwise, or if the
- port becomes unbound later, it sets it to false. If this column
- is empty, the port is not considered up. This allows the CMS to
- wait for a VM’s (or container’s) networking to become active
- before it allows the VM (or container) to start.
+ port becomes unbound later, it sets it to false. If this column
+ is empty, the port is not considered up. This allows the CMS to
+ wait for a VM’s (or container’s) networking to become active be‐
+ fore it allows the VM (or container) to start.
Logical ports of router type are an exception to this rule. They
- are considered to be always up, that is this column is always
+ are considered to be always up, that is this column is always
set to true.
enabled: optional boolean
- This column is used to administratively set port state. If this
- column is empty or is set to true, the port is enabled. If this
- column is set to false, the port is disabled. A disabled port
+ This column is used to administratively set port state. If this
+ column is empty or is set to true, the port is enabled. If this
+ column is set to false, the port is disabled. A disabled port
has all ingress and egress traffic dropped.
Addressing:
@@ -1233,29 +1357,29 @@ Logical_Switch_Port TABLE
Ethernet address followed by zero or more IPv4 or IPv6 addresses
(or both)
An Ethernet address defined is owned by the logical port.
- Like a physical Ethernet NIC, a logical port ordinarily
+ Like a physical Ethernet NIC, a logical port ordinarily
has a single fixed Ethernet address.
- When a OVN logical switch processes a unicast Ethernet
- frame whose destination MAC address is in a logical
- port’s addresses column, it delivers it only to that
- port, as if a MAC learning process had learned that MAC
+ When a OVN logical switch processes a unicast Ethernet
+ frame whose destination MAC address is in a logical
+ port’s addresses column, it delivers it only to that
+ port, as if a MAC learning process had learned that MAC
address on the port.
- If IPv4 or IPv6 address(es) (or both) are defined, it
- indicates that the logical port owns the given IP
- addresses.
+ If IPv4 or IPv6 address(es) (or both) are defined, it in‐
+ dicates that the logical port owns the given IP ad‐
+ dresses.
If IPv4 address(es) are defined, the OVN logical switch
- uses this information to synthesize responses to ARP
- requests without traversing the physical network. The OVN
+ uses this information to synthesize responses to ARP re‐
+ quests without traversing the physical network. The OVN
logical router connected to the logical switch, if any,
uses this information to avoid issuing ARP requests for
logical switch ports.
- Note that the order here is important. The Ethernet
- address must be listed before the IP address(es) if
- defined.
+ Note that the order here is important. The Ethernet ad‐
+ dress must be listed before the IP address(es) if de‐
+ fined.
Examples:
@@ -1271,38 +1395,38 @@ Logical_Switch_Port TABLE
This indicates that the logical port owns the mac
address and 1 IPv6 address.
- 80:fa:5b:06:72:b7 10.0.0.4
+ 80:fa:5b:06:72:b7 10.0.0.4
fdaa:15f2:72cf:0:f816:3eff:fe20:3f41
- This indicates that the logical port owns the mac
+ This indicates that the logical port owns the mac
address and 1 IPv4 address and 1 IPv6 address.
unknown
- This indicates that the logical port has an unknown set
- of Ethernet addresses. When an OVN logical switch pro‐
- cesses a unicast Ethernet frame whose destination MAC
+ This indicates that the logical port has an unknown set
+ of Ethernet addresses. When an OVN logical switch
+ processes a unicast Ethernet frame whose destination MAC
address is not in any logical port’s addresses column, it
- delivers it to the port (or ports) whose addresses col‐
- umns include unknown.
+ delivers it to the port (or ports) whose addresses
+ columns include unknown.
dynamic
Use dynamic to make ovn-northd generate a globally unique
MAC address, choose an unused IPv4 address with the logi‐
cal port’s subnet (if other_config:subnet is set in the
port’s Logical_Switch), and generate an IPv6 address from
- the MAC address (if other_config:ipv6_prefix is set in
- the port’s Logical_Switch) and store them in the port’s
+ the MAC address (if other_config:ipv6_prefix is set in
+ the port’s Logical_Switch) and store them in the port’s
dynamic_addresses column.
- Only one element containing dynamic may appear in
- addresses.
+ Only one element containing dynamic may appear in ad‐
+ dresses.
dynamic ip
dynamic ipv6
dynamic ip ipv6
These act like dynamic alone but specify particular IPv4 or
IPv6 addresses to use. OVN IPAM will still automatically
- allocate the other address if configured appropriately.
- Example: dynamic 192.168.0.1 2001::1.
+ allocate the other address if configured appropriately. Ex‐
+ ample: dynamic 192.168.0.1 2001::1.
mac dynamic
This acts like dynamic alone but specifies a particular MAC
@@ -1325,54 +1449,54 @@ Logical_Switch_Port TABLE
specified in nat with external_mac, then those addresses
are also used to populate the switch’s destination lookup.
- Supported only in OVN 2.7 and later. Earlier versions
- required router addresses to be manually synchronized.
+ Supported only in OVN 2.7 and later. Earlier versions re‐
+ quired router addresses to be manually synchronized.
dynamic_addresses: optional string
Addresses assigned to the logical port by ovn-northd, if dynamic
- is specified in addresses. Addresses will be of the same format
- as those that populate the addresses column. Note that dynami‐
- cally assigned addresses are constructed and managed locally in
- ovn-northd, so they cannot be reconstructed in the event that
+ is specified in addresses. Addresses will be of the same format
+ as those that populate the addresses column. Note that dynami‐
+ cally assigned addresses are constructed and managed locally in
+ ovn-northd, so they cannot be reconstructed in the event that
the database is lost.
port_security: set of strings
- This column controls the addresses from which the host attached
- to the logical port (``the host’’) is allowed to send packets
+ This column controls the addresses from which the host attached
+ to the logical port (``the host’’) is allowed to send packets
and to which it is allowed to receive packets. If this column is
empty, all addresses are permitted.
Each element in the set must begin with one Ethernet address.
This would restrict the host to sending packets from and receiv‐
- ing packets to the ethernet addresses defined in the logical
- port’s port_security column. It also restricts the inner source
- MAC addresses that the host may send in ARP and IPv6 Neighbor
+ ing packets to the ethernet addresses defined in the logical
+ port’s port_security column. It also restricts the inner source
+ MAC addresses that the host may send in ARP and IPv6 Neighbor
Discovery packets. The host is always allowed to receive packets
to multicast and broadcast Ethernet addresses.
Each element in the set may additionally contain one or more
IPv4 or IPv6 addresses (or both), with optional masks. If a mask
- is given, it must be a CIDR mask. In addition to the restric‐
- tions described for Ethernet addresses above, such an element
- restricts the IPv4 or IPv6 addresses from which the host may
- send and to which it may receive packets to the specified
- addresses. A masked address, if the host part is zero, indicates
- that the host is allowed to use any address in the subnet; if
- the host part is nonzero, the mask simply indicates the size of
+ is given, it must be a CIDR mask. In addition to the restric‐
+ tions described for Ethernet addresses above, such an element
+ restricts the IPv4 or IPv6 addresses from which the host may
+ send and to which it may receive packets to the specified ad‐
+ dresses. A masked address, if the host part is zero, indicates
+ that the host is allowed to use any address in the subnet; if
+ the host part is nonzero, the mask simply indicates the size of
the subnet. In addition:
- · If any IPv4 address is given, the host is also allowed to
+ • If any IPv4 address is given, the host is also allowed to
receive packets to the IPv4 local broadcast address
255.255.255.255 and to IPv4 multicast addresses
(224.0.0.0/4). If an IPv4 address with a mask is given,
the host is also allowed to receive packets to the broad‐
cast address in that specified subnet.
- If any IPv4 address is given, the host is additionally
- restricted to sending ARP packets with the specified
+ If any IPv4 address is given, the host is additionally
+ restricted to sending ARP packets with the specified
source IPv4 address. (RARP is not restricted.)
- · If any IPv6 address is given, the host is also allowed to
+ • If any IPv6 address is given, the host is also allowed to
receive packets to IPv6 multicast addresses (ff00::/8).
If any IPv6 address is given, the host is additionally
@@ -1382,16 +1506,16 @@ Logical_Switch_Port TABLE
If an element includes an IPv4 address, but no IPv6 addresses,
then IPv6 traffic is not allowed. If an element includes an IPv6
- address, but no IPv4 address, then IPv4 and ARP traffic is not
+ address, but no IPv4 address, then IPv4 and ARP traffic is not
allowed.
- This column uses the same lexical syntax as the match column in
+ This column uses the same lexical syntax as the match column in
the OVN Southbound database’s Pipeline table. Multiple addresses
within an element may be space or comma separated.
This column is provided as a convenience to cloud management
- systems, but all of the features that it implements can be
- implemented as ACLs using the ACL table.
+ systems, but all of the features that it implements can be im‐
+ plemented as ACLs using the ACL table.
Examples:
@@ -1399,19 +1523,19 @@ Logical_Switch_Port TABLE
The host may send traffic from and receive traffic to the
specified MAC address, and to receive traffic to Ethernet
multicast and broadcast addresses, but not otherwise. The
- host may not send ARP or IPv6 Neighbor Discovery packets
- with inner source Ethernet addresses other than the one
+ host may not send ARP or IPv6 Neighbor Discovery packets
+ with inner source Ethernet addresses other than the one
specified.
80:fa:5b:06:72:b7 192.168.1.10/24
- This adds further restrictions to the first example. The
- host may send IPv4 packets from or receive IPv4 packets
- to only 192.168.1.10, except that it may also receive
+ This adds further restrictions to the first example. The
+ host may send IPv4 packets from or receive IPv4 packets
+ to only 192.168.1.10, except that it may also receive
IPv4 packets to 192.168.1.255 (based on the subnet mask),
255.255.255.255, and any address in 224.0.0.0/4. The host
- may not send ARPs with a source Ethernet address other
- than 80:fa:5b:06:72:b7 or source IPv4 address other than
- 192.168.1.10. The host may not send or receive any IPv6
+ may not send ARPs with a source Ethernet address other
+ than 80:fa:5b:06:72:b7 or source IPv4 address other than
+ 192.168.1.10. The host may not send or receive any IPv6
(including IPv6 Neighbor Discovery) traffic.
"80:fa:5b:12:42:ba", "80:fa:5b:06:72:b7 192.168.1.10/24"
@@ -1444,7 +1568,7 @@ Logical_Switch_Port TABLE
source. Please see the Mirror table.
ha_chassis_group: optional HA_Chassis_Group
- References a row in the OVN Northbound database’s HA_Chas‐
+ References a row in the OVN Northbound database’s HA_Chas‐
sis_Group table. It indicates the HA chassis group to use if the
type is set to external. If type is not external, this column is
ignored.
@@ -1457,7 +1581,7 @@ Logical_Switch_Port TABLE
vide convenience for human interaction with the northbound data‐
base.
- Neutron copies this from its own port object’s name. (Neutron
+ Neutron copies this from its own port object’s name. (Neutron
ports do are not assigned human-friendly names by default, so it
will often be empty.)
@@ -1465,13 +1589,13 @@ Logical_Switch_Port TABLE
options : requested-tnl-key: optional string, containing an integer, in
range 1 to 32,767
- Configures the port binding tunnel key for the port. Usually
- this is not needed because ovn-northd will assign an unique key
- for each port by itself. However, if it is configured,
- ovn-northd honors the configured value. The typical use case is
- for interconnection: the tunnel keys for ports on transit
- switches need to be unique globally, so they are maintained in
- the global OVN_IC_Southbound database, and ovn-ic simply syncs
+ Configures the port binding tunnel key for the port. Usually
+ this is not needed because ovn-northd will assign an unique key
+ for each port by itself. However, if it is configured,
+ ovn-northd honors the configured value. The typical use case is
+ for interconnection: the tunnel keys for ports on transit
+ switches need to be unique globally, so they are maintained in
+ the global OVN_IC_Southbound database, and ovn-ic simply syncs
the value from OVN_IC_Southbound through this config.
Common Columns:
@@ -1479,7 +1603,7 @@ Logical_Switch_Port TABLE
external_ids: map of string-string pairs
See External IDs at the beginning of this document.
- The ovn-northd program copies all these pairs into the exter‐
+ The ovn-northd program copies all these pairs into the exter‐
nal_ids column of the Port_Binding table in OVN_Southbound data‐
base.
@@ -1498,8 +1622,8 @@ Forwarding_Group TABLE
Details:
name: string
A name for the forwarding group. This name has no special mean‐
- ing or purpose other than to provide convenience for human
- interaction with the ovn-nb database.
+ ing or purpose other than to provide convenience for human in‐
+ teraction with the ovn-nb database.
vip: string
The virtual IP address assigned to the forwarding group. It will
@@ -1523,12 +1647,12 @@ Forwarding_Group TABLE
Address_Set TABLE
Each row in this table represents a named set of addresses. An address
set may contain Ethernet, IPv4, or IPv6 addresses with optional bitwise
- or CIDR masks. Address set may ultimately be used in ACLs to compare
- against fields such as ip4.src or ip6.src. A single address set must
- contain addresses of the same type. As an example, the following would
+ or CIDR masks. Address set may ultimately be used in ACLs to compare
+ against fields such as ip4.src or ip6.src. A single address set must
+ contain addresses of the same type. As an example, the following would
create an address set with three IP addresses:
- ovn-nbctl create Address_Set name=set1 addresses=’10.0.0.1 10.0.0.2 10.0.0.3’
+ ovn-nbctl create Address_Set name=set1 addresses=’10.0.0.1 10.0.0.2 10.0.0.3’
Address sets may be used in the match column of the ACL table. For syn‐
@@ -1564,19 +1688,19 @@ Port_Group TABLE
the match column in the Logical_Flow table of the OVN_Southbound data‐
base.
- For each port group, there are two address sets generated to the
- Address_Set table of the OVN_Southbound database, containing the IP
- addresses of the group of ports, one for IPv4, and the other for IPv6,
+ For each port group, there are two address sets generated to the Ad‐
+ dress_Set table of the OVN_Southbound database, containing the IP ad‐
+ dresses of the group of ports, one for IPv4, and the other for IPv6,
with name being the name of the Port_Group followed by a suffix _ip4
for IPv4 and _ip6 for IPv6. The generated address sets can be used in
the same way as regular address sets in the match column of the ACL ta‐
ble. For syntax information, see the details of the expression language
- used for the match column in the Logical_Flow table of the OVN_South‐
+ used for the match column in the Logical_Flow table of the OVN_South‐
bound database.
Summary:
name string (must be unique within table)
- ports set of weak reference to Logi‐
+ ports set of weak reference to Logi‐
cal_Switch_Ports
acls set of ACLs
Common Columns:
@@ -1625,6 +1749,7 @@ Load_Balancer TABLE
options : template optional string
options : address-family optional string
options : affinity_timeout optional string
+ options : ct_flush optional string, either true or false
Details:
name: string
@@ -1637,20 +1762,20 @@ Load_Balancer TABLE
: as a separator) associated with this load balancer and their
corresponding endpoint IP addresses (and optional port numbers
with : as separators) separated by commas. If the destination IP
- address (and port number) of a packet leaving a container or a
- VM matches the virtual IP address (and port number) provided
- here as a key, then OVN will statefully replace the destination
- IP address by one of the provided IP address (and port number)
- in this map as a value. IPv4 and IPv6 addresses are supported
- for load balancing; however a VIP of one address family may not
- be mapped to a destination IP address of a different family. If
+ address (and port number) of a packet leaving a container or a
+ VM matches the virtual IP address (and port number) provided
+ here as a key, then OVN will statefully replace the destination
+ IP address by one of the provided IP address (and port number)
+ in this map as a value. IPv4 and IPv6 addresses are supported
+ for load balancing; however a VIP of one address family may not
+ be mapped to a destination IP address of a different family. If
specifying an IPv6 address with a port, the address portion must
be enclosed in square brackets. Examples for keys are
"192.168.1.4" and "[fd0f::1]:8800". Examples for value are
"10.0.0.1, 10.0.0.2" and "20.0.0.10:8800, 20.0.0.11:8800".
When the Load_Balancer is added to the logical_switch, the VIP
- has to be in a different subnet than the one used for the logi‐
+ has to be in a different subnet than the one used for the logi‐
cal_switch. Since VIP is in a different subnet, you should con‐
nect your logical switch to either a OVN logical router or a
real router (this is because the client can now send a packet
@@ -1665,47 +1790,52 @@ Load_Balancer TABLE
Health Checks:
- OVN supports health checks for load balancer endpoints, for IPv4 load
- balancers only. When health checks are enabled, the load balancer uses
- only healthy endpoints.
+ OVN supports health checks for load balancer endpoints. When health
+ checks are enabled, the load balancer uses only healthy endpoints.
- Suppose that vips contains a key-value pair
- 10.0.0.10:80=10.0.0.4:8080,20.0.0.4:8080. To enable health checks for
- this virtual’s endpoints, add two key-value pairs to ip_port_mappings,
+ Suppose that vips contains a key-value pair
+ 10.0.0.10:80=10.0.0.4:8080,20.0.0.4:8080. To enable health checks for
+ this virtual’s endpoints, add two key-value pairs to ip_port_mappings,
with keys 10.0.0.4 and 20.0.0.4, and add to health_check a reference to
- a Load_Balancer_Health_Check row whose vip is set to 10.0.0.10.
+ a Load_Balancer_Health_Check row whose vip is set to 10.0.0.10. The
+ same approach can be used for IPv6 as well.
health_check: set of Load_Balancer_Health_Checks
Load balancer health checks associated with this load balancer.
ip_port_mappings: map of string-string pairs
- Maps from endpoint IP to a colon-separated pair of logical port
- name and source IP, e.g. port_name:sourc_ip. Health checks are
- sent to this port with the specified source IP.
-
- For example, in the example above, IP to port mappings might be
- defined as 10.0.0.4=sw0-p1:10.0.0.2 and
- 20.0.0.4=sw1-p1:20.0.0.2, if the values given were suitable
+ Maps from endpoint IP to a colon-separated pair of logical port
+ name and source IP, e.g. port_name:sourc_ip for IPv4. Health
+ checks are sent to this port with the specified source IP. For
+ IPv6 square brackets must be used around IP address, e.g:
+ port_name:[sourc_ip]
+
+ For example, in the example above, IP to port mappings might be
+ defined as 10.0.0.4=sw0-p1:10.0.0.2 and
+ 20.0.0.4=sw1-p1:20.0.0.2, if the values given were suitable
ports and IP addresses.
- selection_fields: set of strings, one of eth_dst, eth_src, ip_dst,
+ For IPv6 IP to port mappings might be defined as
+ [2001::1]=sw0-p1:[2002::1].
+
+ selection_fields: set of strings, one of eth_dst, eth_src, ip_dst,
ip_src, tp_dst, or tp_src
- OVN native load balancers are supported using the OpenFlow
- groups of type select. OVS supports two selection methods:
- dp_hash and hash (with optional fields specified) in selecting
- the buckets of a group. Please see the OVS documentation (man
- ovs-ofctl) for more details on the selection methods. Each end‐
- point IP (and port if set) is mapped to a bucket in the group
+ OVN native load balancers are supported using the OpenFlow
+ groups of type select. OVS supports two selection methods:
+ dp_hash and hash (with optional fields specified) in selecting
+ the buckets of a group. Please see the OVS documentation (man
+ ovs-ofctl) for more details on the selection methods. Each end‐
+ point IP (and port if set) is mapped to a bucket in the group
flow.
- CMS can choose the hash selection method by setting the selec‐
- tion fields in this column. ovs-vswitchd uses the specified
+ CMS can choose the hash selection method by setting the selec‐
+ tion fields in this column. ovs-vswitchd uses the specified
fields in generating the hash.
dp_hash selection method uses the assistance of datapath to cal‐
culate the hash and it is expected to be faster than hash selec‐
- tion method. So CMS should take this into consideration before
- using the hash method. Please consult the OVS documentation and
+ tion method. So CMS should take this into consideration before
+ using the hash method. Please consult the OVS documentation and
OVS sources for the implementation details.
Common Columns:
@@ -1716,17 +1846,17 @@ Load_Balancer TABLE
Load_Balancer options:
options : reject: optional string, either true or false
- If the load balancer is created with --reject option and it has
- no active backends, a TCP reset segment (for tcp) or an ICMP
- port unreachable packet (for all other kind of traffic) will be
- sent whenever an incoming packet is received for this load-bal‐
- ancer. Please note using --reject option will disable empty_lb
+ If the load balancer is created with --reject option and it has
+ no active backends, a TCP reset segment (for tcp) or an ICMP
+ port unreachable packet (for all other kind of traffic) will be
+ sent whenever an incoming packet is received for this load-bal‐
+ ancer. Please note using --reject option will disable empty_lb
SB controller event for this load balancer.
options : hairpin_snat_ip: optional string
- IP to be used as source IP for packets that have been hair-
- pinned after load balancing. The default behavior when the
- option is not set is to use the load balancer VIP as source IP.
+ IP to be used as source IP for packets that have been hair-
+ pinned after load balancing. The default behavior when the op‐
+ tion is not set is to use the load balancer VIP as source IP.
This option may have exactly one IPv4 and/or one IPv6 address on
it, separated by a space character.
@@ -1740,20 +1870,20 @@ Load_Balancer TABLE
If set to true, then neighbor routers will have logical flows
added that will allow for routing to the VIP IP. It also will
have ARP resolution logical flows added. By setting this option,
- it means there is no reason to create a Logi‐
- cal_Router_Static_Route from neighbor routers to this NAT
- address. It also means that no ARP request is required for
- neighbor routers to learn the IP-MAC mapping for this VIP IP.
- For more information about what flows are added for IP routes,
- please see the ovn-northd manpage section on IP Routing.
+ it means there is no reason to create a Logical_Router_Sta‐
+ tic_Route from neighbor routers to this NAT address. It also
+ means that no ARP request is required for neighbor routers to
+ learn the IP-MAC mapping for this VIP IP. For more information
+ about what flows are added for IP routes, please see the
+ ovn-northd manpage section on IP Routing.
options : neighbor_responder: optional string
- If set to all, then routers on which the load balancer is
- applied reply to ARP/neighbor discovery requests for all VIPs of
- the load balancer. If set to reachable, then routers on which
- the load balancer is applied reply to ARP/neighbor discovery
- requests only for VIPs that are part of a router’s subnet. If
- set to none, then routers on which the load balancer is applied
+ If set to all, then routers on which the load balancer is ap‐
+ plied reply to ARP/neighbor discovery requests for all VIPs of
+ the load balancer. If set to reachable, then routers on which
+ the load balancer is applied reply to ARP/neighbor discovery re‐
+ quests only for VIPs that are part of a router’s subnet. If set
+ to none, then routers on which the load balancer is applied
never reply to ARP/neighbor discovery requests for any of the
load balancer VIPs. Load balancers with options:template=true do
not support reachable as a valid mode. The default value of this
@@ -1762,7 +1892,7 @@ Load_Balancer TABLE
options : template: optional string
Option to be set to true, if the load balancer is a template.
- The load balancer VIPs and backends must be using Chassis_Tem‐
+ The load balancer VIPs and backends must be using Chassis_Tem‐
plate_Var in their definitions.
Load balancer template VIP supported formats are:
@@ -1784,27 +1914,34 @@ Load_Balancer TABLE
^BACKENDS_VAR1,^BACKENDS_VAR2
- where BACKEND_VAR1, PORT_VAR1, BACKEND_VAR2, PORT_VAR2, BACK‐
+ where BACKEND_VAR1, PORT_VAR1, BACKEND_VAR2, PORT_VAR2, BACK‐
ENDS_VAR1 and BACKENDS_VAR2 are keys of the Chassis_Template_Var
variables records.
options : address-family: optional string
- Address family used by the load balancer. Supported values are
- ipv4 and ipv6. The address-family is only used for load bal‐
- ancers with options:template=true. For explicit load balancers,
+ Address family used by the load balancer. Supported values are
+ ipv4 and ipv6. The address-family is only used for load bal‐
+ ancers with options:template=true. For explicit load balancers,
setting the address-family has no effect.
options : affinity_timeout: optional string
- If the CMS provides a positive value (in seconds) for affin‐
- ity_timeout, OVN will dnat connections received from the same
- client to this lb to the same backend if received in the affin‐
+ If the CMS provides a positive value (in seconds) for affin‐
+ ity_timeout, OVN will dnat connections received from the same
+ client to this lb to the same backend if received in the affin‐
ity timeslot. Max supported affinity_timeout is 65535 seconds.
+ options : ct_flush: optional string, either true or false
+ The value indicates whether ovn-controller should flush CT en‐
+ tries that are related to this LB. The flush happens if the LB
+ is removed, any of the backends is updated/removed or the LB is
+ not considered local anymore by the ovn-controller. This option
+ is set to false by default.
+
Load_Balancer_Group TABLE
- Each row represents a logical grouping of load balancers. It is up to
- the CMS to decide the criteria on which load balancers are grouped
- together. To simplify configuration and to optimize its processing load
- balancers that must be associated to the same set of logical switches
+ Each row represents a logical grouping of load balancers. It is up to
+ the CMS to decide the criteria on which load balancers are grouped to‐
+ gether. To simplify configuration and to optimize its processing load
+ balancers that must be associated to the same set of logical switches
and/or logical routers should be grouped together.
Summary:
@@ -1813,16 +1950,15 @@ Load_Balancer_Group TABLE
Details:
name: string (must be unique within table)
- A name for the load balancer group. This name has no special
- meaning or purpose other than to provide convenience for human
+ A name for the load balancer group. This name has no special
+ meaning or purpose other than to provide convenience for human
interaction with the ovn-nb database.
load_balancer: set of weak reference to Load_Balancers
A set of load balancers.
Load_Balancer_Health_Check TABLE
- Each row represents one load balancer health check. Health checks are
- supported for IPv4 load balancers only.
+ Each row represents one load balancer health check.
Summary:
vip string
@@ -1862,9 +1998,9 @@ Load_Balancer_Health_Check TABLE
ACL TABLE
Each row in this table represents one ACL rule for a logical switch or
a port group that points to it through its acls column. The action col‐
- umn for the highest-priority matching row in this table determines a
- packet’s treatment. If no row matches, packets are allowed by default.
- (Default-deny treatment is possible: add a rule with priority 0, 1 as
+ umn for the highest-priority matching row in this table determines a
+ packet’s treatment. If no row matches, packets are allowed by default.
+ (Default-deny treatment is possible: add a rule with priority 0, 1 as
match, and deny as action.)
Summary:
@@ -1872,8 +2008,10 @@ ACL TABLE
priority integer, in range 0 to 32,767
direction string, either from-lport or to-lport
match string
- action string, one of allow-related,
- allow-stateless, allow, drop, or reject
+ action string, one of allow-related, al‐
+ low-stateless, allow, drop, pass, or re‐
+ ject
+ tier integer, in range 0 to 3
options:
options : apply-after-lb optional string
Logging:
@@ -1901,7 +2039,7 @@ ACL TABLE
allow-related actions.
priority: integer, in range 0 to 32,767
- The ACL rule’s priority. Rules with numerically higher priority
+ The ACL rule’s priority. Rules with numerically higher priority
take precedence over those with lower. If two ACL rules with the
same priority both match, then the one actually applied to a
packet is undefined.
@@ -1910,64 +2048,86 @@ ACL TABLE
cannot be changed through an ACL.
allow-stateless flows always take precedence before stateful
- ACLs, regardless of their priority. (Both allow and
- allow-related ACLs can be stateful.)
+ ACLs, regardless of their priority. (Both allow and allow-re‐
+ lated ACLs can be stateful.)
direction: string, either from-lport or to-lport
Direction of the traffic to which this rule should apply:
- · from-lport: Used to implement filters on traffic arriving
+ • from-lport: Used to implement filters on traffic arriving
from a logical port. These rules are applied to the logi‐
cal switch’s ingress pipeline.
- · to-lport: Used to implement filters on traffic forwarded
+ • to-lport: Used to implement filters on traffic forwarded
to a logical port. These rules are applied to the logical
switch’s egress pipeline.
match: string
- The packets that the ACL should match, in the same expression
- language used for the match column in the OVN Southbound data‐
- base’s Logical_Flow table. The outport logical port is only
- available in the to-lport direction (the inport is available in
+ The packets that the ACL should match, in the same expression
+ language used for the match column in the OVN Southbound data‐
+ base’s Logical_Flow table. The outport logical port is only
+ available in the to-lport direction (the inport is available in
both directions).
- By default all traffic is allowed. When writing a more restric‐
- tive policy, it is important to remember to allow flows such as
+ By default all traffic is allowed. When writing a more restric‐
+ tive policy, it is important to remember to allow flows such as
ARP and IPv6 neighbor discovery packets.
- Note that you can not create an ACL matching on a port with
+ Note that you can not create an ACL matching on a port with
type=router or type=localnet.
- action: string, one of allow-related, allow-stateless, allow, drop, or
- reject
+ action: string, one of allow-related, allow-stateless, allow, drop,
+ pass, or reject
The action to take when the ACL rule matches:
- · allow-stateless: Always forward the packet in stateless
+ • allow-stateless: Always forward the packet in stateless
manner, omitting connection tracking mechanism, regard‐
less of other rules defined for the switch. May require
defining additional rules for inbound replies. For exam‐
ple, if you define a rule to allow outgoing TCP traffic
directed to an IP address, then you probably also want to
- define another rule to allow incoming TCP traffic coming
- from this same IP address. In addition, traffic that
+ define another rule to allow incoming TCP traffic coming
+ from this same IP address. In addition, traffic that
matches stateless ACLs will bypass load-balancer DNAT/un-
DNAT processing. Stateful ACLs should be used instead if
the traffic is supposed to be load-balanced.
- · allow: Forward the packet. It will also send the packets
- through connection tracking when allow-related rules
- exist on the logical switch. Otherwise, it’s equivalent
- to allow-stateless.
+ • allow: Forward the packet. It will also send the packets
+ through connection tracking when allow-related rules ex‐
+ ist on the logical switch. Otherwise, it’s equivalent to
+ allow-stateless.
- · allow-related: Forward the packet and related traffic
+ • allow-related: Forward the packet and related traffic
(e.g. inbound replies to an outbound connection).
- · drop: Silently drop the packet.
+ • drop: Silently drop the packet.
- · reject: Drop the packet, replying with a RST for TCP or
+ • reject: Drop the packet, replying with a RST for TCP or
ICMPv4/ICMPv6 unreachable message for other
IPv4/IPv6-based protocols.
+ • pass: Pass to the next ACL tier. If using multiple ACL
+ tiers, a match on this ACL will stop evaluating ACLs at
+ the current tier and move to the next one. If not using
+ ACL tiers or if a pass ACL is matched at the final tier,
+ then the options:default_acl_drop option from the
+ NB_Global table is used to determine how to proceed.
+
+ tier: integer, in range 0 to 3
+ The hierarchical tier that this ACL belongs to.
+
+ ACLs can be assigned to numerical tiers. When evaluating ACLs,
+ an internal counter is used to determine which tier of ACLs
+ should be evaluated. Tier 0 ACLs are evaluated first. If no ver‐
+ dict can be determined, then tier 1 ACLs are evaluated next.
+ This continues until the maximum tier value is reached. If all
+ tiers of ACLs are evaluated and no verdict is reached, then the
+ options:default_acl_drop option from table NB_Global is used to
+ determine how to proceed.
+
+ In this version of OVN, the maximum tier value for ACLs is 3,
+ meaning there are 4 tiers of ACLs allowed (0-3).
+
options:
ACLs options.
@@ -1982,20 +2142,20 @@ ACL TABLE
OVN will apply the from-lport ACLs in two stages. ACLs without
this option apply-after-lb set, will be applied before the load
- balancer stage and ACLs with this option set will be applied
- after the load balancer stage. The priorities are indepedent
- between these stages and may not be obvious to the CMS. Hence
- CMS should be extra careful when using this option and should
- carefully evaluate the priorities of all the ACLs and the
- default deny/allow ACLs if any.
+ balancer stage and ACLs with this option set will be applied af‐
+ ter the load balancer stage. The priorities are indepedent be‐
+ tween these stages and may not be obvious to the CMS. Hence CMS
+ should be extra careful when using this option and should care‐
+ fully evaluate the priorities of all the ACLs and the default
+ deny/allow ACLs if any.
Logging:
- These columns control whether and how OVN logs packets that match an
+ These columns control whether and how OVN logs packets that match an
ACL.
log: boolean
- If set to true, packets that match the ACL will trigger a log
+ If set to true, packets that match the ACL will trigger a log
message on the transport node or nodes that perform ACL process‐
ing. Logging may be combined with any action.
@@ -2007,23 +2167,23 @@ ACL TABLE
provides the administrator and the cloud management system a way
to associate a log record with a particular ACL.
- severity: optional string, one of alert, debug, info, notice, or warn‐
+ severity: optional string, one of alert, debug, info, notice, or warn‐
ing
The severity of the ACL. The severity levels match those of sys‐
- log, in decreasing level of severity: alert, warning, notice,
+ log, in decreasing level of severity: alert, warning, notice,
info, or debug. When the column is empty, the default is info.
meter: optional string
- The name of a meter to rate-limit log messages for the ACL. The
- string must match the name column of a row in the Meter table.
- By default, log messages are not rate-limited. In order to
- ensure that the same Meter rate limits multiple ACL logs sepa‐
+ The name of a meter to rate-limit log messages for the ACL. The
+ string must match the name column of a row in the Meter table.
+ By default, log messages are not rate-limited. In order to en‐
+ sure that the same Meter rate limits multiple ACL logs sepa‐
rately, set the fair column.
Common Columns:
options: map of string-string pairs
- This column provides general key/value settings. The supported
+ This column provides general key/value settings. The supported
options are described individually below.
ACL configuration options:
@@ -2034,12 +2194,12 @@ ACL TABLE
the log option must be set to true and a label must be set, and
it must be unique to the ACL. The label is necessary as it is
the only means to associate the reply traffic with the ACL to
- which it belongs. It must be unique, because otherwise it is
- ambiguous which ACL will be matched. Note: If this option is
- enabled, an extra flow is installed in order to log the related
- traffic. Therefore, if this is enabled on all ACLs, then the
- total number of flows necessary to log the ACL traffic is dou‐
- bled, compared to if this option is not enabled.
+ which it belongs. It must be unique, because otherwise it is am‐
+ biguous which ACL will be matched. Note: If this option is en‐
+ abled, an extra flow is installed in order to log the related
+ traffic. Therefore, if this is enabled on all ACLs, then the to‐
+ tal number of flows necessary to log the ACL traffic is doubled,
+ compared to if this option is not enabled.
external_ids: map of string-string pairs
See External IDs at the beginning of this document.
@@ -2071,13 +2231,12 @@ Logical_Router TABLE
options : always_learn_from_arp_request
optional string, either true or false
options : requested-tnl-key
- optional string, containing an integer,
+ optional string, containing an integer,
in range 1 to 16,777,215
- options : snat-ct-zone optional string, containing an integer,
+ options : snat-ct-zone optional string, containing an integer,
in range 0 to 65,535
options : mac_binding_age_threshold
- optional string, containing an integer,
- in range 0 to 4,294,967,295
+ optional string
Common Columns:
external_ids map of string-string pairs
@@ -2114,14 +2273,14 @@ Logical_Router TABLE
These columns provide names for the logical router. From OVN’s perspec‐
tive, these names have no special meaning or purpose other than to pro‐
- vide convenience for human interaction with the northbound database.
- There is no requirement for the name to be unique. (For a unique iden‐
+ vide convenience for human interaction with the northbound database.
+ There is no requirement for the name to be unique. (For a unique iden‐
tifier for a logical router, use its row UUID.)
(Originally, name was intended to serve the purpose of a human-friendly
name, but the Neutron integration used it to uniquely identify its own
router object, in the format neutron-uuid. Later on, Neutron started
- propagating the friendly name of a router as external_ids:neu‐
+ propagating the friendly name of a router as external_ids:neu‐
tron:router_name. Perhaps this can be cleaned up someday.)
name: string
@@ -2131,9 +2290,9 @@ Logical_Router TABLE
Another name for the logical router.
copp: optional weak reference to Copp
- The control plane protection policy from table Copp used for
- metering packets sent to ovn-controller from logical ports of
- this router.
+ The control plane protection policy from table Copp used for me‐
+ tering packets sent to ovn-controller from logical ports of this
+ router.
Options:
@@ -2141,25 +2300,25 @@ Logical_Router TABLE
options : chassis: optional string
If set, indicates that the logical router in question is a Gate‐
- way router (which is centralized) and resides in the set chas‐
- sis. The same value is also used by ovn-controller to uniquely
- identify the chassis in the OVN deployment and comes from exter‐
+ way router (which is centralized) and resides in the set chas‐
+ sis. The same value is also used by ovn-controller to uniquely
+ identify the chassis in the OVN deployment and comes from exter‐
nal_ids:system-id in the Open_vSwitch table of Open_vSwitch
database.
The Gateway router can only be connected to a distributed router
- via a switch if SNAT and DNAT are to be configured in the Gate‐
+ via a switch if SNAT and DNAT are to be configured in the Gate‐
way router.
options : dnat_force_snat_ip: optional string
- If set, indicates a set of IP addresses to use to force SNAT a
- packet that has already been DNATed in the gateway router. When
- multiple gateway routers are configured, a packet can poten‐
- tially enter any of the gateway router, get DNATted and eventu‐
+ If set, indicates a set of IP addresses to use to force SNAT a
+ packet that has already been DNATed in the gateway router. When
+ multiple gateway routers are configured, a packet can poten‐
+ tially enter any of the gateway router, get DNATted and eventu‐
ally reach the logical switch port. For the return traffic to go
back to the same gateway router (for unDNATing), the packet
needs a SNAT in the first place. This can be achieved by setting
- the above option with a gateway specific set of IP addresses.
+ the above option with a gateway specific set of IP addresses.
This option may have exactly one IPv4 and/or one IPv6 address on
it, separated by a a space.
@@ -2167,16 +2326,16 @@ Logical_Router TABLE
If set, this option can take two possible type of values. Either
a set of IP addresses or the string value - router_ip.
- If a set of IP addresses are configured, it indicates to use to
- force SNAT a packet that has already been load-balanced in the
- gateway router. When multiple gateway routers are configured, a
- packet can potentially enter any of the gateway routers, get
- DNATted as part of the load-balancing and eventually reach the
- logical switch port. For the return traffic to go back to the
- same gateway router (for unDNATing), the packet needs a SNAT in
- the first place. This can be achieved by setting the above
- option with a gateway specific set of IP addresses. This option
- may have exactly one IPv4 and/or one IPv6 address on it, sepa‐
+ If a set of IP addresses are configured, it indicates to use to
+ force SNAT a packet that has already been load-balanced in the
+ gateway router. When multiple gateway routers are configured, a
+ packet can potentially enter any of the gateway routers, get
+ DNATted as part of the load-balancing and eventually reach the
+ logical switch port. For the return traffic to go back to the
+ same gateway router (for unDNATing), the packet needs a SNAT in
+ the first place. This can be achieved by setting the above op‐
+ tion with a gateway specific set of IP addresses. This option
+ may have exactly one IPv4 and/or one IPv6 address on it, sepa‐
rated by a space character.
If it is configured with the value router_ip, then the load bal‐
@@ -2185,29 +2344,29 @@ Logical_Router TABLE
routing decision.
options : mcast_relay: optional string, either true or false
- Enables/disables IP multicast relay between logical switches
+ Enables/disables IP multicast relay between logical switches
connected to the logical router. Default: False.
options : dynamic_neigh_routers: optional string, either true or false
- If set to true, the router will resolve neighbor routers’ MAC
- addresses only by dynamic ARP/ND, instead of prepopulating
- static mappings for all neighbor routers in the ARP/ND Resolu‐
- tion stage. This reduces number of flows, but requires ARP/ND
- messages to resolve the IP-MAC bindings when needed. It is false
- by default. It is recommended to set to true when a large number
- of logical routers are connected to the same logical switch but
- most of them never need to send traffic between each other. By
- default, ovn-northd does not create mappings to NAT and load
+ If set to true, the router will resolve neighbor routers’ MAC
+ addresses only by dynamic ARP/ND, instead of prepopulating sta‐
+ tic mappings for all neighbor routers in the ARP/ND Resolution
+ stage. This reduces number of flows, but requires ARP/ND mes‐
+ sages to resolve the IP-MAC bindings when needed. It is false by
+ default. It is recommended to set to true when a large number of
+ logical routers are connected to the same logical switch but
+ most of them never need to send traffic between each other. By
+ default, ovn-northd does not create mappings to NAT and load
balancer addresess. However, for NAT and load balancer addresses
that have the add_route option added, ovn-northd will create
logical flows that map NAT and load balancer IP addresses to the
- appropriate MAC address. Setting dynamic_neigh_routers to true
+ appropriate MAC address. Setting dynamic_neigh_routers to true
will prevent the automatic creation of these logical flows.
- options : always_learn_from_arp_request: optional string, either true
+ options : always_learn_from_arp_request: optional string, either true
or false
- This option controls the behavior when handling IPv4 ARP
- requests or IPv6 ND-NS packets - whether a dynamic neighbor (MAC
+ This option controls the behavior when handling IPv4 ARP re‐
+ quests or IPv6 ND-NS packets - whether a dynamic neighbor (MAC
binding) entry is added/updated.
true - Always learn the MAC-IP binding, and add/update the MAC
@@ -2225,23 +2384,56 @@ Logical_Router TABLE
options : requested-tnl-key: optional string, containing an integer, in
range 1 to 16,777,215
- Configures the datapath tunnel key for the logical router. This
- is not needed because ovn-northd will assign an unique key for
- each datapath by itself. However, if it is configured,
+ Configures the datapath tunnel key for the logical router. This
+ is not needed because ovn-northd will assign an unique key for
+ each datapath by itself. However, if it is configured,
ovn-northd honors the configured value.
- options : snat-ct-zone: optional string, containing an integer, in
+ options : snat-ct-zone: optional string, containing an integer, in
range 0 to 65,535
Use the requested conntrack zone for SNAT with this router. This
- can be useful if egress traffic from the host running OVN comes
- from both OVN and other sources. This way, OVN and the other
+ can be useful if egress traffic from the host running OVN comes
+ from both OVN and other sources. This way, OVN and the other
sources can make use of the same conntrack zone.
- options : mac_binding_age_threshold: optional string, containing an
- integer, in range 0 to 4,294,967,295
- MAC binding aging threshold value in seconds. MAC binding
- exceeding this timeout will be automatically removed. The value
- defaults to 0, which means disabled.
+ options : mac_binding_age_threshold: optional string
+ Specifies the MAC binding aging thresholds based on CIDRs, with
+ the format: entry[;entry[...]], where each entry has the format:
+ [cidr:]threshold
+
+ • cidr: Can be either an IPv4 or IPv6 CIDR.
+
+ • threshold: Threshold value in seconds. MAC bindings with
+ IP addresses matching the specified CIDR that exceed this
+ timeout will be automatically removed.
+
+ If an entry is provided without an CIDR (just the threshold
+ value), it specifies the default threshold for MAC bindings that
+ don’t match any of the given CIDRs. If there are multiple de‐
+ fault threshold entries in the option, the behavior is unde‐
+ fined.
+
+ If there are multiple CIDRs matching a MAC binding IP, the one
+ with the longest prefix length takes effect. If there are multi‐
+ ple entries with the same CIDR in the option, the behavior is
+ undefined.
+
+ If no matching CIDR is found for a MAC binding IP, and no de‐
+ fault threshold is specified, the behavior defaults to the orig‐
+ inal: the binding will not be removed based on age.
+
+ The value can also default to an empty string, which means that
+ the aging threshold is disabled. Any string not in the above
+ format is regarded as invalid and the aging is disabled.
+
+ Example: 192.168.0.0/16:300;192.168.10.0/24:0;fe80::/10:600;1200
+
+ This sets a threshold of 300 seconds for MAC bindings with IP
+ addresses in the 192.168.0.0/16 range, excluding the
+ 192.168.1.0/24 range (for which the aging is disabled), a
+ threshold of 600 seconds for MAC bindings with IP addresses in
+ the fe80::/10 IPv6 range, and a default threshold of 1200 sec‐
+ onds for all other MAC bindings.
Common Columns:
@@ -2249,22 +2441,23 @@ Logical_Router TABLE
See External IDs at the beginning of this document.
QoS TABLE
- Each row in this table represents one QoS rule for a logical switch
- that points to it through its qos_rules column. Two types of QoS are
+ Each row in this table represents one QoS rule for a logical switch
+ that points to it through its qos_rules column. Two types of QoS are
supported: DSCP marking and metering. A match with the highest-priority
will have QoS applied to it. If the action column is specified, then
matching packets will have DSCP marking applied. If the bandwidth col‐
- umn is specified, then matching packets will have metering applied.
- action and bandwidth are not exclusive, so both marking and metering by
- defined for the same QoS entry. If no row matches, packets will not
+ umn is specified, then matching packets will have metering applied. ac‐
+ tion and bandwidth are not exclusive, so both marking and metering by
+ defined for the same QoS entry. If no row matches, packets will not
have any QoS applied.
Summary:
priority integer, in range 0 to 32,767
direction string, either from-lport or to-lport
match string
- action map of string-integer pairs, key must be
- dscp, value in range 0 to 63
+ action map of string-integer pairs, key either
+ dscp or mark, value in range 0 to
+ 4,294,967,295
bandwidth map of string-integer pairs, key either
burst or rate, value in range 1 to
4,294,967,295
@@ -2274,11 +2467,11 @@ QoS TABLE
priority: integer, in range 0 to 32,767
The QoS rule’s priority. Rules with numerically higher priority
take precedence over those with lower. If two QoS rules with the
- same priority both match, then the one actually applied to a
+ same priority both match, then the one actually applied to a
packet is undefined.
direction: string, either from-lport or to-lport
- The value of this field is similar to ACL column in the OVN
+ The value of this field is similar to ACL column in the OVN
Northbound database’s ACL table.
match: string
@@ -2288,36 +2481,42 @@ QoS TABLE
available in the to-lport direction (the inport is available in
both directions).
- action: map of string-integer pairs, key must be dscp, value in range 0
- to 63
- When specified, matching flows will have DSCP marking applied.
+ action: map of string-integer pairs, key either dscp or mark, value in
+ range 0 to 4,294,967,295
+ When dscp action is specified, matching flows will have have
+ DSCP marking applied. When mark action is specified, matching
+ flows will have packet marking applied.
- · dscp: The value of this action should be in the range of
+ • dscp: The value of this action should be in the range of
0 to 63 (inclusive).
+ • mark: The value of this action should be a positive inte‐
+ ger.
+
bandwidth: map of string-integer pairs, key either burst or rate, value
in range 1 to 4,294,967,295
When specified, matching packets will have bandwidth metering
applied. Traffic over the limit will be dropped.
- · rate: The value of rate limit in kbps.
+ • rate: The value of rate limit in kbps.
- · burst: The value of burst rate limit in kilobits. This is
+ • burst: The value of burst rate limit in kilobits. This is
optional and needs to specify the rate.
external_ids: map of string-string pairs
See External IDs at the beginning of this document.
Mirror TABLE
- Each row in this table represents a mirror that can be used for port
- mirroring. These mirrors are referenced by the mirror_rules column in
+ Each row in this table represents a mirror that can be used for port
+ mirroring. These mirrors are referenced by the mirror_rules column in
the Logical_Switch_Port table.
Summary:
name string (must be unique within table)
- filter string, either from-lport or to-lport
+ filter string, one of both, from-lport, or
+ to-lport
sink string
- type string, either erspan or gre
+ type string, one of erspan, gre, or local
index integer
external_ids map of string-string pairs
@@ -2325,30 +2524,35 @@ Mirror TABLE
name: string (must be unique within table)
Represents the name of the mirror.
- filter: string, either from-lport or to-lport
+ filter: string, one of both, from-lport, or to-lport
The value of this field represents selection criteria of the
mirror. to-lport mirrors the packets coming into logical port.
- from-lport mirrors the packets going out of logical port.
+ from-lport mirrors the packets going out of logical port. both
+ mirrors for both directions.
sink: string
- The value of this field represents the destination/sink of the
- mirror. The value it takes is an IP address of the sink port.
+ The value of this field represents the destination/sink of the
+ mirror. If the type is gre or erspan, the value indicates the
+ tunnel remote IP (either IPv4 or IPv6). For a type of local,
+ this field defines a local interface on the OVS integration
+ bridge to be used as the mirror destination. The interface must
+ possess external-ids:mirror-id that matches this string.
- type: string, either erspan or gre
- The value of this field represents the type of the tunnel used
- for sending the mirrored packets.
+ type: string, one of erspan, gre, or local
+ The value of this field specifies the mirror type - gre, erspan
+ or local.
index: integer
The value of this field represents the tunnel ID. If the config‐
ured tunnel type is gre, this field represents the GRE key value
- and if the configured tunnel type is erspan it represents the
- erspan_idx value.
+ and if the configured tunnel type is erspan it represents the
+ erspan_idx value. It is ignored if the type is local.
external_ids: map of string-string pairs
See External IDs at the beginning of this document.
Meter TABLE
- Each row in this table represents a meter that can be used for QoS or
+ Each row in this table represents a meter that can be used for QoS or
rate-limiting.
Summary:
@@ -2362,12 +2566,12 @@ Meter TABLE
name: string (must be unique within table)
A name for this meter.
- Names that begin with "__" (two underscores) are reserved for
+ Names that begin with "__" (two underscores) are reserved for
OVN internal use and should not be added manually.
unit: string, either kbps or pktps
- The unit for rate and burst_rate parameters in the bands entry.
- kbps specifies kilobits per second, and pktps specifies packets
+ The unit for rate and burst_rate parameters in the bands entry.
+ kbps specifies kilobits per second, and pktps specifies packets
per second.
bands: set of 1 or more Meter_Bands
@@ -2379,9 +2583,9 @@ Meter TABLE
fair: optional boolean
This column is used to further describe the desired behavior of
the meter when there are multiple references to it. If this col‐
- umn is empty or is set to false, the rate will be shared across
- all rows that refer to the same Meter name. Conversely, when
- this column is set to true, each user of the same Meter will be
+ umn is empty or is set to false, the rate will be shared across
+ all rows that refer to the same Meter name. Conversely, when
+ this column is set to true, each user of the same Meter will be
rate-limited on its own.
external_ids: map of string-string pairs
@@ -2421,7 +2625,7 @@ Meter_Band TABLE
Logical_Router_Port TABLE
A port within an L3 logical router.
- Exactly one Logical_Router row must reference a given logical router
+ Exactly one Logical_Router row must reference a given logical router
port.
Summary:
@@ -2435,7 +2639,7 @@ Logical_Router_Port TABLE
Options for Physical VLAN MTU Issues:
options : reside-on-redirect-chassis
optional string, either true or false
- options : redirect-type optional string, either bridged or over‐
+ options : redirect-type optional string, either bridged or over‐
lay
ipv6_prefix set of strings
ipv6_ra_configs:
@@ -2457,13 +2661,13 @@ Logical_Router_Port TABLE
Options:
options : mcast_flood optional string, either true or false
options : requested-tnl-key
- optional string, containing an integer,
+ optional string, containing an integer,
in range 1 to 32,767
options : prefix_delegation
optional string, either true or false
options : prefix optional string, either true or false
options : route_table optional string
- options : gateway_mtu optional string, containing an integer,
+ options : gateway_mtu optional string, containing an integer,
in range 68 to 65,535
options : gateway_mtu_bypass
optional string
@@ -2471,28 +2675,30 @@ Logical_Router_Port TABLE
peer optional string
Common Columns:
external_ids map of string-string pairs
+ Status:
+ status : hosting-chassis optional string
Details:
name: string (must be unique within table)
A name for the logical router port.
- In addition to provide convenience for human interaction with
+ In addition to provide convenience for human interaction with
the northbound database, this column is used as reference by its
patch port in Logical_Switch_Port or another logical router port
in Logical_Router_Port.
- A logical router port may not have the same name as a logical
+ A logical router port may not have the same name as a logical
switch port, but the database schema cannot enforce this.
networks: set of 1 or more strings
- The IP addresses and netmasks of the router. For example,
- 192.168.0.1/24 indicates that the router’s IP address is
- 192.168.0.1 and that packets destined to 192.168.0.x should be
+ The IP addresses and netmasks of the router. For example,
+ 192.168.0.1/24 indicates that the router’s IP address is
+ 192.168.0.1 and that packets destined to 192.168.0.x should be
routed to this port.
- A logical router port always adds a link-local IPv6 address
- (fe80::/64) automatically generated from the interface’s MAC
- address using the modified EUI-64 format.
+ A logical router port always adds a link-local IPv6 address
+ (fe80::/64) automatically generated from the interface’s MAC ad‐
+ dress using the modified EUI-64 format.
mac: string
The Ethernet address that belongs to this router port.
@@ -2513,24 +2719,24 @@ Logical_Router_Port TABLE
exist for historical reasons. Both of them produce the same kind of OVN
southbound records and the same behavior in practice.
- If either of these are set, this logical router port represents a dis‐
- tributed gateway port that connects this router to a logical switch
+ If either of these are set, this logical router port represents a dis‐
+ tributed gateway port that connects this router to a logical switch
with a localnet port or a connection to another OVN deployment.
Also mentioned in the OVN architecture guide, distributed gateway ports
can also be used for scalability reasons in deployments where logical
switches are dedicated to chassises rather than distributed.
- The preferred way to configure a gateway is ha_chassis_group, but gate‐
- way_chassis is also supported for backward compatibility. Only one of
- these should be set at a time on a given LRP, since they configure the
+ The preferred way to configure a gateway is ha_chassis_group, but gate‐
+ way_chassis is also supported for backward compatibility. Only one of
+ these should be set at a time on a given LRP, since they configure the
same features.
Even when a gateway is configured, the logical router port still effec‐
tively resides on each chassis. However, due to the implications of the
use of L2 learning in the physical network, as well as the need to sup‐
port advanced features such as one-to-many NAT (aka IP masquerading), a
- subset of the logical router processing is handled in a centralized
+ subset of the logical router processing is handled in a centralized
manner on the gateway chassis.
There can be more than one distributed gateway ports configured on each
@@ -2538,26 +2744,26 @@ Logical_Router_Port TABLE
ing is not yet supported on logical routers with more than one distrib‐
uted gateway ports.
- For each distributed gateway port, it may have more than one gateway
- chassises. When more than one gateway chassis is specified, OVN only
- uses one at a time. OVN can rely on OVS BFD implementation to monitor
- gateway connectivity, preferring the highest-priority gateway that is
- online. Priorities are specified in the priority column of Gate‐
+ For each distributed gateway port, it may have more than one gateway
+ chassises. When more than one gateway chassis is specified, OVN only
+ uses one at a time. OVN can rely on OVS BFD implementation to monitor
+ gateway connectivity, preferring the highest-priority gateway that is
+ online. Priorities are specified in the priority column of Gate‐
way_Chassis or HA_Chassis.
- ovn-northd programs the external_mac rules specified in the LRP’s LR
- into the peer logical switch’s destination lookup on the chassis where
+ ovn-northd programs the external_mac rules specified in the LRP’s LR
+ into the peer logical switch’s destination lookup on the chassis where
the logical_port resides. In addition, the logical router’s MAC address
is automatically programmed in the peer logical switch’s destination
lookup flow on the gateway chasssis. If it is desired to generate gra‐
- tuitous ARPs for NAT addresses, then set the peer LSP’s options:nat-
- addresses to router.
+ tuitous ARPs for NAT addresses, then set the peer LSP’s options:nat-ad‐
+ dresses to router.
- OVN 20.03 and earlier supported a third way to configure distributed
- gateway ports using options:redirect-chassis to specify the gateway
+ OVN 20.03 and earlier supported a third way to configure distributed
+ gateway ports using options:redirect-chassis to specify the gateway
chassis. This method is no longer supported. Any remaining users should
switch to one of the newer methods instead. A gateway_chassis may be
- easily configured from the command line, e.g. ovn-nbctl lrp-set-gate‐
+ easily configured from the command line, e.g. ovn-nbctl lrp-set-gate‐
way-chassis lrp chassis.
ha_chassis_group: optional HA_Chassis_Group
@@ -2575,52 +2781,52 @@ Logical_Router_Port TABLE
Physical VLAN MTU Issues in the OVN architecture document. The follow‐
ing options, which are alternatives, provide solutions. Both of them
cause packets to be sent over localnet instead of tunnels, but they
- differ in whether some or all packets are sent this way. The most prom‐
- inent tradeoff between these options is that reside-on-redirect-chassis
- is easier to configure and that redirect-type performs better for east-
- west traffic.
+ differ in whether some or all packets are sent this way. The most
+ prominent tradeoff between these options is that reside-on-redi‐
+ rect-chassis is easier to configure and that redirect-type performs
+ better for east-west traffic.
- options : reside-on-redirect-chassis: optional string, either true or
+ options : reside-on-redirect-chassis: optional string, either true or
false
- If set to true, this option forces all traffic across the logi‐
- cal router port to pass through the gateway chassis using a hop
+ If set to true, this option forces all traffic across the logi‐
+ cal router port to pass through the gateway chassis using a hop
across a localnet port. This changes behavior in two ways:
- · Without this option, east-west traffic passes directly
- between source and destination chassis (or even within a
- single chassis, for co-located VMs). With this option,
+ • Without this option, east-west traffic passes directly
+ between source and destination chassis (or even within a
+ single chassis, for co-located VMs). With this option,
all east-west traffic passes through the gateway chassis.
- · Without this option, traffic between the gateway chassis
- and other chassis is encapsulated in tunnels. With this
+ • Without this option, traffic between the gateway chassis
+ and other chassis is encapsulated in tunnels. With this
option, traffic passes over a localnet interface.
- This option may usefully be set only on logical router ports
- that connect a distributed logical router to a logical switch
+ This option may usefully be set only on logical router ports
+ that connect a distributed logical router to a logical switch
with VIFs. It should not be set on a distributed gateway port.
- OVN honors this option only if the logical router has one and
- only one distributed gateway port and if the LRP’s peer switch
+ OVN honors this option only if the logical router has one and
+ only one distributed gateway port and if the LRP’s peer switch
has a localnet port.
options : redirect-type: optional string, either bridged or overlay
- If set to bridged on a distributed gateway port, this option
- causes OVN to redirect packets to the gateway chassis over a
- localnet port instead of a tunnel. The relevant chassis must
- share a localnet port.
-
- This feature requires the administrator or the CMS to configure
- each participating chassis with a unique Ethernet address for
- the logical router by setting ovn-chassis-mac-mappings in the
+ If set to bridged on a distributed gateway port, this option
+ causes OVN to redirect packets to the gateway chassis over a lo‐
+ calnet port instead of a tunnel. The relevant chassis must share
+ a localnet port.
+
+ This feature requires the administrator or the CMS to configure
+ each participating chassis with a unique Ethernet address for
+ the logical router by setting ovn-chassis-mac-mappings in the
Open vSwitch database, for use by ovn-controller.
- Setting this option to overlay or leaving it unset has no
- effect. This option may usefully be set only on a distributed
- gateway port when there is one and only one distributed gateway
+ Setting this option to overlay or leaving it unset has no ef‐
+ fect. This option may usefully be set only on a distributed
+ gateway port when there is one and only one distributed gateway
port on the logical router. It is otherwise ignored.
ipv6_prefix: set of strings
- This column contains IPv6 prefix obtained by prefix delegation
+ This column contains IPv6 prefix obtained by prefix delegation
router according to RFC 3633
ipv6_ra_configs:
@@ -2630,30 +2836,30 @@ Logical_Router_Port TABLE
tion requests.
ipv6_ra_configs : address_mode: optional string
- The address mode to be used for IPv6 address configuration. The
+ The address mode to be used for IPv6 address configuration. The
supported values are:
- · slaac: Address configuration using Router Advertisement
- (RA) packet. The IPv6 prefixes defined in the Logi‐
- cal_Router_Port table’s networks column will be included
+ • slaac: Address configuration using Router Advertisement
+ (RA) packet. The IPv6 prefixes defined in the Logi‐
+ cal_Router_Port table’s networks column will be included
in the RA’s ICMPv6 option - Prefix information.
- · dhcpv6_stateful: Address configuration using DHCPv6.
+ • dhcpv6_stateful: Address configuration using DHCPv6.
- · dhcpv6_stateless: Address configuration using Router
- Advertisement (RA) packet. Other IPv6 options are pro‐
- vided by DHCPv6.
+ • dhcpv6_stateless: Address configuration using Router Ad‐
+ vertisement (RA) packet. Other IPv6 options are provided
+ by DHCPv6.
ipv6_ra_configs : router_preference: optional string
Default Router Preference (PRF) indicates whether to prefer this
router over other default routers (RFC 4191). Possible values
are:
- · HIGH: mapped to 0x01 in RA PRF field
+ • HIGH: mapped to 0x01 in RA PRF field
- · MEDIUM: mapped to 0x00 in RA PRF field
+ • MEDIUM: mapped to 0x00 in RA PRF field
- · LOW: mapped to 0x11 in RA PRF field
+ • LOW: mapped to 0x11 in RA PRF field
ipv6_ra_configs : route_info: optional string
Route Info is used to configure Route Info Option sent in Router
@@ -2662,41 +2868,41 @@ Logical_Router_Port TABLE
given route (e.g: HIGH-aef1::11/48,LOW-aef2::11/96) Possible PRF
values are:
- · HIGH: mapped to 0x01 in RA PRF field
+ • HIGH: mapped to 0x01 in RA PRF field
- · MEDIUM: mapped to 0x00 in RA PRF field
+ • MEDIUM: mapped to 0x00 in RA PRF field
- · LOW: mapped to 0x11 in RA PRF field
+ • LOW: mapped to 0x11 in RA PRF field
ipv6_ra_configs : mtu: optional string
- The recommended MTU for the link. Default is 0, which means no
- MTU Option will be included in RA packet replied by ovn-con‐
+ The recommended MTU for the link. Default is 0, which means no
+ MTU Option will be included in RA packet replied by ovn-con‐
troller. Per RFC 2460, the mtu value is recommended no less than
1280, so any mtu value less than 1280 will be considered as no
MTU Option.
ipv6_ra_configs : send_periodic: optional string
- If set to true, then this router interface will send router
- advertisements periodically. The default is false.
+ If set to true, then this router interface will send router ad‐
+ vertisements periodically. The default is false.
ipv6_ra_configs : max_interval: optional string
The maximum number of seconds to wait between sending periodic
- router advertisements. This option has no effect if ipv6_ra_con‐
+ router advertisements. This option has no effect if ipv6_ra_con‐
figs:send_periodic is false. The default is 600.
ipv6_ra_configs : min_interval: optional string
- The minimum number of seconds to wait between sending periodic
- router advertisements. This option has no effect if ipv6_ra_con‐
+ The minimum number of seconds to wait between sending periodic
+ router advertisements. This option has no effect if ipv6_ra_con‐
figs:send_periodic is false. The default is one-third of
ipv6_ra_configs:max_interval, i.e. 200 seconds if that key is
unset.
ipv6_ra_configs : rdnss: optional string
- IPv6 address of RDNSS server announced in RA packets. At the
- moment OVN supports just one RDNSS server.
+ IPv6 address of RDNSS server announced in RA packets. At the mo‐
+ ment OVN supports just one RDNSS server.
ipv6_ra_configs : dnssl: optional string
- DNS Search List announced in RA packets. Multiple DNS Search
+ DNS Search List announced in RA packets. Multiple DNS Search
List must be ’comma’ separated (e.g. "a.b.c, d.e.f")
Options:
@@ -2714,24 +2920,24 @@ Logical_Router_Port TABLE
options : requested-tnl-key: optional string, containing an integer, in
range 1 to 32,767
- Configures the port binding tunnel key for the port. Usually
- this is not needed because ovn-northd will assign an unique key
- for each port by itself. However, if it is configured,
+ Configures the port binding tunnel key for the port. Usually
+ this is not needed because ovn-northd will assign an unique key
+ for each port by itself. However, if it is configured,
ovn-northd honors the configured value.
options : prefix_delegation: optional string, either true or false
- If set to true, enable IPv6 prefix delegation state machine on
- this logical router port (RFC3633). IPv6 prefix delegation is
+ If set to true, enable IPv6 prefix delegation state machine on
+ this logical router port (RFC3633). IPv6 prefix delegation is
available just on a gateway router or on a gateway router port.
options : prefix: optional string, either true or false
- If set to true, this interface will receive an IPv6 prefix
- according to RFC3663
+ If set to true, this interface will receive an IPv6 prefix ac‐
+ cording to RFC3663
options : route_table: optional string
- Designates lookup Logical_Router_Static_Routes with specified
- route_table value. Routes to directly connected networks from
- same Logical Router and routes without route_table option set
+ Designates lookup Logical_Router_Static_Routes with specified
+ route_table value. Routes to directly connected networks from
+ same Logical Router and routes without route_table option set
have higher priority than routes with route_table option set.
options : gateway_mtu: optional string, containing an integer, in range
@@ -2744,25 +2950,25 @@ Logical_Router_Port TABLE
This allows for Path MTU Discovery.
options : gateway_mtu_bypass: optional string
- When configured, represents a match expression, in the same
- expression language used for the match column in the OVN South‐
- bound database’s Logical_Flow table. Packets matching this
- expression will bypass the length check configured through the
- options:gateway_mtu option.
+ When configured, represents a match expression, in the same ex‐
+ pression language used for the match column in the OVN South‐
+ bound database’s Logical_Flow table. Packets matching this ex‐
+ pression will bypass the length check configured through the op‐
+ tions:gateway_mtu option.
Attachment:
A given router port serves one of two purposes:
- · To attach a logical switch to a logical router. A logical
- router port of this type is referenced by exactly one
- Logical_Switch_Port of type router. The value of name is
- set as router-port in column options of Logi‐
+ • To attach a logical switch to a logical router. A logical
+ router port of this type is referenced by exactly one
+ Logical_Switch_Port of type router. The value of name is
+ set as router-port in column options of Logi‐
cal_Switch_Port. In this case peer column is empty.
- · To connect one logical router to another. This requires a
+ • To connect one logical router to another. This requires a
pair of logical router ports, each connected to a differ‐
- ent router. Each router port in the pair specifies the
+ ent router. Each router port in the pair specifies the
other in its peer column. No Logical_Switch refers to the
router port.
@@ -2778,9 +2984,22 @@ Logical_Router_Port TABLE
external_ids: map of string-string pairs
See External IDs at the beginning of this document.
- The ovn-northd program copies all these pairs into the exter‐
+ The ovn-northd program copies all these pairs into the exter‐
nal_ids column of the Port_Binding table in OVN_Southbound data‐
base.
+
+ Status:
+
+ Additional status about the logical router port.
+
+ status : hosting-chassis: optional string
+ This option is populated by ovn-northd.
+
+ When a distributed gateway port is bound to a location in the
+ OVN Southbound database Port_Binding ovn-northd will populate
+ this key with the name of the Chassis that is currently hosting
+ this port.
+
Logical_Router_Static_Route TABLE
Each record represents a static route.
@@ -2818,10 +3037,10 @@ Logical_Router_Static_Route TABLE
make routing decisions. This setting must be one of the follow‐
ing strings:
- · src-ip: This policy sends the packet to the nexthop when
+ • src-ip: This policy sends the packet to the nexthop when
the packet’s source IP address matches ip_prefix.
- · dst-ip: This policy sends the packet to the nexthop when
+ • dst-ip: This policy sends the packet to the nexthop when
the packet’s destination IP address matches ip_prefix.
If not specified, the default is dst-ip.
@@ -2838,7 +3057,7 @@ Logical_Router_Static_Route TABLE
will automatically figure this out based on the nexthop. When
this is specified and there are multiple IP addresses on the
router port and none of them are in the same subnet of nexthop,
- OVN chooses the first IP address as the one via which the nex‐
+ OVN chooses the first IP address as the one via which the nex‐
thop is reachable.
bfd: optional weak reference to BFD
@@ -2847,21 +3066,21 @@ Logical_Router_Static_Route TABLE
route_table: string
Any string to place route to separate routing table. If Logical
Router Port has configured value in options:route_table other
- than empty string, OVN performs route lookup for all packets
- entering Logical Router ingress pipeline from this port in the
+ than empty string, OVN performs route lookup for all packets en‐
+ tering Logical Router ingress pipeline from this port in the
following manner:
- · 1. First lookup among "global" routes: routes without
- route_table value set and routes to directly connected
+ • 1. First lookup among "global" routes: routes without
+ route_table value set and routes to directly connected
networks.
- · 2. Next lookup among routes with same route_table value
+ • 2. Next lookup among routes with same route_table value
as specified in LRP’s options:route_table field.
external_ids : ic-learned-route: optional string
- ovn-ic populates this key if the route is learned from the
- global OVN_IC_Southbound database. In this case the value will
- be set to the uuid of the row in Route table of the
+ ovn-ic populates this key if the route is learned from the
+ global OVN_IC_Southbound database. In this case the value will
+ be set to the uuid of the row in Route table of the
OVN_IC_Southbound database.
Common Columns:
@@ -2872,7 +3091,7 @@ Logical_Router_Static_Route TABLE
Common options:
options: map of string-string pairs
- This column provides general key/value settings. The supported
+ This column provides general key/value settings. The supported
options are described individually below.
options : ecmp_symmetric_reply: optional string
@@ -2887,7 +3106,7 @@ Logical_Router_Static_Route TABLE
In case ovn-interconnection has been learned this route, it will
have its origin set: either "connected" or "static". This key is
supposed to be written only by ovn-ic daemon. ovn-northd then
- checks this value when generating Logical Flows. Logi‐
+ checks this value when generating Logical Flows. Logi‐
cal_Router_Static_Route records with same ip_prefix within same
Logical Router will have next lookup order based on origin key
value:
@@ -2895,13 +3114,12 @@ Logical_Router_Static_Route TABLE
1. connected
2. static
-
Logical_Router_Policy TABLE
Each row in this table represents one routing policy for a logical
router that points to it through its policies column. The action column
- for the highest-priority matching row in this table determines a
- packet’s treatment. If no row matches, packets are allowed by default.
- (Default-deny treatment is possible: add a rule with priority 0, 1 as
+ for the highest-priority matching row in this table determines a
+ packet’s treatment. If no row matches, packets are allowed by default.
+ (Default-deny treatment is possible: add a rule with priority 0, 1 as
match, and drop as action.)
Summary:
@@ -2910,53 +3128,58 @@ Logical_Router_Policy TABLE
action string, one of allow, drop, or reroute
nexthop optional string
nexthops set of strings
+ bfd_sessions set of weak reference to BFDs
options : pkt_mark optional string
Common Columns:
external_ids map of string-string pairs
Details:
priority: integer, in range 0 to 32,767
- The routing policy’s priority. Rules with numerically higher
- priority take precedence over those with lower. A rule is
+ The routing policy’s priority. Rules with numerically higher
+ priority take precedence over those with lower. A rule is
uniquely identified by the priority and match string.
match: string
- The packets that the routing policy should match, in the same
- expression language used for the match column in the OVN South‐
+ The packets that the routing policy should match, in the same
+ expression language used for the match column in the OVN South‐
bound database’s Logical_Flow table.
- By default all traffic is allowed. When writing a more restric‐
- tive policy, it is important to remember to allow flows such as
+ By default all traffic is allowed. When writing a more restric‐
+ tive policy, it is important to remember to allow flows such as
ARP and IPv6 neighbor discovery packets.
action: string, one of allow, drop, or reroute
The action to take when the routing policy matches:
- · allow: Forward the packet.
+ • allow: Forward the packet.
- · drop: Silently drop the packet.
+ • drop: Silently drop the packet.
- · reroute: Reroute packet to nexthop or nexthops.
+ • reroute: Reroute packet to nexthop or nexthops.
nexthop: optional string
Note: This column is deprecated in favor of nexthops.
- Next-hop IP address for this route, which should be the IP
- address of a connected router port or the IP address of a logi‐
- cal port.
+ Next-hop IP address for this route, which should be the IP ad‐
+ dress of a connected router port or the IP address of a logical
+ port.
nexthops: set of strings
- Next-hop ECMP IP addresses for this route. Each IP in the list
- should be the IP address of a connected router port or the IP
+ Next-hop ECMP IP addresses for this route. Each IP in the list
+ should be the IP address of a connected router port or the IP
address of a logical port.
One IP from the list is selected as next hop.
+ bfd_sessions: set of weak reference to BFDs
+ Reference to BFD row if the route policy has associated some BFD
+ sessions.
+
options : pkt_mark: optional string
Marks the packet with the value specified when the router policy
- is applied. CMS can inspect this packet marker and take some
- decisions if desired. This value is not preserved when the
- packet goes out on the wire.
+ is applied. CMS can inspect this packet marker and take some de‐
+ cisions if desired. This value is not preserved when the packet
+ goes out on the wire.
Common Columns:
@@ -2967,7 +3190,7 @@ NAT TABLE
Each record represents a NAT rule.
Summary:
- type string, one of dnat, dnat_and_snat, or
+ type string, one of dnat, dnat_and_snat, or
snat
external_ip string
external_mac optional string
@@ -2976,7 +3199,7 @@ NAT TABLE
logical_port optional string
allowed_ext_ips optional Address_Set
exempted_ext_ips optional Address_Set
- gateway_port optional weak reference to Logi‐
+ gateway_port optional weak reference to Logi‐
cal_Router_Port
options : stateless optional string
options : add_route optional string
@@ -2987,20 +3210,20 @@ NAT TABLE
type: string, one of dnat, dnat_and_snat, or snat
Type of the NAT rule.
- · When type is dnat, the externally visible IP address
- external_ip is DNATted to the IP address logical_ip in
- the logical space.
+ • When type is dnat, the externally visible IP address ex‐
+ ternal_ip is DNATted to the IP address logical_ip in the
+ logical space.
- · When type is snat, IP packets with their source IP
- address that either matches the IP address in logical_ip
- or is in the network provided by logical_ip is SNATed
- into the IP address in external_ip.
+ • When type is snat, IP packets with their source IP ad‐
+ dress that either matches the IP address in logical_ip or
+ is in the network provided by logical_ip is SNATed into
+ the IP address in external_ip.
- · When type is dnat_and_snat, the externally visible IP
- address external_ip is DNATted to the IP address logi‐
- cal_ip in the logical space. In addition, IP packets with
- the source IP address that matches logical_ip is SNATed
- into the IP address in external_ip.
+ • When type is dnat_and_snat, the externally visible IP ad‐
+ dress external_ip is DNATted to the IP address logical_ip
+ in the logical space. In addition, IP packets with the
+ source IP address that matches logical_ip is SNATed into
+ the IP address in external_ip.
external_ip: string
An IPv4 address.
@@ -3012,11 +3235,11 @@ NAT TABLE
This must be specified in order for the NAT rule to be processed
in a distributed manner on all chassis. If this is not specified
for a NAT rule on a distributed router, then this NAT rule will
- be processed in a centralized manner on the gateway port
- instance on the gateway chassis.
+ be processed in a centralized manner on the gateway port in‐
+ stance on the gateway chassis.
This MAC address must be unique on the logical switch that the
- gateway port is attached to. If the MAC address used on the log‐
+ gateway port is attached to. If the MAC address used on the log‐
ical_port is globally unique, then that MAC address can be spec‐
ified as this external_mac.
@@ -3024,8 +3247,8 @@ NAT TABLE
L4 source port range
Range of ports, from which a port number will be picked that
- will replace the source port of to be NATed packet. This is
- basically PAT (port address translation).
+ will replace the source port of to be NATed packet. This is ba‐
+ sically PAT (port address translation).
Value of the column is in the format, port_lo-port_hi. For exam‐
ple: external_port_range : "1-30000"
@@ -3041,15 +3264,15 @@ NAT TABLE
This is only used on distributed routers. This must be specified
in order for the NAT rule to be processed in a distributed man‐
ner on all chassis. If this is not specified for a NAT rule on a
- distributed router, then this NAT rule will be processed in a
- centralized manner on the gateway port instance on the gateway
+ distributed router, then this NAT rule will be processed in a
+ centralized manner on the gateway port instance on the gateway
chassis.
allowed_ext_ips: optional Address_Set
- It represents Address Set of external ips that NAT rule is
- applicable to. For SNAT type NAT rules, this refers to destina‐
- tion addresses. For DNAT type NAT rules, this refers to source
- addresses.
+ It represents Address Set of external ips that NAT rule is ap‐
+ plicable to. For SNAT type NAT rules, this refers to destination
+ addresses. For DNAT type NAT rules, this refers to source ad‐
+ dresses.
This configuration overrides the default NAT behavior of apply‐
ing a rule solely based on internal IP. Without this configura‐
@@ -3080,49 +3303,48 @@ NAT TABLE
with RULE2, then a logical ip which matches both 50.0.0.0/24 and
50.0.0.0/25 may get the RULE2 applied to it instead of RULE1.
- allowed_ext_ips and exempted_ext_ips are mutually exclusive to
- each other. If both Address Sets are set for a rule, then the
+ allowed_ext_ips and exempted_ext_ips are mutually exclusive to
+ each other. If both Address Sets are set for a rule, then the
NAT rule is not considered.
gateway_port: optional weak reference to Logical_Router_Port
- A distributed gateway port in the Logical_Router_Port table
+ A distributed gateway port in the Logical_Router_Port table
where the NAT rule needs to be applied.
- When multiple distributed gateway ports are configured on a Log‐
+ When multiple distributed gateway ports are configured on a Log‐
ical_Router, applying a NAT rule at each of the distributed
gateway ports might not be desired. Consider the case where a
logical router has 2 distributed gateway port, one with networks
- 50.0.0.10/24 and the other with networks 60.0.0.10/24. If the
- logical router has a NAT rule of type snat, logical_ip
- 10.1.1.0/24 and external_ip 50.1.1.20/24, the rule needs to be
+ 50.0.0.10/24 and the other with networks 60.0.0.10/24. If the
+ logical router has a NAT rule of type snat, logical_ip
+ 10.1.1.0/24 and external_ip 50.1.1.20/24, the rule needs to be
selectively applied on matching packets entering/leaving through
the distributed gateway port with networks 50.0.0.10/24.
When a logical router has multiple distributed gateway ports and
- this column is not set for a NAT rule, then the rule will be
- applied at the distributed gateway port which is in the same
- network as the external_ip of the NAT rule, if such a router
- port exists. If logical router has a single distributed gateway
- port and this column is not set for a NAT rule, the rule will be
- applied at the distributed gateway port even if the router port
- is not in the same network as the external_ip of the NAT rule.
+ this column is not set for a NAT rule, then the rule will be ap‐
+ plied at the distributed gateway port which is in the same net‐
+ work as the external_ip of the NAT rule, if such a router port
+ exists. If logical router has a single distributed gateway port
+ and this column is not set for a NAT rule, the rule will be ap‐
+ plied at the distributed gateway port even if the router port is
+ not in the same network as the external_ip of the NAT rule.
options : stateless: optional string
- Indicates if a dnat_and_snat rule should lead to connection
+ Indicates if a dnat_and_snat rule should lead to connection
tracking state or not.
options : add_route: optional string
- If set to true, then neighbor routers will have logical flows
- added that will allow for routing to the NAT address. It also
- will have ARP resolution logical flows added. By setting this
- option, it means there is no reason to create a Logi‐
- cal_Router_Static_Route from neighbor routers to this NAT
- address. It also means that no ARP request is required for
- neighbor routers to learn the IP-MAC mapping for this NAT
- address. This option only applies to NATs of type dnat and
- dnat_and_snat. For more information about what flows are added
- for IP routes, please see the ovn-northd manpage section on IP
- Routing.
+ If set to true, then neighbor routers will have logical flows
+ added that will allow for routing to the NAT address. It also
+ will have ARP resolution logical flows added. By setting this
+ option, it means there is no reason to create a Logi‐
+ cal_Router_Static_Route from neighbor routers to this NAT ad‐
+ dress. It also means that no ARP request is required for neigh‐
+ bor routers to learn the IP-MAC mapping for this NAT address.
+ This option only applies to NATs of type dnat and dnat_and_snat.
+ For more information about what flows are added for IP routes,
+ please see the ovn-northd manpage section on IP Routing.
Common Columns:
@@ -3130,14 +3352,13 @@ NAT TABLE
See External IDs at the beginning of this document.
DHCP_Options TABLE
- OVN implements native DHCPv4 support which caters to the common use
- case of providing an IPv4 address to a booting instance by providing
- stateless replies to DHCPv4 requests based on statically configured
- address mappings. To do this it allows a short list of DHCPv4 options
- to be configured and applied at each compute host running ovn-con‐
- troller.
-
- OVN also implements native DHCPv6 support which provides stateless
+ OVN implements native DHCPv4 support which caters to the common use
+ case of providing an IPv4 address to a booting instance by providing
+ stateless replies to DHCPv4 requests based on statically configured ad‐
+ dress mappings. To do this it allows a short list of DHCPv4 options to
+ be configured and applied at each compute host running ovn-controller.
+
+ OVN also implements native DHCPv6 support which provides stateless
replies to DHCPv6 requests.
Summary:
@@ -3146,7 +3367,7 @@ DHCP_Options TABLE
Mandatory DHCPv4 options:
options : server_id optional string
options : server_mac optional string
- options : lease_time optional string, containing an integer,
+ options : lease_time optional string, containing an integer,
in range 0 to 4,294,967,295
IPv4 DHCP Options:
options : router optional string
@@ -3174,24 +3395,24 @@ DHCP_Options TABLE
optional string, either 0 or 1
options : ethernet_encap optional string, either 0 or 1
Integer DHCP Options:
- options : default_ttl optional string, containing an integer,
+ options : default_ttl optional string, containing an integer,
in range 0 to 255
- options : tcp_ttl optional string, containing an integer,
+ options : tcp_ttl optional string, containing an integer,
in range 0 to 255
- options : mtu optional string, containing an integer,
+ options : mtu optional string, containing an integer,
in range 68 to 65,535
- options : T1 optional string, containing an integer,
+ options : T1 optional string, containing an integer,
in range 68 to 4,294,967,295
- options : T2 optional string, containing an integer,
+ options : T2 optional string, containing an integer,
in range 68 to 4,294,967,295
options : arp_cache_timeout
- optional string, containing an integer,
+ optional string, containing an integer,
in range 0 to 255
options : tcp_keepalive_interval
- optional string, containing an integer,
+ optional string, containing an integer,
in range 0 to 255
options : netbios_node_type
- optional string, containing an integer,
+ optional string, containing an integer,
in range 0 to 255
String DHCP Options:
options : wpad optional string
@@ -3219,19 +3440,20 @@ DHCP_Options TABLE
options : domain_search optional string
options : dhcpv6_stateless
optional string
+ options : fqdn optional string
Common Columns:
external_ids map of string-string pairs
Details:
cidr: string
- The DHCPv4/DHCPv6 options will be included if the logical port
+ The DHCPv4/DHCPv6 options will be included if the logical port
has its IP address in this cidr.
DHCPv4 options:
- The CMS should define the set of DHCPv4 options as key/value pairs in
- the options column of this table. For ovn-controller to include these
- DHCPv4 options, the dhcpv4_options of Logical_Switch_Port should refer
+ The CMS should define the set of DHCPv4 options as key/value pairs in
+ the options column of this table. For ovn-controller to include these
+ DHCPv4 options, the dhcpv4_options of Logical_Switch_Port should refer
to an entry in this table.
Mandatory DHCPv4 options:
@@ -3240,13 +3462,13 @@ DHCP_Options TABLE
options : server_id: optional string
The IP address for the DHCP server to use. This should be in the
- subnet of the offered IP. This is also included in the DHCP
- offer as option 54, ``server identifier.’’
+ subnet of the offered IP. This is also included in the DHCP of‐
+ fer as option 54, ``server identifier.’’
options : server_mac: optional string
The Ethernet address for the DHCP server to use.
- options : lease_time: optional string, containing an integer, in range
+ options : lease_time: optional string, containing an integer, in range
0 to 4,294,967,295
The offered lease time in seconds,
@@ -3254,14 +3476,14 @@ DHCP_Options TABLE
IPv4 DHCP Options:
- Below are the supported DHCPv4 options whose values are an IPv4
- address, e.g. 192.168.1.1. Some options accept multiple IPv4 addresses
- enclosed within curly braces, e.g. {192.168.1.2, 192.168.1.3}. Please
+ Below are the supported DHCPv4 options whose values are an IPv4 ad‐
+ dress, e.g. 192.168.1.1. Some options accept multiple IPv4 addresses
+ enclosed within curly braces, e.g. {192.168.1.2, 192.168.1.3}. Please
refer to RFC 2132 for more details on DHCPv4 options and their codes.
options : router: optional string
- The IP address of a gateway for the client to use. This should
- be in the subnet of the offered IP. The DHCPv4 option code for
+ The IP address of a gateway for the client to use. This should
+ be in the subnet of the offered IP. The DHCPv4 option code for
this option is 3.
options : netmask: optional string
@@ -3305,7 +3527,7 @@ DHCP_Options TABLE
Example: {30.0.0.0/24,10.0.0.10, 0.0.0.0/0,10.0.0.1}
options : ms_classless_static_route: optional string
- The DHCPv4 option code for this option is 249. This option is
+ The DHCPv4 option code for this option is 249. This option is
similar to classless_static_route supported by Microsoft Windows
DHCPv4 clients.
@@ -3335,32 +3557,32 @@ DHCP_Options TABLE
0 to 255
The DHCPv4 option code for this option is 23.
- options : tcp_ttl: optional string, containing an integer, in range 0
+ options : tcp_ttl: optional string, containing an integer, in range 0
to 255
The DHCPv4 option code for this option is 37.
- options : mtu: optional string, containing an integer, in range 68 to
+ options : mtu: optional string, containing an integer, in range 68 to
65,535
The DHCPv4 option code for this option is 26.
- options : T1: optional string, containing an integer, in range 68 to
+ options : T1: optional string, containing an integer, in range 68 to
4,294,967,295
- This specifies the time interval from address assignment until
+ This specifies the time interval from address assignment until
the client begins trying to renew its address. The DHCPv4 option
code for this option is 58.
- options : T2: optional string, containing an integer, in range 68 to
+ options : T2: optional string, containing an integer, in range 68 to
4,294,967,295
- This specifies the time interval from address assignment until
- the client begins trying to rebind its address. The DHCPv4
- option code for this option is 59.
+ This specifies the time interval from address assignment until
+ the client begins trying to rebind its address. The DHCPv4 op‐
+ tion code for this option is 59.
options : arp_cache_timeout: optional string, containing an integer, in
range 0 to 255
The DHCPv4 option code for this option is 35. This option speci‐
fies the timeout in seconds for ARP cache entries.
- options : tcp_keepalive_interval: optional string, containing an inte‐
+ options : tcp_keepalive_interval: optional string, containing an inte‐
ger, in range 0 to 255
The DHCPv4 option code for this option is 38. This option speci‐
fies the interval that the client TCP should wait before sending
@@ -3375,18 +3597,18 @@ DHCP_Options TABLE
These options accept a string value.
options : wpad: optional string
- The DHCPv4 option code for this option is 252. This option is
- used as part of web proxy auto discovery to provide a URL for a
+ The DHCPv4 option code for this option is 252. This option is
+ used as part of web proxy auto discovery to provide a URL for a
web proxy.
options : bootfile_name: optional string
- The DHCPv4 option code for this option is 67. This option is
+ The DHCPv4 option code for this option is 67. This option is
used to identify a bootfile.
options : path_prefix: optional string
The DHCPv4 option code for this option is 210. In PXELINUX’ case
- this option is used to set a common path prefix, instead of
- deriving it from the bootfile name.
+ this option is used to set a common path prefix, instead of de‐
+ riving it from the bootfile name.
options : tftp_server_address: optional string
The DHCPv4 option code for this option is 150. The option con‐
@@ -3395,11 +3617,11 @@ DHCP_Options TABLE
this requirement is option 66 (tftp_server).
options : hostname: optional string
- The DHCPv4 option code for this option is 12. If set, indicates
- the DHCPv4 option "Hostname". Alternatively, this option can be
- configured in options:hostname column in table Logi‐
- cal_Switch_Port. If Hostname option value is set in both con‐
- flicting Logical_Switch_Port and DHCP_Options tables, Logi‐
+ The DHCPv4 option code for this option is 12. If set, indicates
+ the DHCPv4 option "Hostname". Alternatively, this option can be
+ configured in options:hostname column in table Logi‐
+ cal_Switch_Port. If Hostname option value is set in both con‐
+ flicting Logical_Switch_Port and DHCP_Options tables, Logi‐
cal_Switch_Port takes precedence.
options : domain_name: optional string
@@ -3408,7 +3630,7 @@ DHCP_Options TABLE
names via the Domain Name System.
options : bootfile_name_alt: optional string
- "bootfile_name_alt" option is used to support iPXE. When both
+ "bootfile_name_alt" option is used to support iPXE. When both
"bootfile_name" and "bootfile_name_alt" are provided by the CMS,
"bootfile_name" will be used for option 67 if the dhcp request
contains etherboot option (175), otherwise "bootfile_name_alt"
@@ -3427,7 +3649,7 @@ DHCP_Options TABLE
DHCP Options of type domains:
- These options accept string value which is a comma separated list of
+ These options accept string value which is a comma separated list of
domain names. The domain names are encoded based on RFC 1035.
options : domain_search_list: optional string
@@ -3435,28 +3657,28 @@ DHCP_Options TABLE
DHCPv6 options:
- OVN also implements native DHCPv6 support. The CMS should define the
- set of DHCPv6 options as key/value pairs. The define DHCPv6 options
- will be included in the DHCPv6 response to the DHCPv6
- Solicit/Request/Confirm packet from the logical ports having the IPv6
- addresses in the cidr.
+ OVN also implements native DHCPv6 support. The CMS should define the
+ set of DHCPv6 options as key/value pairs. The define DHCPv6 options
+ will be included in the DHCPv6 response to the DHCPv6 Solicit/Re‐
+ quest/Confirm packet from the logical ports having the IPv6 addresses
+ in the cidr.
Mandatory DHCPv6 options:
The following options must be defined.
options : server_id: optional string
- The Ethernet address for the DHCP server to use. This is also
- included in the DHCPv6 reply as option 2, ``Server Identifier’’
- to carry a DUID identifying a server between a client and a
- server. ovn-controller defines DUID based on Link-layer Address
+ The Ethernet address for the DHCP server to use. This is also
+ included in the DHCPv6 reply as option 2, ``Server Identifier’’
+ to carry a DUID identifying a server between a client and a
+ server. ovn-controller defines DUID based on Link-layer Address
[DUID-LL].
IPv6 DHCPv6 options:
- Below are the supported DHCPv6 options whose values are an IPv6
- address, e.g. aef0::4. Some options accept multiple IPv6 addresses
- enclosed within curly braces, e.g. {aef0::4, aef0::5}. Please refer to
+ Below are the supported DHCPv6 options whose values are an IPv6 ad‐
+ dress, e.g. aef0::4. Some options accept multiple IPv6 addresses en‐
+ closed within curly braces, e.g. {aef0::4, aef0::5}. Please refer to
RFC 3315 for more details on DHCPv6 options and their codes.
options : dns_server: optional string
@@ -3469,33 +3691,37 @@ DHCP_Options TABLE
options : domain_search: optional string
The DHCPv6 option code for this option is 24. This option speci‐
- fies the domain search list the client should use to resolve
+ fies the domain search list the client should use to resolve
hostnames with DNS.
Example: "ovn.org".
options : dhcpv6_stateless: optional string
- This option specifies the OVN native DHCPv6 will work in state‐
- less mode, which means OVN native DHCPv6 will not offer IPv6
- addresses for VM/VIF ports, but only reply other configurations,
+ This option specifies the OVN native DHCPv6 will work in state‐
+ less mode, which means OVN native DHCPv6 will not offer IPv6 ad‐
+ dresses for VM/VIF ports, but only reply other configurations,
such as DNS and domain search list. When setting this option
with string value "true", VM/VIF will configure IPv6 addresses
by stateless way. Default value for this option is false.
+ options : fqdn: optional string
+ The DHCPv6 option code for this option is 39. If set, indicates
+ the DHCPv6 option "FQDN".
+
Common Columns:
external_ids: map of string-string pairs
See External IDs at the beginning of this document.
Connection TABLE
- Configuration for a database connection to an Open vSwitch database
+ Configuration for a database connection to an Open vSwitch database
(OVSDB) client.
- This table primarily configures the Open vSwitch database server
+ This table primarily configures the Open vSwitch database server
(ovsdb-server).
- The Open vSwitch database server can initiate and maintain active con‐
- nections to remote clients. It can also listen for database connec‐
+ The Open vSwitch database server can initiate and maintain active con‐
+ nections to remote clients. It can also listen for database connec‐
tions.
Summary:
@@ -3507,17 +3733,17 @@ Connection TABLE
Status:
is_connected boolean
status : last_error optional string
- status : state optional string, one of ACTIVE, BACKOFF,
+ status : state optional string, one of ACTIVE, BACKOFF,
CONNECTING, IDLE, or VOID
- status : sec_since_connect optional string, containing an integer,
+ status : sec_since_connect optional string, containing an integer,
at least 0
status : sec_since_disconnect
- optional string, containing an integer,
+ 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,
+ status : n_connections optional string, containing an integer,
at least 2
status : bound_port optional string, containing an integer
Common Columns:
@@ -3533,9 +3759,9 @@ Connection TABLE
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
+ The specified SSL port on the host at the given host,
+ which can either be a DNS name (if built with unbound li‐
+ brary) 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 ta‐
ble.
@@ -3547,9 +3773,9 @@ Connection TABLE
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.
+ which can either be a DNS name (if built with unbound li‐
+ brary) 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.
@@ -3557,8 +3783,8 @@ Connection TABLE
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
+ DNS name (if built with unbound library) or an IP ad‐
+ dress, 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
@@ -3575,13 +3801,13 @@ Connection TABLE
ptcp:[port][:host]
Listens for connections on the specified TCP port. Spec‐
ify 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.
+ 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 re‐
+ solved 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.
@@ -3591,17 +3817,17 @@ Connection TABLE
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.
+ Maximum number of milliseconds to wait between connection at‐
+ tempts. 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 recon‐
- nect. Default is implementation-specific. A value of 0 disables
+ 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 recon‐
+ nect. Default is implementation-specific. A value of 0 disables
inactivity probes.
Status:
@@ -3610,12 +3836,12 @@ Connection TABLE
in the status columns may be updated depends on the target type.
When target specifies a connection method that listens for inbound con‐
- nections (e.g. ptcp: or punix:), both n_connections and is_connected
+ nections (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 omit‐
+ 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 omit‐
ted.
is_connected: boolean
@@ -3626,7 +3852,7 @@ Connection TABLE
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,
+ status : state: optional string, one of ACTIVE, BACKOFF, CONNECTING,
IDLE, or VOID
The state of the connection to the manager:
@@ -3642,78 +3868,88 @@ Connection TABLE
IDLE Connection is idle. Waiting for response to keep-alive.
- These values may change in the future. They are provided only
+ These values may change in the future. They are provided only
for human consumption.
- status : sec_since_connect: optional string, containing an integer, at
+ 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,
+ 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 dis‐
+ The amount of time since this client last disconnected from the
+ database (in seconds). Value is empty if client has never dis‐
connected.
status : locks_held: optional string
- Space-separated list of the names of OVSDB locks that the con‐
- nection holds. Omitted if the connection does not hold any
+ Space-separated list of the names of OVSDB locks that the con‐
+ nection 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 con‐
- nection is currently waiting to acquire. Omitted if the connec‐
+ Space-separated list of the names of OVSDB locks that the con‐
+ nection is currently waiting to acquire. Omitted if the connec‐
tion is not waiting for any locks.
status : locks_lost: optional string
- Space-separated list of the names of OVSDB locks that the con‐
- nection has had stolen by another OVSDB client. Omitted if no
+ Space-separated list of the names of OVSDB locks that the con‐
+ nection 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
+ 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 con‐
+ When target specifies a connection method that listens for in‐
+ bound connections (e.g. ptcp: or pssl:) and more than one con‐
nection 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
+ 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
+ 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
-
DNS TABLE
- Each row in this table stores the DNS records. The Logical_Switch ta‐
+ Each row in this table stores the DNS records. The Logical_Switch ta‐
ble’s dns_records references these records.
Summary:
records map of string-string pairs
+ options : ovn-owned optional string
external_ids map of string-string pairs
Details:
records: map of string-string pairs
Key-value pair of DNS records with DNS query name as the key and
value as a string of IP address(es) separated by comma or space.
- For PTR requests, the key-value pair can be Reverse IPv4
- address.in-addr.arpa and the value DNS domain name. For IPv6
- addresses, the key has to be Reverse IPv6 address.ip6.arpa.
+ For PTR requests, the key-value pair can be Reverse IPv4 ad‐
+ dress.in-addr.arpa and the value DNS domain name. For IPv6 ad‐
+ dresses, the key has to be Reverse IPv6 address.ip6.arpa.
Example: "vm1.ovn.org" = "10.0.0.4 aef0::4"
Example: "4.0.0.10.in-addr.arpa" = "vm1.ovn.org"
+ options : ovn-owned: optional string
+ If set to true, then the OVN will be the main responsible for
+ DNS Records within this row.
+
+ A DNS row with this option set to true can be created for do‐
+ mains that the user needs to configure locally and don’t care
+ about IPv6 only interested in IPv4 or vice versa. This will let
+ ovn send IPv4 DNS reply and reject/ignore IPv6 queries to save
+ the waiting for a timeout on those uninteresting queries.
+
external_ids: map of string-string pairs
See External IDs at the beginning of this document.
@@ -3738,27 +3974,27 @@ SSL TABLE
certificate: string
Name of a PEM file containing a certificate, signed by the cer‐
tificate authority (CA) used by the controller and manager, that
- certifies the switch’s private key, identifying a trustworthy
+ 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
+ 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 bootstrap‐
+ 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 im‐
+ mediately 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 bootstrap‐
ping.
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.
+ List of SSL protocols to be enabled for SSL connections. The de‐
+ fault when this option is omitted is TLSv1,TLSv1.1,TLSv1.2.
ssl_ciphers: string
List of ciphers (in OpenSSL cipher string format) to be sup‐
@@ -3771,7 +4007,6 @@ SSL TABLE
at the beginning of this document.
external_ids: map of string-string pairs
-
Gateway_Chassis TABLE
Association of a chassis to a logical router port. The traffic going
out through an specific router port will be redirected to a chassis, or
@@ -3798,8 +4033,8 @@ Gateway_Chassis TABLE
name column of the Chassis table in the OVN_Southbound database.
priority: integer, in range 0 to 32,767
- This is the priority of a chassis among all Gateway_Chassis
- belonging to the same logical router port.
+ This is the priority of a chassis among all Gateway_Chassis be‐
+ longing to the same logical router port.
options: map of string-string pairs
Reserved for future use.
@@ -3811,11 +4046,11 @@ Gateway_Chassis TABLE
HA_Chassis_Group TABLE
Table representing a group of chassis which can provide high availabil‐
- ity services. Each chassis in the group is represented by the table
- HA_Chassis. The HA chassis with highest priority will be the master of
- this group. If the master chassis failover is detected, the HA chassis
- with the next higher priority takes over the responsibility of provid‐
- ing the HA. If a distributed gateway router port references a row in
+ ity services. Each chassis in the group is represented by the table
+ HA_Chassis. The HA chassis with highest priority will be the master of
+ this group. If the master chassis failover is detected, the HA chassis
+ with the next higher priority takes over the responsibility of provid‐
+ ing the HA. If a distributed gateway router port references a row in
this table, then the master HA chassis in this group provides the gate‐
way functionality.
@@ -3861,12 +4096,12 @@ HA_Chassis TABLE
BFD TABLE
Contains BFD parameter for ovn-controller BFD configuration. OVN BFD
- implementation is used to provide detection of failures in the path
- between adjacent forwarding engines, including the OVN interfaces. OVN
- BFD provides link status info to OVN northd in order to update logical
- flows according to the status of BFD endpoints. In the current imple‐
- mentation OVN BFD is used to check next-hop status for ECMP routes.
- Please note BFD table refers to OVN BFD implementation and not to OVS
+ implementation is used to provide detection of failures in the path be‐
+ tween adjacent forwarding engines, including the OVN interfaces. OVN
+ BFD provides link status info to OVN northd in order to update logical
+ flows according to the status of BFD endpoints. In the current imple‐
+ mentation OVN BFD is used to check next-hop status for ECMP routes.
+ Please note BFD table refers to OVN BFD implementation and not to OVS
legacy one.
Summary:
@@ -3924,14 +4159,13 @@ BFD TABLE
status: optional string, one of admin_down, down, init, or up
BFD port logical states. Possible values are:
- · admin_down
-
- · down
+ • admin_down
- · init
+ • down
- · up
+ • init
+ • up
Static_MAC_Binding TABLE
Each record represents a Static_MAC_Binding entry for a logical router.
@@ -3964,16 +4198,16 @@ Chassis_Template_Var TABLE
One record per chassis, each containing a map, variables, between tem‐
plate variable names and their value for that specific chassis. A tem‐
plate variable has a name and potentially different values on different
- hypervisors in the OVN cluster. For example, two rows, R1 = (.chas‐
- sis=C1, variables={(N: V1)} and R2 = (.chassis=C2, variables={(N: V2)}
- will make ovn-controller running on chassis C1 and C2 interpret the
- token N either as V1 (on C1) or as V2 (on C2). Users can refer to tem‐
+ hypervisors in the OVN cluster. For example, two rows, R1 = (.chas‐
+ sis=C1, variables={(N: V1)} and R2 = (.chassis=C2, variables={(N: V2)}
+ will make ovn-controller running on chassis C1 and C2 interpret the to‐
+ ken N either as V1 (on C1) or as V2 (on C2). Users can refer to tem‐
plate variables from within other logical components, e.g., within ACL,
- QoS or Logical_Router_Policy matches or from Load_Balancer VIP and
+ QoS or Logical_Router_Policy matches or from Load_Balancer VIP and
backend definitions.
- If a template variable is referenced on a chassis for which that vari‐
- able is not defined then ovn-controller running on that chassis will
+ If a template variable is referenced on a chassis for which that vari‐
+ able is not defined then ovn-controller running on that chassis will
just interpret it as a raw string literal.
Summary:
@@ -3994,6 +4228,4 @@ Chassis_Template_Var TABLE
external_ids: map of string-string pairs
See External IDs at the beginning of this document.
-
-
-Open vSwitch 22.12.90 DB Schema 7.0.0 ovn-nb(5)
+Open vSwitch 24.03.90 DB Schema 7.3.0 ovn-nb(5)
diff --git a/src/static/support/dist-docs/ovn-nbctl.8 b/src/static/support/dist-docs/ovn-nbctl.8
index 6feead04..09719f50 100644
--- a/src/static/support/dist-docs/ovn-nbctl.8
+++ b/src/static/support/dist-docs/ovn-nbctl.8
@@ -1,6 +1,6 @@
'\" p
.\" -*- nroff -*-
-.TH "ovn-nbctl" 8 "ovn-nbctl" "OVN 22\[char46]12\[char46]90" "OVN Manual"
+.TH "ovn-nbctl" 8 "ovn-nbctl" "OVN 24\[char46]03\[char46]90" "OVN Manual"
.fp 5 L CR \\" Make fixed-width font available as \\fL.
.de TQ
. br
@@ -400,25 +400,29 @@ Lists all existing switches on standard output, one per line\[char46]
These commands operates on ACL objects for a given \fIentity\fR\[char46] The \fIentity\fR can be either a logical switch or a port group\[char46] The \fIentity\fR can be specified as uuid or name\[char46] The \fB\-\-type\fR option can be used to specify the type of the \fIentity\fR, in case both a logical switch and a port groups exist with the same name specified for \fIentity\fR\[char46] \fBtype\fR must be either \fBswitch\fR or \fBport\-group\fR\[char46]
.RS
.TP
-[\fB\-\-type=\fR{\fBswitch\fR | \fBport\-group\fR}] [\fB\-\-log\fR] [\fB\-\-meter=\fR\fImeter\fR] [\fB\-\-severity=\fR\fIseverity\fR] [\fB\-\-name=\fR\fIname\fR] [\fB\-\-label=\fR\fIlabel\fR] [\fB\-\-may\-exist\fR] [\fB\-\-apply\-after\-lb\fR] \fBacl\-add\fR \fIentity\fR \fIdirection\fR \fIpriority\fR \fImatch\fR \fIverdict\fR
+[\fB\-\-type=\fR{\fBswitch\fR | \fBport\-group\fR}] [\fB\-\-log\fR] [\fB\-\-meter=\fR\fImeter\fR] [\fB\-\-severity=\fR\fIseverity\fR] [\fB\-\-name=\fR\fIname\fR] [\fB\-\-label=\fR\fIlabel\fR] [\fB\-\-may\-exist\fR] [\fB\-\-apply\-after\-lb\fR] [\fB\-\-tier\fR] \fBacl\-add\fR \fIentity\fR \fIdirection\fR \fIpriority\fR \fImatch\fR \fIverdict\fR
Adds the specified ACL to \fIentity\fR\[char46] \fIdirection\fR must be either \fBfrom\-lport\fR or \fBto\-lport\fR\[char46] \fIpriority\fR must be between \fB0\fR and \fB32767\fR, inclusive\[char46] A full description of the fields are in \fBovn\-nb\fR(5)\[char46] If \fB\-\-may\-exist\fR is specified, adding a duplicated ACL succeeds but the ACL is not really created\[char46] Without \fB\-\-may\-exist\fR, adding a duplicated ACL results in error\[char46]
.IP
The \fB\-\-log\fR option enables packet logging for the ACL\[char46] The options \fB\-\-severity\fR and \fB\-\-name\fR specify a severity and name, respectively, for log entries (and also enable logging)\[char46] The severity must be one of \fBalert\fR, \fBwarning\fR, \fBnotice\fR, \fBinfo\fR, or \fBdebug\fR\[char46] If a severity is not specified, the default is \fBinfo\fR\[char46] The \fB\-\-meter=\fImeter\fB\fR option is used to rate-limit packet logging\[char46] The \fImeter\fR argument names a meter configured by \fBmeter\-add\fR\[char46]
.IP
The \fB\-\-apply\-after\-lb\fR option sets \fBapply\-after\-lb=true\fR in the \fBoptions\fR column of the \fBACL\fR table\[char46] As the option name suggests, the ACL will be applied after the logical switch load balancer stage\[char46]
+.IP
+The \fB\-\-tier\fR option sets the ACL\(cqs tier to the specified value\[char46] For more information about ACL tiers, see the documentation for the \fBovn\-nb\fR(5) database\[char46]
.TP
-[\fB\-\-type=\fR{\fBswitch\fR | \fBport\-group\fR}] \fBacl\-del\fR \fIentity\fR [\fIdirection\fR [\fIpriority\fR \fImatch\fR]]
+[\fB\-\-type=\fR{\fBswitch\fR | \fBport\-group\fR}] [\fB\-\-tier\fR] \fBacl\-del\fR \fIentity\fR [\fIdirection\fR [\fIpriority\fR \fImatch\fR]]
Deletes ACLs from \fIentity\fR\[char46] If only \fIentity\fR is supplied, all the ACLs from the \fIentity\fR are deleted\[char46] If \fIdirection\fR is also specified, then all the flows in that direction will be deleted from the \fIentity\fR\[char46] If all the fields are given, then a single flow that matches all the fields will be deleted\[char46]
+.IP
+If the \fB\-\-tier\fR option is provided, then only ACLs of the given tier value will be deleted, in addition to whatever other criteria have been provided\[char46]
.TP
[\fB\-\-type=\fR{\fBswitch\fR | \fBport\-group\fR}] \fBacl\-list\fR \fIentity\fR
Lists the ACLs on \fIentity\fR\[char46]
.RE
.SS "Logical Switch QoS Rule Commands"
.TP
-[\fB\-\-may\-exist\fR] \fBqos\-add\fR \fIswitch\fR \fIdirection\fR \fIpriority\fR \fImatch\fR [\fBdscp=\fR\fIdscp\fR] [\fBrate=\fR\fIrate\fR [\fBburst=\fR\fIburst\fR]]
+[\fB\-\-may\-exist\fR] \fBqos\-add\fR \fIswitch\fR \fIdirection\fR \fIpriority\fR \fImatch\fR [\fBmark=\fR\fImark\fR] [\fBdscp=\fR\fIdscp\fR] [\fBrate=\fR\fIrate\fR [\fBburst=\fR\fIburst\fR]]
Adds QoS marking and metering rules to \fIswitch\fR\[char46] \fIdirection\fR must be either \fBfrom\-lport\fR or \fBto\-lport\fR\[char46] \fIpriority\fR must be between \fB0\fR and \fB32767\fR, inclusive\[char46]
.IP
-If \fBdscp=\fR\fIdscp\fR is specified, then matching packets will have DSCP marking applied\[char46] \fIdscp\fR must be between \fB0\fR and \fB63\fR, inclusive\[char46] If \fBrate=\fR\fIrate\fR is specified then matching packets will have metering applied at \fIrate\fR kbps\[char46] If metering is configured, then \fBburst=\fR\fIburst\fR specifies the burst rate limit in kilobits\[char46] \fBdscp\fR and/or \fBrate\fR are required arguments\[char46]
+If \fBdscp=\fR\fIdscp\fR is specified, then matching packets will have DSCP marking applied\[char46] \fIdscp\fR must be between \fB0\fR and \fB63\fR, inclusive\[char46] If \fBrate=\fR\fIrate\fR is specified then matching packets will have metering applied at \fIrate\fR kbps\[char46] If metering is configured, then \fBburst=\fR\fIburst\fR specifies the burst rate limit in kilobits\[char46] \fBdscp\fR and/or \fBrate\fR are required arguments\[char46] If \fBmark=\fR\fImark\fR is specified, then matching packets will be marked (through \fBpkt\[char46]mark\fR)\[char46] \fImark\fR must be a positive integer\[char46]
.IP
If \fB\-\-may\-exist\fR is specified, adding a duplicated QoS rule succeeds but the QoS rule is not really created\[char46] Without \fB\-\-may\-exist\fR, adding a duplicated QoS rule results in error\[char46]
.TP
@@ -558,7 +562,7 @@ Get the logical switch which the \fIport\fR belongs to\[char46]
\fBlsp\-attach\-mirror\fR \fIport\fR \fIm\fR
Attaches the mirror \fIm\fR to the logical port \fIport\fR\[char46]
.TP
-\fBlsp\-dettach\-mirror\fR \fIport\fR \fIm\fR
+\fBlsp\-detach\-mirror\fR \fIport\fR \fIm\fR
Detaches the mirror \fIm\fR from the logical port \fIport\fR\[char46]
.SS "Forwarding Group Commands"
.TP
@@ -648,6 +652,8 @@ Add Policy to \fIrouter\fR which provides a way to configure permit/deny and rer
.IP
If \fB\-\-may\-exist\fR is specified, adding a duplicated routing policy with the same priority and match string is not really created\[char46] Without \fB\-\-may\-exist\fR, adding a duplicated routing policy results in error\[char46]
.IP
+\fB\-\-bfd\fR option is used to link a BFD session to the OVN reroute policy\[char46] OVN will look for an already running BFD session using next-hop as lookup key in the BFD table\[char46] If the lookup fails, a new entry in the BFD table will be created using the \fInexthop\fR as \fIdst_ip\fR\[char46]
+.IP
The following example shows a policy to lr1, which will drop packets from\fB192\[char46]168\[char46]100\[char46]0/24\fR\[char46]
.IP
\fBlr\-policy\-add lr1 100 ip4\[char46]src == 192\[char46]168\[char46]100\[char46]0/24 drop\fR\[char46]
@@ -666,7 +672,7 @@ If \fIrouter\fR and \fIuuid\fR are supplied, then the policy with specified uuid
Lists the polices on \fIrouter\fR\[char46]
.SS "NAT Commands"
.TP
-[\fB\-\-may\-exist\fR] [\fB\-\-stateless\fR] [\fB\-\-gateway_port\fR=\fIGATEWAY_PORT\fR] \fBlr\-nat\-add\fR \fIrouter\fR \fItype\fR \fIexternal_ip\fR \fIlogical_ip\fR [\fIlogical_port\fR \fIexternal_mac\fR]
+[\fB\-\-may\-exist\fR] [\fB\-\-stateless\fR] [\fB\-\-gateway\-port\fR=\fIGATEWAY_PORT\fR] \fBlr\-nat\-add\fR \fIrouter\fR \fItype\fR \fIexternal_ip\fR \fIlogical_ip\fR [\fIlogical_port\fR \fIexternal_mac\fR]
Adds the specified NAT to \fIrouter\fR\[char46] The \fItype\fR must be one of \fBsnat\fR, \fBdnat\fR, or \fBdnat_and_snat\fR\[char46] The \fIexternal_ip\fR is an IPv4 address\[char46] The \fIlogical_ip\fR is an IPv4 network (e\[char46]g 192\[char46]168\[char46]1\[char46]0/24) or an IPv4 address\[char46] The \fIlogical_port\fR and \fIexternal_mac\fR are only accepted when \fIrouter\fR is a distributed router (rather than a gateway router) and \fItype\fR is \fBdnat_and_snat\fR\[char46] The \fIlogical_port\fR is the name of an existing logical switch port where the \fIlogical_ip\fR resides\[char46] The \fIexternal_mac\fR is an Ethernet address\[char46]
.IP
When \fB\-\-stateless\fR is specified then it implies that we will be not use connection tracker, i\[char46]e internal ip and external ip are 1:1 mapped\[char46] This implies that \fB\-\-stateless\fR is applicable only to dnat_and_snat type NAT rules\[char46] An external ip with \fB\-\-stateless\fR NAT cannot be shared with any other NAT rule\[char46]
@@ -765,8 +771,8 @@ Creates a new HA chassis group in the \fBHA_Chassis_Group\fR table named \fBgrou
\fBha\-chassis\-group\-del\fR \fIgroup\fR
Deletes the HA chassis group \fBgroup\fR\[char46] It is an error if \fBgroup\fR does not exist\[char46]
.TP
-\fBha\-chassis\-group\-list\fR
-Lists the HA chassis group \fBgroup\fR along with the \fBHA chassis\fR if any associated with it\[char46]
+\fBha\-chassis\-group\-list\fR [\fIha-chassis-group\fR]
+Lists all HA chassis groups along with the \fBHA chassis\fR if any associated with it\[char46] If \fIha-chassis-group\fR is also specified, then only the specified \fIha-chassis-group\fR will be listed\[char46]
.TP
\fBha\-chassis\-group\-add\-chassis\fR \fIgroup\fR \fIchassis\fR \fIpriority\fR
Adds a new HA chassis \fBchassis\fR to the HA Chassis group \fBgroup\fR with the specified priority\[char46] If the \fBchassis\fR already exists, then the \fBpriority\fR is updated\[char46] The \fBchassis\fR should be the name of the chassis in the \fBOVN_Southbound\fR\[char46]
@@ -830,16 +836,16 @@ Adds the control plane protection policy \fBname\fR to the logical router \fBrou
.RE
.SS "Mirror commands"
.TP
-\fBmirror\-add\fR \fIm\fR \fItype\fR \fIindex\fR \fIfilter\fR \fIdest\fR
+\fBmirror\-add\fR \fIm\fR \fItype\fR [\fIindex\fR] \fIfilter\fR \fIdest\fR
Creates a new mirror in the \fBMirror\fR table with the name \fBm\fR with the below mandatory arguments\[char46]
.IP
-\fItype\fR specifies the mirror type - \fBgre\fR or \fBerspan\fR\[char46]
+\fItype\fR specifies the mirror type - \fBgre\fR , \fBerspan\fR or \fBlocal\fR\[char46]
.IP
-\fIindex\fR specifies the tunnel index value (which is an integer)\[char46]
+\fIindex\fR specifies the tunnel index value (which is an integer) if the \fItype\fR is \fBgre\fR or \fBerspan\fR\[char46]
.IP
-\fIfilter\fR specifies the mirror source selection\[char46] Can be \fBfrom\-lport\fR or \fBto\-lport\fR\[char46]
+\fIfilter\fR specifies the mirror source selection\[char46] Can be \fBfrom\-lport\fR, \fBto\-lport\fR or \fBboth\fR\[char46]
.IP
-\fIdest\fR specifies the mirror destination IP (v4 or v6)\[char46]
+\fIdest\fR specifies the mirror destination IP (v4 or v6) if the \fItype\fR is \fBgre\fR or \fBerspan\fR\[char46] For a \fItype\fR of \fBlocal\fR, this field defines a local interface on the OVS integration bridge to be used as the mirror destination\[char46] The interface must possess external-ids:mirror-id that matches this string\[char46]
.TP
\fBmirror\-del\fR \fIm\fR
Deletes the mirror \fBm\fR\[char46]
diff --git a/src/static/support/dist-docs/ovn-nbctl.8.html b/src/static/support/dist-docs/ovn-nbctl.8.html
index aec9834d..996c2724 100644
--- a/src/static/support/dist-docs/ovn-nbctl.8.html
+++ b/src/static/support/dist-docs/ovn-nbctl.8.html
@@ -1,7 +1,5 @@
-ovn-nbctl(8) OVN Manual ovn-nbctl(8)
-
-
+ovn-nbctl(8) OVN Manual ovn-nbctl(8)
NAME
ovn-nbctl - Open Virtual Network northbound db management utility
@@ -22,20 +20,20 @@
ovn-nbctl can perform any number of commands in a single run, imple‐
mented as a single atomic transaction against the database.
- The ovn-nbctl command line begins with global options (see OPTIONS
- below for details). The global options are followed by one or more com‐
+ The ovn-nbctl command line begins with global options (see OPTIONS be‐
+ low for details). The global options are followed by one or more com‐
mands. Each command should begin with -- by itself as a command-line
argument, to separate it from the following commands. (The -- before
the first command is optional.) The command itself starts with command-
- specific options, if any, followed by the command name and any argu‐
+ specific options, if any, followed by the command name and any argu‐
ments.
DAEMON MODE
- When it is invoked in the most ordinary way, ovn-nbctl connects to an
- OVSDB server that hosts the northbound database, retrieves a partial
- copy of the database that is complete enough to do its work, sends a
- transaction request to the server, and receives and processes the
- server’s reply. In common interactive use, this is fine, but if the
+ When it is invoked in the most ordinary way, ovn-nbctl connects to an
+ OVSDB server that hosts the northbound database, retrieves a partial
+ copy of the database that is complete enough to do its work, sends a
+ transaction request to the server, and receives and processes the
+ server’s reply. In common interactive use, this is fine, but if the
database is large, the step in which ovn-nbctl retrieves a partial copy
of the database can take a long time, which yields poor performance
overall.
@@ -43,22 +41,22 @@
To improve performance in such a case, ovn-nbctl offers a "daemon
mode," in which the user first starts ovn-nbctl running in the back‐
ground and afterward uses the daemon to execute operations. Over sev‐
- eral ovn-nbctl command invocations, this performs better overall
- because it retrieves a copy of the database only once at the beginning,
+ eral ovn-nbctl command invocations, this performs better overall be‐
+ cause it retrieves a copy of the database only once at the beginning,
not once per program run.
Use the --detach option to start an ovn-nbctl daemon. With this option,
- ovn-nbctl prints the name of a control socket to stdout. The client
- should save this name in environment variable OVN_NB_DAEMON. Under the
+ ovn-nbctl prints the name of a control socket to stdout. The client
+ should save this name in environment variable OVN_NB_DAEMON. Under the
Bourne shell this might be done like this:
export OVN_NB_DAEMON=$(ovn-nbctl --pidfile --detach)
- When OVN_NB_DAEMON is set, ovn-nbctl automatically and transparently
+ When OVN_NB_DAEMON is set, ovn-nbctl automatically and transparently
uses the daemon to execute its commands.
- When the daemon is no longer needed, kill it and unset the environment
+ When the daemon is no longer needed, kill it and unset the environment
variable, e.g.:
kill $(cat $OVN_RUNDIR/ovn-nbctl.pid)
@@ -85,23 +83,23 @@
ovn-appctl. One may also use ovn-appctl directly with the following
commands:
- run [options] command [arg...] [-- [options] command [arg...]
+ run [options] command [arg...] [-- [options] command [arg...]
...]
Instructs the daemon process to run one or more ovn-nbctl
commands described above and reply with the results of
running these commands. Accepts the --no-wait, --wait,
- --timeout, --dry-run, --oneline, and the options
- described under Table Formatting Options in addition to
- the the command-specific options.
+ --timeout, --dry-run, --oneline, and the options de‐
+ scribed under Table Formatting Options in addition to the
+ the command-specific options.
exit Causes ovn-nbctl to gracefully terminate.
OPTIONS
- The options listed below affect the behavior of ovn-nbctl as a whole.
+ The options listed below affect the behavior of ovn-nbctl as a whole.
Some individual commands also accept their own options, which are given
just before the command name. If the first command on the command line
- has options, then those options must be separated from the global
- options by --.
+ has options, then those options must be separated from the global op‐
+ tions by --.
ovn-nbctl also accepts options from the OVN_NBCTL_OPTIONS environment
variable, in the same format as on the command line. Options from the
@@ -123,10 +121,10 @@
the northbound database updates.
With --wait=hv, before ovn-nbctl exits, it additionally
- waits for all OVN chassis (hypervisors and gateways) to
- become up-to-date with the northbound database updates.
- (This can become an indefinite wait if any chassis is mal‐
- functioning.)
+ waits for all OVN chassis (hypervisors and gateways) to be‐
+ come up-to-date with the northbound database updates. (This
+ can become an indefinite wait if any chassis is malfunc‐
+ tioning.)
Ordinarily, --wait=sb or --wait=hv only waits for changes
by the current ovn-nbctl invocation to take effect. This
@@ -135,11 +133,11 @@
Use the sync command to override this behavior.
--db database
- The OVSDB database remote to contact. If the OVN_NB_DB
- environment variable is set, its value is used as the
- default. Otherwise, the default is unix:/ovnnb_db.sock, but
- this default is unlikely to be useful outside of single-
- machine OVN test environments.
+ The OVSDB database remote to contact. If the OVN_NB_DB en‐
+ vironment variable is set, its value is used as the de‐
+ fault. Otherwise, the default is unix:/ovnnb_db.sock, but
+ this default is unlikely to be useful outside of single-ma‐
+ chine OVN test environments.
--leader-only
--no-leader-only
@@ -149,7 +147,7 @@
ovn-nbctl reads and reports is up-to-date. With
--no-leader-only, ovn-nbctl will use any server in the
cluster, which means that for read-only transactions it can
- report and act on stale data (transactions that modify the
+ report and act on stale data (transactions that modify the
database are always serialized even with --no-leader-only).
Refer to Understanding Cluster Consistency in ovsdb(7) for
more information.
@@ -163,11 +161,11 @@
tries to connect. The remotes will be shuffled only once to
a new order before the first connection attempt. The fol‐
lowing retries, if any, will follow the same new order. The
- default behavior is to make sure clients of a clustered
- database can distribute evenly to all members of the clus‐
- ter. With --no-shuffle-remotes, ovn-nbctl will use the
- original order specified in the connection string to con‐
- nect. This allows user to specify the preferred order,
+ default behavior is to make sure clients of a clustered
+ database can distribute evenly to all members of the clus‐
+ ter. With --no-shuffle-remotes, ovn-nbctl will use the
+ original order specified in the connection string to con‐
+ nect. This allows user to specify the preferred order,
which is particularly useful for testing.
--no-syslog
@@ -179,10 +177,10 @@
--oneline
Modifies the output format so that the output for each com‐
- mand is printed on a single line. New-line characters that
- would otherwise separate lines are printed as \fB\\n\fR,
- and any instances of \fB\\\fR that would otherwise appear
- in the output are doubled. Prints a blank line for each
+ mand is printed on a single line. New-line characters that
+ would otherwise separate lines are printed as \fB\\n\fR,
+ and any instances of \fB\\\fR that would otherwise appear
+ in the output are doubled. Prints a blank line for each
command that has no output. This option does not affect the
formatting of output from the list or find commands; see
Table Formatting Options below.
@@ -211,8 +209,8 @@
ovn-northd completes the Southbound DB updating success‐
fully. If --wait=hv is specified, in addition to the above
information, it also prints "ovn-controller(s) completion",
- which is the time between the Northbound DB update and the
- moment when the slowest hypervisor finishes processing the
+ which is the time between the Northbound DB update and the
+ moment when the slowest hypervisor finishes processing the
update.
Daemon Options
@@ -225,7 +223,7 @@
If --pidfile is not specified, no pidfile is created.
--overwrite-pidfile
- By default, when --pidfile is specified and the specified pid‐
+ By default, when --pidfile is specified and the specified pid‐
file already exists and is locked by a running process, the dae‐
mon refuses to start. Specify --overwrite-pidfile to cause it to
instead overwrite the pidfile.
@@ -233,8 +231,8 @@
When --pidfile is not specified, this option has no effect.
--detach
- Runs this program as a background process. The process forks,
- and in the child it starts a new session, closes the standard
+ Runs this program as a background process. The process forks,
+ and in the child it starts a new session, closes the standard
file descriptors (which has the side effect of disabling logging
to the console), and changes its current directory to the root
(unless --no-chdir is specified). After the child completes its
@@ -242,24 +240,24 @@
--monitor
Creates an additional process to monitor this program. If it
- dies due to a signal that indicates a programming error (SIGA‐
+ dies due to a signal that indicates a programming error (SIGA‐‐
BRT, SIGALRM, SIGBUS, SIGFPE, SIGILL, SIGPIPE, SIGSEGV, SIGXCPU,
or SIGXFSZ) then the monitor process starts a new copy of it. If
the daemon dies or exits for another reason, the monitor process
exits.
- This option is normally used with --detach, but it also func‐
+ This option is normally used with --detach, but it also func‐
tions without it.
--no-chdir
- By default, when --detach is specified, the daemon changes its
- current working directory to the root directory after it
- detaches. Otherwise, invoking the daemon from a carelessly cho‐
- sen directory would prevent the administrator from unmounting
- the file system that holds that directory.
-
- Specifying --no-chdir suppresses this behavior, preventing the
- daemon from changing its current working directory. This may be
+ By default, when --detach is specified, the daemon changes its
+ current working directory to the root directory after it de‐
+ taches. Otherwise, invoking the daemon from a carelessly chosen
+ directory would prevent the administrator from unmounting the
+ file system that holds that directory.
+
+ Specifying --no-chdir suppresses this behavior, preventing the
+ daemon from changing its current working directory. This may be
useful for collecting core files, since it is common behavior to
write core dumps into the current working directory and the root
directory is not a good directory to use.
@@ -267,13 +265,13 @@
This option has no effect when --detach is not specified.
--no-self-confinement
- By default this daemon will try to self-confine itself to work
- with files under well-known directories determined at build
- time. It is better to stick with this default behavior and not
- to use this flag unless some other Access Control is used to
- confine daemon. Note that in contrast to other access control
- implementations that are typically enforced from kernel-space
- (e.g. DAC or MAC), self-confinement is imposed from the user-
+ By default this daemon will try to self-confine itself to work
+ with files under well-known directories determined at build
+ time. It is better to stick with this default behavior and not
+ to use this flag unless some other Access Control is used to
+ confine daemon. Note that in contrast to other access control
+ implementations that are typically enforced from kernel-space
+ (e.g. DAC or MAC), self-confinement is imposed from the user-
space daemon itself and hence should not be considered as a full
confinement strategy, but instead should be viewed as an addi‐
tional layer of security.
@@ -293,32 +291,32 @@
apply even if the new user is root.
On Windows, this option is not currently supported. For security
- reasons, specifying this option will cause the daemon process
+ reasons, specifying this option will cause the daemon process
not to start.
Logging options
-v[spec]
--verbose=[spec]
- Sets logging levels. Without any spec, sets the log level for
- every module and destination to dbg. Otherwise, spec is a list of
+ Sets logging levels. Without any spec, sets the log level for
+ every module and destination to dbg. Otherwise, spec is a list of
words separated by spaces or commas or colons, up to one from each
category below:
- · A valid module name, as displayed by the vlog/list command
+ • A valid module name, as displayed by the vlog/list command
on ovs-appctl(8), limits the log level change to the speci‐
fied module.
- · syslog, console, or file, to limit the log level change to
- only to the system log, to the console, or to a file,
- respectively. (If --detach is specified, the daemon closes
- its standard file descriptors, so logging to the console
+ • syslog, console, or file, to limit the log level change to
+ only to the system log, to the console, or to a file, re‐
+ spectively. (If --detach is specified, the daemon closes
+ its standard file descriptors, so logging to the console
will have no effect.)
- On Windows platform, syslog is accepted as a word and is
+ On Windows platform, syslog is accepted as a word and is
only useful along with the --syslog-target option (the word
has no effect otherwise).
- · off, emer, err, warn, info, or dbg, to control the log
+ • off, emer, err, warn, info, or dbg, to control the log
level. Messages of the given severity or higher will be
logged, and messages of lower severity will be filtered
out. off filters out all messages. See ovs-appctl(8) for a
@@ -334,26 +332,26 @@
-v
--verbose
- Sets the maximum logging verbosity level, equivalent to --ver‐
+ Sets the maximum logging verbosity level, equivalent to --ver‐‐
bose=dbg.
-vPATTERN:destination:pattern
--verbose=PATTERN:destination:pattern
- Sets the log pattern for destination to pattern. Refer to
- ovs-appctl(8) for a description of the valid syntax for pattern.
+ Sets the log pattern for destination to pattern. Refer to ovs-ap‐‐
+ pctl(8) for a description of the valid syntax for pattern.
-vFACILITY:facility
--verbose=FACILITY:facility
- Sets the RFC5424 facility of the log message. facility can be one
+ Sets the RFC5424 facility of the log message. facility can be one
of kern, user, mail, daemon, auth, syslog, lpr, news, uucp, clock,
ftp, ntp, audit, alert, clock2, local0, local1, local2, local3,
local4, local5, local6 or local7. If this option is not specified,
- daemon is used as the default for the local system syslog and
- local0 is used while sending a message to the target provided via
+ daemon is used as the default for the local system syslog and lo‐‐
+ cal0 is used while sending a message to the target provided via
the --syslog-target option.
--log-file[=file]
- Enables logging to a file. If file is specified, then it is used
+ Enables logging to a file. If file is specified, then it is used
as the exact name for the log file. The default log file name used
if file is omitted is /usr/local/var/log/ovn/program.log.
@@ -366,30 +364,30 @@
Specify method as how syslog messages should be sent to syslog
daemon. The following forms are supported:
- · libc, to use the libc syslog() function. Downside of using
+ • libc, to use the libc syslog() function. Downside of using
this options is that libc adds fixed prefix to every mes‐
sage before it is actually sent to the syslog daemon over
/dev/log UNIX domain socket.
- · unix:file, to use a UNIX domain socket directly. It is pos‐
+ • unix:file, to use a UNIX domain socket directly. It is pos‐
sible to specify arbitrary message format with this option.
However, rsyslogd 8.9 and older versions use hard coded
parser function anyway that limits UNIX domain socket use.
If you want to use arbitrary message format with older
- rsyslogd versions, then use UDP socket to localhost IP
- address instead.
+ rsyslogd versions, then use UDP socket to localhost IP ad‐
+ dress instead.
- · udp:ip:port, to use a UDP socket. With this method it is
+ • udp:ip:port, to use a UDP socket. With this method it is
possible to use arbitrary message format also with older
- rsyslogd. When sending syslog messages over UDP socket
- extra precaution needs to be taken into account, for exam‐
- ple, syslog daemon needs to be configured to listen on the
- specified UDP port, accidental iptables rules could be
- interfering with local syslog traffic and there are some
- security considerations that apply to UDP sockets, but do
- not apply to UNIX domain sockets.
+ rsyslogd. When sending syslog messages over UDP socket ex‐
+ tra precaution needs to be taken into account, for example,
+ syslog daemon needs to be configured to listen on the spec‐
+ ified UDP port, accidental iptables rules could be inter‐
+ fering with local syslog traffic and there are some secu‐
+ rity considerations that apply to UDP sockets, but do not
+ apply to UNIX domain sockets.
- · null, to discard all messages logged to syslog.
+ • null, to discard all messages logged to syslog.
The default is taken from the OVS_SYSLOG_METHOD environment vari‐
able; if it is unset, the default is libc.
@@ -431,14 +429,14 @@
element is also an array with one element per
table column. The elements of this second-
level array are the cells that constitute the
- table. Cells that represent OVSDB data or
- data types are expressed in the format
- described in the OVSDB specification; other
+ table. Cells that represent OVSDB data or
+ data types are expressed in the format de‐
+ scribed in the OVSDB specification; other
cells are simply expressed as text strings.
-d format
--data=format
- Sets the formatting for cells within output tables unless
+ Sets the formatting for cells within output tables unless
the table format is set to json, in which case json format‐
ting is always used when formatting cells. The following
types of format are available:
@@ -448,19 +446,19 @@
section of ovs-vsctl(8).
bare The simple format with punctuation stripped off: []
- and {} are omitted around sets, maps, and empty col‐
- umns, items within sets and maps are space-sepa‐
+ and {} are omitted around sets, maps, and empty
+ columns, items within sets and maps are space-sepa‐
rated, and strings are never quoted. This format may
be easier for scripts to parse.
json The RFC 4627 JSON format as described above.
--no-headings
- This option suppresses the heading row that otherwise
- appears in the first row of table output.
+ This option suppresses the heading row that otherwise ap‐
+ pears in the first row of table output.
--pretty
- By default, JSON in output is printed as compactly as pos‐
+ By default, JSON in output is printed as compactly as pos‐
sible. This option causes JSON in output to be printed in a
more readable fashion. Members of objects and elements of
arrays are printed one per line, with indentation.
@@ -472,27 +470,27 @@
Equivalent to --format=list --data=bare --no-headings.
PKI Options
- PKI configuration is required to use SSL for the connection to the
+ PKI configuration is required to use SSL for the connection to the
database.
-p privkey.pem
--private-key=privkey.pem
- Specifies a PEM file containing the private key used as
+ Specifies a PEM file containing the private key used as
identity for outgoing SSL connections.
-c cert.pem
--certificate=cert.pem
- Specifies a PEM file containing a certificate that certi‐
+ Specifies a PEM file containing a certificate that certi‐
fies the private key specified on -p or --private-key to be
trustworthy. The certificate must be signed by the certifi‐
- cate authority (CA) that the peer in SSL connections will
+ cate authority (CA) that the peer in SSL connections will
use to verify it.
-C cacert.pem
--ca-cert=cacert.pem
Specifies a PEM file containing the CA certificate for ver‐
ifying certificates presented to this program by SSL peers.
- (This may be the same certificate that SSL peers use to
+ (This may be the same certificate that SSL peers use to
verify the certificate specified on -c or --certificate, or
it may be a different one, depending on the PKI design in
use.)
@@ -511,14 +509,14 @@
the SSL peer on its first SSL connection and save it to
the named PEM file. If it is successful, it will immedi‐
ately drop the connection and reconnect, and from then on
- all SSL connections must be authenticated by a certifi‐
+ all SSL connections must be authenticated by a certifi‐
cate 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, but
+ This option exposes the SSL connection to a man-in-the-
+ middle attack obtaining the initial CA certificate, but
it may be useful for bootstrapping.
- This option is only useful if the SSL peer sends its CA
+ This option is only useful if the SSL peer sends its CA
certificate as part of the SSL certificate chain. The SSL
protocol does not require the server to send the CA cer‐
tificate.
@@ -544,105 +542,115 @@
show [switch | router]
Prints a brief overview of the database contents. If switch is
provided, only records related to that logical switch are shown.
- If router is provided, only records related to that logical
+ If router is provided, only records related to that logical
router are shown.
Logical Switch Commands
- ls-add Creates a new, unnamed logical switch, which initially has no
- ports. The switch does not have a name, other commands must
- refer to this switch by its UUID.
+ ls-add Creates a new, unnamed logical switch, which initially has no
+ ports. The switch does not have a name, other commands must re‐
+ fer to this switch by its UUID.
[--may-exist | --add-duplicate] ls-add switch
- Creates a new logical switch named switch, which initially has
+ Creates a new logical switch named switch, which initially has
no ports.
- The OVN northbound database schema does not require logical
- switch names to be unique, but the whole point to the names is
+ The OVN northbound database schema does not require logical
+ switch names to be unique, but the whole point to the names is
to provide an easy way for humans to refer to the switches, mak‐
ing duplicate names unhelpful. Thus, without any options, this
command regards it as an error if switch is a duplicate name.
With --may-exist, adding a duplicate name succeeds but does not
create a new logical switch. With --add-duplicate, the command
really creates a new logical switch with a duplicate name. It is
- an error to specify both options. If there are multiple logical
- switches with a duplicate name, configure the logical switches
+ an error to specify both options. If there are multiple logical
+ switches with a duplicate name, configure the logical switches
using the UUID instead of the switch name.
[--if-exists] ls-del switch
- Deletes switch. It is an error if switch does not exist, unless
+ Deletes switch. It is an error if switch does not exist, unless
--if-exists is specified.
ls-list
Lists all existing switches on standard output, one per line.
ACL Commands
- These commands operates on ACL objects for a given entity. The entity
+ These commands operates on ACL objects for a given entity. The entity
can be either a logical switch or a port group. The entity can be spec‐
ified as uuid or name. The --type option can be used to specify the
- type of the entity, in case both a logical switch and a port groups
- exist with the same name specified for entity. type must be either
- switch or port-group.
-
- [--type={switch | port-group}] [--log] [--meter=meter] [--sever‐
- ity=severity] [--name=name] [--label=label] [--may-exist]
- [--apply-after-lb] acl-add entity direction priority match ver‐
- dict
- Adds the specified ACL to entity. direction must be
- either from-lport or to-lport. priority must be between 0
- and 32767, inclusive. A full description of the fields
- are in ovn-nb(5). If --may-exist is specified, adding a
- duplicated ACL succeeds but the ACL is not really cre‐
- ated. Without --may-exist, adding a duplicated ACL
- results in error.
-
- The --log option enables packet logging for the ACL. The
- options --severity and --name specify a severity and
+ type of the entity, in case both a logical switch and a port groups ex‐
+ ist with the same name specified for entity. type must be either switch
+ or port-group.
+
+ [--type={switch | port-group}] [--log] [--meter=meter] [--sever‐‐
+ ity=severity] [--name=name] [--label=label] [--may-exist] [--ap‐‐
+ ply-after-lb] [--tier] acl-add entity direction priority match
+ verdict
+ Adds the specified ACL to entity. direction must be ei‐
+ ther from-lport or to-lport. priority must be between 0
+ and 32767, inclusive. A full description of the fields
+ are in ovn-nb(5). If --may-exist is specified, adding a
+ duplicated ACL succeeds but the ACL is not really cre‐
+ ated. Without --may-exist, adding a duplicated ACL re‐
+ sults in error.
+
+ The --log option enables packet logging for the ACL. The
+ options --severity and --name specify a severity and
name, respectively, for log entries (and also enable log‐
- ging). The severity must be one of alert, warning,
- notice, info, or debug. If a severity is not specified,
- the default is info. The --meter=meter option is used to
- rate-limit packet logging. The meter argument names a
- meter configured by meter-add.
+ ging). The severity must be one of alert, warning, no‐‐
+ tice, info, or debug. If a severity is not specified, the
+ default is info. The --meter=meter option is used to
+ rate-limit packet logging. The meter argument names a me‐
+ ter configured by meter-add.
The --apply-after-lb option sets apply-after-lb=true in
the options column of the ACL table. As the option name
suggests, the ACL will be applied after the logical
switch load balancer stage.
- [--type={switch | port-group}] acl-del entity [direction [prior‐
- ity match]]
+ The --tier option sets the ACL’s tier to the specified
+ value. For more information about ACL tiers, see the doc‐
+ umentation for the ovn-nb(5) database.
+
+ [--type={switch | port-group}] [--tier] acl-del entity [direc
+ tion [priority match]]
Deletes ACLs from entity. If only entity is supplied, all
- the ACLs from the entity are deleted. If direction is
+ the ACLs from the entity are deleted. If direction is
also specified, then all the flows in that direction will
be deleted from the entity. If all the fields are given,
then a single flow that matches all the fields will be
deleted.
+ If the --tier option is provided, then only ACLs of the
+ given tier value will be deleted, in addition to whatever
+ other criteria have been provided.
+
[--type={switch | port-group}] acl-list entity
Lists the ACLs on entity.
Logical Switch QoS Rule Commands
- [--may-exist] qos-add switch direction priority match [dscp=dscp]
- [rate=rate [burst=burst]]
+ [--may-exist] qos-add switch direction priority match [mark=mark]
+ [dscp=dscp] [rate=rate [burst=burst]]
Adds QoS marking and metering rules to switch. direction must be
- either from-lport or to-lport. priority must be between 0 and
+ either from-lport or to-lport. priority must be between 0 and
32767, inclusive.
- If dscp=dscp is specified, then matching packets will have DSCP
- marking applied. dscp must be between 0 and 63, inclusive. If
- rate=rate is specified then matching packets will have metering
- applied at rate kbps. If metering is configured, then
- burst=burst specifies the burst rate limit in kilobits. dscp
- and/or rate are required arguments.
+ If dscp=dscp is specified, then matching packets will have DSCP
+ marking applied. dscp must be between 0 and 63, inclusive. If
+ rate=rate is specified then matching packets will have metering
+ applied at rate kbps. If metering is configured, then
+ burst=burst specifies the burst rate limit in kilobits. dscp
+ and/or rate are required arguments. If mark=mark is specified,
+ then matching packets will be marked (through pkt.mark). mark
+ must be a positive integer.
- If --may-exist is specified, adding a duplicated QoS rule suc‐
- ceeds but the QoS rule is not really created. Without
- --may-exist, adding a duplicated QoS rule results in error.
+ If --may-exist is specified, adding a duplicated QoS rule suc‐
+ ceeds but the QoS rule is not really created. Without --may-ex‐‐
+ ist, adding a duplicated QoS rule results in error.
qos-del switch [direction [priority match]]
- Deletes QoS rules from switch. If only switch is supplied, all
- the QoS rules from the logical switch are deleted. If direction
- is also specified, then all the flows in that direction will be
+ Deletes QoS rules from switch. If only switch is supplied, all
+ the QoS rules from the logical switch are deleted. If direction
+ is also specified, then all the flows in that direction will be
deleted from the logical switch. If all the fields are supplied,
then a single flow that matches the given fields will be
deleted.
@@ -656,14 +664,14 @@
Meter Commands
meter-add name action rate unit [burst]
Adds the specified meter. name must be a unique name to identify
- this meter. The action argument specifies what should happen
+ this meter. The action argument specifies what should happen
when this meter is exceeded. The only supported action is drop.
- The unit specifies the unit for the rate argument; valid values
- are kbps and pktps for kilobits per second and packets per sec‐
+ The unit specifies the unit for the rate argument; valid values
+ are kbps and pktps for kilobits per second and packets per sec‐
ond, respectively. The burst option configures the maximum burst
allowed for the band in kilobits or packets depending on whether
- the unit chosen was kbps or pktps, respectively. If a burst is
+ the unit chosen was kbps or pktps, respectively. If a burst is
not supplied, the switch is free to select some reasonable value
depending on its configuration.
@@ -684,9 +692,9 @@
[--may-exist] lsp-add switch port
Creates on lswitch a new logical switch port named port.
- It is an error if a logical port named port already exists,
- unless --may-exist is specified. Regardless of --may-exist, it
- is an error if the existing port is in some logical switch other
+ It is an error if a logical port named port already exists, un‐
+ less --may-exist is specified. Regardless of --may-exist, it is
+ an error if the existing port is in some logical switch other
than switch or if it has a parent port.
[--may-exist] lsp-add switch port parent tag_request
@@ -699,10 +707,10 @@
tion to the container’s port and it must be shared with the vir‐
tual machine’s port.
- It is an error if a logical port named port already exists,
- unless --may-exist is specified. Regardless of --may-exist, it
- is an error if the existing port is not in switch or if it does
- not have the specified parent and tag_request.
+ It is an error if a logical port named port already exists, un‐
+ less --may-exist is specified. Regardless of --may-exist, it is
+ an error if the existing port is not in switch or if it does not
+ have the specified parent and tag_request.
[--if-exists] lsp-del port
Deletes port. It is an error if port does not exist, unless
@@ -722,7 +730,7 @@
Sets the addresses associated with port to address. Each address
should be one of the following:
- an Ethernet address, optionally followed by a space and one or
+ an Ethernet address, optionally followed by a space and one or
more IP addresses
OVN delivers packets for the Ethernet address to this
port.
@@ -733,13 +741,13 @@
to ports with address unknown.
dynamic
- Use this keyword to make ovn-northd generate a globally
+ Use this keyword to make ovn-northd generate a globally
unique MAC address and choose an unused IPv4 address with
the logical port’s subnet and store them in the port’s
dynamic_addresses column.
router Accepted only when the type of the logical switch port is
- router. This indicates that the Ethernet, IPv4, and IPv6
+ router. This indicates that the Ethernet, IPv4, and IPv6
addresses for this logical switch port should be obtained
from the connected logical router port, as specified by
router-port in lsp-set-options.
@@ -752,34 +760,34 @@
one per line.
lsp-set-port-security port [addrs]...
- Sets the port security addresses associated with port to addrs.
- Multiple sets of addresses may be set by using multiple addrs
- arguments. If no addrs argument is given, port will not have
+ Sets the port security addresses associated with port to addrs.
+ Multiple sets of addresses may be set by using multiple addrs
+ arguments. If no addrs argument is given, port will not have
port security enabled.
Port security limits the addresses from which a logical port may
send packets and to which it may receive packets. See the
- ovn-nb(5) documentation for the port_security column in the Log‐
+ ovn-nb(5) documentation for the port_security column in the Log‐‐
ical_Switch_Port table for details.
lsp-get-port-security port
- Lists all the port security addresses associated with port on
+ Lists all the port security addresses associated with port on
standard output, one per line.
lsp-get-up port
Prints the state of port, either up or down.
lsp-set-enabled port state
- Set the administrative state of port, either enabled or dis‐
- abled. When a port is disabled, no traffic is allowed into or
+ Set the administrative state of port, either enabled or dis‐‐
+ abled. When a port is disabled, no traffic is allowed into or
out of the port.
lsp-get-enabled port
- Prints the administrative state of port, either enabled or dis‐
+ Prints the administrative state of port, either enabled or dis‐‐
abled.
lsp-set-type port type
- Set the type for the logical port. The type must be one of the
+ Set the type for the logical port. The type must be one of the
following:
(empty string)
@@ -788,10 +796,10 @@
router A connection to a logical router.
localnet
- A connection to a locally accessible network from each
+ A connection to a locally accessible network from each
ovn-controller instance. A logical switch can only have a
- single localnet port attached. This is used to model
- direct connectivity to an existing network.
+ single localnet port attached. This is used to model di‐
+ rect connectivity to an existing network.
localport
A connection to a local VIF. Traffic that arrives on a
@@ -817,7 +825,7 @@
lsp-set-dhcpv4-options port dhcp_options
Set the DHCPv4 options for the logical port. The dhcp_options is
- a UUID referring to a set of DHCP options in the DHCP_Options
+ a UUID referring to a set of DHCP options in the DHCP_Options
table.
lsp-get-dhcpv4-options port
@@ -837,7 +845,7 @@
lsp-attach-mirror port m
Attaches the mirror m to the logical port port.
- lsp-dettach-mirror port m
+ lsp-detach-mirror port m
Detaches the mirror m from the logical port port.
Forwarding Group Commands
@@ -852,42 +860,42 @@
When --liveness is specified then child ports are expected to be
bound to external devices like routers. BFD should be configured
- between hypervisors and the external devices. The child port
- selection will become dependent on BFD status with its external
+ between hypervisors and the external devices. The child port se‐
+ lection will become dependent on BFD status with its external
device.
[--if-exists] fwd-group-del group
- Deletes group. It is an error if group does not exist, unless
+ Deletes group. It is an error if group does not exist, unless
--if-exists is specified.
fwd-group-list [switch]
- Lists all existing forwarding groups, If switch is specified
- then only the forwarding groups configured for switch will be
+ Lists all existing forwarding groups, If switch is specified
+ then only the forwarding groups configured for switch will be
listed.
Logical Router Commands
- lr-add Creates a new, unnamed logical router, which initially has no
- ports. The router does not have a name, other commands must
- refer to this router by its UUID.
+ lr-add Creates a new, unnamed logical router, which initially has no
+ ports. The router does not have a name, other commands must re‐
+ fer to this router by its UUID.
[--may-exist | --add-duplicate] lr-add router
- Creates a new logical router named router, which initially has
+ Creates a new logical router named router, which initially has
no ports.
- The OVN northbound database schema does not require logical
- router names to be unique, but the whole point to the names is
- to provide an easy way for humans to refer to the routers, mak‐
- ing duplicate names unhelpful. Thus, without any options, this
- command regards it as an error if router is a duplicate name.
- With --may-exist, adding a duplicate name succeeds but does not
- create a new logical router. With --add-duplicate, the command
+ The OVN northbound database schema does not require logical
+ router names to be unique, but the whole point to the names is
+ to provide an easy way for humans to refer to the routers, mak‐
+ ing duplicate names unhelpful. Thus, without any options, this
+ command regards it as an error if router is a duplicate name.
+ With --may-exist, adding a duplicate name succeeds but does not
+ create a new logical router. With --add-duplicate, the command
really creates a new logical router with a duplicate name. It is
an error to specify both options. If there are multiple logical
- routers with a duplicate name, configure the logical routers
- using the UUID instead of the router name.
+ routers with a duplicate name, configure the logical routers us‐
+ ing the UUID instead of the router name.
[--if-exists] lr-del router
- Deletes router. It is an error if router does not exist, unless
+ Deletes router. It is an error if router does not exist, unless
--if-exists is specified.
lr-list
@@ -900,36 +908,36 @@
network.
The optional argument peer identifies a logical router port that
- connects to this one. The following example adds a router port
+ connects to this one. The following example adds a router port
with an IPv4 and IPv6 address with peer lr1:
lrp-add lr0 lrp0 00:11:22:33:44:55 192.168.0.1/24 2001:db8::1/64
peer=lr1
- It is an error if a logical router port named port already
- exists, unless --may-exist is specified. Regardless of
- --may-exist, it is an error if the existing router port is in
- some logical router other than router.
+ It is an error if a logical router port named port already ex‐
+ ists, unless --may-exist is specified. Regardless of --may-ex‐‐
+ ist, it is an error if the existing router port is in some logi‐
+ cal router other than router.
[--if-exists] lrp-del port
- Deletes port. It is an error if port does not exist, unless
+ Deletes port. It is an error if port does not exist, unless
--if-exists is specified.
lrp-list router
- Lists all the logical router ports within router on standard
+ Lists all the logical router ports within router on standard
output, one per line.
lrp-set-enabled port state
- Set the administrative state of port, either enabled or dis‐
- abled. When a port is disabled, no traffic is allowed into or
+ Set the administrative state of port, either enabled or dis‐‐
+ abled. When a port is disabled, no traffic is allowed into or
out of the port.
lrp-get-enabled port
- Prints the administrative state of port, either enabled or dis‐
+ Prints the administrative state of port, either enabled or dis‐‐
abled.
lrp-set-gateway-chassis port chassis [priority]
- Set gateway chassis for port. chassis is the name of the chas‐
+ Set gateway chassis for port. chassis is the name of the chas‐
sis. This creates a gateway chassis entry in Gateway_Chassis ta‐
ble. It won’t check if chassis really exists in OVN_Southbound
database. Priority will be set to 0 if priority is not provided
@@ -944,14 +952,14 @@
dard output, one per line, ordered based on priority.
Logical Router Static Route Commands
- [--may-exist] [--policy=POLICY] [--ecmp] [--ecmp-symmetric-reply]
+ [--may-exist] [--policy=POLICY] [--ecmp] [--ecmp-symmetric-reply]
[--bfd[=UUID]] lr-route-add router prefix nexthop [port]
Adds the specified route to router. prefix describes an IPv4 or
IPv6 prefix for this route, such as 192.168.100.0/24. nexthop
specifies the gateway to use for this route, which should be the
- IP address of one of router logical router ports or the IP
- address of a logical port. If port is specified, packets that
- match this route will be sent out that port. When port is omit‐
+ IP address of one of router logical router ports or the IP ad‐
+ dress of a logical port. If port is specified, packets that
+ match this route will be sent out that port. When port is omit‐
ted, OVN infers the output port based on nexthop. Nexthop can be
set to discard for dropping packets which match the given route.
@@ -959,7 +967,7 @@
This should be one of "dst-ip" or "src-ip". If not specified,
the default is "dst-ip".
- The --ecmp option allows for multiple routes with the same pre‐
+ The --ecmp option allows for multiple routes with the same pre
fix POLICY but different nexthop and port to be added.
The --ecmp-symmetric-reply option makes it so that traffic that
@@ -970,23 +978,23 @@
--bfd option is used to link a BFD session to the OVN route. If
the BFD session UUID is provided, it will be used for the OVN
route otherwise the next-hop will be used to perform a lookup in
- the OVN BFD table. If the lookup fails and port is specified, a
- new entry in the BFD table will be created using the nexthop as
+ the OVN BFD table. If the lookup fails and port is specified, a
+ new entry in the BFD table will be created using the nexthop as
dst_ip and port as logical_port.
It is an error if a route with prefix and POLICY already exists,
unless --may-exist, --ecmp, or --ecmp-symmetric-reply is speci‐
- fied. If --may-exist is specified but not --ecmp or --ecmp-sym‐
+ fied. If --may-exist is specified but not --ecmp or --ecmp-sym‐‐
metric-reply, the existed route will be updated with the new
nexthop and port. If --ecmp or --ecmp-symmetric-reply is speci‐
fied, a new route will be added, regardless of the existed
route., which is useful when adding ECMP routes, i.e. routes
with same POLICY and prefix but different nexthop and port.
- [--if-exists] [--policy=POLICY] lr-route-del router [prefix [nexthop
+ [--if-exists] [--policy=POLICY] lr-route-del router [prefix [nexthop
[port]]]
- Deletes routes from router. If only router is supplied, all the
- routes from the logical router are deleted. If POLICY, prefix,
+ Deletes routes from router. If only router is supplied, all the
+ routes from the logical router are deleted. If POLICY, prefix,
nexthop and/or port are also specified, then all the routes that
match the conditions will be deleted from the logical router.
@@ -997,30 +1005,36 @@
Lists the routes on router.
Logical Router Policy Commands
- [--may-exist]lr-policy-add router priority match action [nexthop[,nex‐
+ [--may-exist]lr-policy-add router priority match action [nexthop[,nex
thop,...]] [options key=value]]
- Add Policy to router which provides a way to configure per‐
- mit/deny and reroute policies on the router. Permit/deny poli‐
- cies are similar to OVN ACLs, but exist on the logical-router.
- Reroute policies are needed for service-insertion and service-
- chaining. nexthop is an optional parameter. It needs to be pro‐
- vided only when action is reroute. Multiple nexthops can be
- specified for ECMP routing. A policy is uniquely identified by
- priority and match. Multiple policies can have the same prior‐
- ity. options sets the router policy options as key-value pair.
+ Add Policy to router which provides a way to configure per‐
+ mit/deny and reroute policies on the router. Permit/deny poli‐
+ cies are similar to OVN ACLs, but exist on the logical-router.
+ Reroute policies are needed for service-insertion and service-
+ chaining. nexthop is an optional parameter. It needs to be pro‐
+ vided only when action is reroute. Multiple nexthops can be
+ specified for ECMP routing. A policy is uniquely identified by
+ priority and match. Multiple policies can have the same prior
+ ity. options sets the router policy options as key-value pair.
The supported option is : pkt_mark.
- If --may-exist is specified, adding a duplicated routing policy
- with the same priority and match string is not really created.
- Without --may-exist, adding a duplicated routing policy results
+ If --may-exist is specified, adding a duplicated routing policy
+ with the same priority and match string is not really created.
+ Without --may-exist, adding a duplicated routing policy results
in error.
- The following example shows a policy to lr1, which will drop
+ --bfd option is used to link a BFD session to the OVN reroute
+ policy. OVN will look for an already running BFD session using
+ next-hop as lookup key in the BFD table. If the lookup fails, a
+ new entry in the BFD table will be created using the nexthop as
+ dst_ip.
+
+ The following example shows a policy to lr1, which will drop
packets from192.168.100.0/24.
lr-policy-add lr1 100 ip4.src == 192.168.100.0/24 drop.
- lr-policy-add lr1 100 ip4.src == 192.168.100.0/24 allow
+ lr-policy-add lr1 100 ip4.src == 192.168.100.0/24 allow
pkt_mark=100 .
[--if-exists] lr-policy-del router [{priority | uuid} [match]]
@@ -1037,14 +1051,14 @@
Lists the polices on router.
NAT Commands
- [--may-exist] [--stateless] [--gateway_port=GATEWAY_PORT] lr-nat-add
+ [--may-exist] [--stateless] [--gateway-port=GATEWAY_PORT] lr-nat-add
router type external_ip logical_ip [logical_port external_mac]
- Adds the specified NAT to router. The type must be one of snat,
- dnat, or dnat_and_snat. The external_ip is an IPv4 address. The
- logical_ip is an IPv4 network (e.g 192.168.1.0/24) or an IPv4
- address. The logical_port and external_mac are only accepted
- when router is a distributed router (rather than a gateway
- router) and type is dnat_and_snat. The logical_port is the name
+ Adds the specified NAT to router. The type must be one of snat,
+ dnat, or dnat_and_snat. The external_ip is an IPv4 address. The
+ logical_ip is an IPv4 network (e.g 192.168.1.0/24) or an IPv4
+ address. The logical_port and external_mac are only accepted
+ when router is a distributed router (rather than a gateway
+ router) and type is dnat_and_snat. The logical_port is the name
of an existing logical switch port where the logical_ip resides.
The external_mac is an Ethernet address.
@@ -1055,7 +1069,7 @@
NAT cannot be shared with any other NAT rule.
--gateway-port option allows specifying the distributed gateway
- port of router where the NAT rule needs to be applied. GATE‐
+ port of router where the NAT rule needs to be applied. GATE
WAY_PORT should reference a Logical_Router_Port row that is a
distributed gateway port of router. When router has multiple
distributed gateway ports and the gateway port for this NAT
@@ -1065,69 +1079,69 @@
When type is dnat, the externally visible IP address external_ip
is DNATted to the IP address logical_ip in the logical space.
- When type is snat, IP packets with their source IP address that
+ When type is snat, IP packets with their source IP address that
either matches the IP address in logical_ip or is in the network
- provided by logical_ip is SNATed into the IP address in exter‐
+ provided by logical_ip is SNATed into the IP address in exter
nal_ip.
When type is dnat_and_snat, the externally visible IP address
external_ip is DNATted to the IP address logical_ip in the logi‐
- cal space. In addition, IP packets with the source IP address
- that matches logical_ip is SNATed into the IP address in exter‐
+ cal space. In addition, IP packets with the source IP address
+ that matches logical_ip is SNATed into the IP address in exter
nal_ip.
- When the logical_port and external_mac are specified, the NAT
- rule will be programmed on the chassis where the logical_port
- resides. This includes ARP replies for the external_ip, which
- return the value of external_mac. All packets transmitted with
- source IP address equal to external_ip will be sent using the
+ When the logical_port and external_mac are specified, the NAT
+ rule will be programmed on the chassis where the logical_port
+ resides. This includes ARP replies for the external_ip, which
+ return the value of external_mac. All packets transmitted with
+ source IP address equal to external_ip will be sent using the
external_mac.
- It is an error if a NAT already exists with the same values of
- router, type, external_ip, logical_ip and GATEWAY_PORT (in case
- of multiple distributed gateway ports), unless --may-exist is
- specified. When --may-exist, logical_port, and external_mac are
- all specified, the existing values of logical_port and exter‐
+ It is an error if a NAT already exists with the same values of
+ router, type, external_ip, logical_ip and GATEWAY_PORT (in case
+ of multiple distributed gateway ports), unless --may-exist is
+ specified. When --may-exist, logical_port, and external_mac are
+ all specified, the existing values of logical_port and exter
nal_mac are overwritten.
[--if-exists] lr-nat-del router [type [ip] [gateway_port]]
- Deletes NATs from router. If only router is supplied, all the
+ Deletes NATs from router. If only router is supplied, all the
NATs from the logical router are deleted. If type is also speci‐
fied, then all the NATs that match the type will be deleted from
- the logical router. If ip is also specified without specifying
- gateway_port, then all the NATs that match the type and ip will
+ the logical router. If ip is also specified without specifying
+ gateway_port, then all the NATs that match the type and ip will
be deleted from the logical router. If gateway_port is specified
without specifying ip, then all the NATs that match the type and
gateway_port will be deleted from the logical router. If all the
fields are given, then a single NAT rule that matches all the
fields will be deleted. When type is snat, the ip should be log‐
- ical_ip. When type is dnat or dnat_and_snat, the ip should be
+ ical_ip. When type is dnat or dnat_and_snat, the ip should be
external_ip.
- It is an error if both ip and gateway_port are specified and
+ It is an error if both ip and gateway_port are specified and
there is no matching NAT entry, unless --if-exists is specified.
lr-nat-list router
Lists the NATs on router.
Load Balancer Commands
- [--may-exist | --add-duplicate | --reject | --event] lb-add lb vip ips
+ [--may-exist | --add-duplicate | --reject | --event] lb-add lb vip ips
[protocol]
Creates a new load balancer named lb with the provided vip and
ips or adds the vip to an existing lb. vip should be a virtual
IP address (or an IP address and a port number with : as a sepa‐
- rator). Examples for vip are 192.168.1.4, fd0f::1, and
+ rator). Examples for vip are 192.168.1.4, fd0f::1, and
192.168.1.5:8080. ips should be comma separated IP endpoints (or
comma separated IP addresses and port numbers with : as a sepa‐
rator). ips must be the same address family as vip. Examples for
ips are 10.0.0.1,10.0.0.2or [fdef::1]:8800,[fdef::2]:8800.
- The optional argument protocol must be either tcp, udp or sctp.
- This argument is useful when a port number is provided as part
- of the vip. If the protocol is unspecified and a port number is
+ The optional argument protocol must be either tcp, udp or sctp.
+ This argument is useful when a port number is provided as part
+ of the vip. If the protocol is unspecified and a port number is
provided as part of the vip, OVN assumes the protocol to be tcp.
- It is an error if the vip already exists in the load balancer
+ It is an error if the vip already exists in the load balancer
named lb, unless --may-exist is specified. With --add-duplicate,
the command really creates a new load balancer with a duplicate
name.
@@ -1156,34 +1170,34 @@
lb, unless --if-exists is specified.
lb-list [lb]
- Lists the LBs. If lb is also specified, then only the specified
+ Lists the LBs. If lb is also specified, then only the specified
lb will be listed.
[--may-exist] ls-lb-add switch lb
- Adds the specified lb to switch. It is an error if a load bal‐
- ancer named lb already exists in the switch, unless --may-exist
+ Adds the specified lb to switch. It is an error if a load bal‐
+ ancer named lb already exists in the switch, unless --may-exist
is specified.
[--if-exists] ls-lb-del switch [lb]
- Removes lb from switch. If only switch is supplied, all the LBs
- from the logical switch are removed. If lb is also specified,
- then only the lb will be removed from the logical switch. It is
- an error if lb does not exist in the switch, unless --if-exists
+ Removes lb from switch. If only switch is supplied, all the LBs
+ from the logical switch are removed. If lb is also specified,
+ then only the lb will be removed from the logical switch. It is
+ an error if lb does not exist in the switch, unless --if-exists
is specified.
ls-lb-list switch
Lists the LBs for the given switch.
[--may-exist] lr-lb-add router lb
- Adds the specified lb to router. It is an error if a load bal‐
- ancer named lb already exists in the router, unless --may-exist
+ Adds the specified lb to router. It is an error if a load bal‐
+ ancer named lb already exists in the router, unless --may-exist
is specified.
[--if-exists] lr-lb-del router [lb]
- Removes lb from router. If only router is supplied, all the LBs
- from the logical router are removed. If lb is also specified,
- then only the lb will be removed from the logical router. It is
- an error if lb does not exist in the router, unless --if-exists
+ Removes lb from router. If only router is supplied, all the LBs
+ from the logical router are removed. If lb is also specified,
+ then only the lb will be removed from the logical router. It is
+ an error if lb does not exist in the router, unless --if-exists
is specified.
lr-lb-list router
@@ -1191,7 +1205,7 @@
DHCP Options commands
dhcp-options-create cidr [key=value]
- Creates a new DHCP Options entry in the DHCP_Options table with
+ Creates a new DHCP Options entry in the DHCP_Options table with
the specified cidr and optional external-ids.
dhcp-options-list
@@ -1208,33 +1222,34 @@
Port Group commands
pg-add group [port]...
- Creates a new port group in the Port_Group table named group
+ Creates a new port group in the Port_Group table named group
with optional ports added to the group.
pg-set-ports group port...
- Sets ports on the port group named group. It is an error if
+ Sets ports on the port group named group. It is an error if
group does not exist.
pg-del group
- Deletes port group group. It is an error if group does not
- exist.
+ Deletes port group group. It is an error if group does not ex‐
+ ist.
HA Chassis Group commands
ha-chassis-group-add group
- Creates a new HA chassis group in the HA_Chassis_Group table
+ Creates a new HA chassis group in the HA_Chassis_Group table
named group.
ha-chassis-group-del group
Deletes the HA chassis group group. It is an error if group does
not exist.
- ha-chassis-group-list
- Lists the HA chassis group group along with the HA chassis if
- any associated with it.
+ ha-chassis-group-list [ha-chassis-group]
+ Lists all HA chassis groups along with the HA chassis if any as‐
+ sociated with it. If ha-chassis-group is also specified, then
+ only the specified ha-chassis-group will be listed.
ha-chassis-group-add-chassis group chassis priority
Adds a new HA chassis chassis to the HA Chassis group group with
- the specified priority. If the chassis already exists, then the
+ the specified priority. If the chassis already exists, then the
priority is updated. The chassis should be the name of the chas‐
sis in the OVN_Southbound.
@@ -1244,41 +1259,41 @@
Control Plane Protection Policy commands
These commands manage meters configured in Copp table linking them to
- logical datapaths through copp column in Logical_Switch or Logi‐
+ logical datapaths through copp column in Logical_Switch or Logi‐‐
cal_Router tables. Protocol packets for which CoPP is enforced when
sending packets to ovn-controller (if configured):
- · ARP
+ • ARP
- · ND_NS
+ • ND_NS
- · ND_NA
+ • ND_NA
- · ND_RA
+ • ND_RA
- · ND
+ • ND
- · DNS
+ • DNS
- · IGMP
+ • IGMP
- · packets that require ARP resolution before forwarding
+ • packets that require ARP resolution before forwarding
- · packets that require ND_NS before forwarding
+ • packets that require ND_NS before forwarding
- · packets that need to be replied to with ICMP Errors
+ • packets that need to be replied to with ICMP Errors
- · packets that need to be replied to with TCP RST
+ • packets that need to be replied to with TCP RST
- · packets that need to be replied to with DHCP_OPTS
+ • packets that need to be replied to with DHCP_OPTS
- · packets that trigger a reject action
+ • packets that trigger a reject action
- · packets that trigger a SCTP abort action
+ • packets that trigger a SCTP abort action
- · controller_events
+ • controller_events
- · BFD
+ • BFD
copp-add name proto meter
Adds the control proto to meter mapping to the control
@@ -1304,18 +1319,23 @@
ical router router.
Mirror commands
- mirror-add m type index filter dest
+ mirror-add m type [index] filter dest
Creates a new mirror in the Mirror table with the name m with
the below mandatory arguments.
- type specifies the mirror type - gre or erspan.
+ type specifies the mirror type - gre , erspan or local.
- index specifies the tunnel index value (which is an integer).
+ index specifies the tunnel index value (which is an integer) if
+ the type is gre or erspan.
- filter specifies the mirror source selection. Can be from-lport
- or to-lport.
+ filter specifies the mirror source selection. Can be from-lport,
+ to-lport or both.
- dest specifies the mirror destination IP (v4 or v6).
+ dest specifies the mirror destination IP (v4 or v6) if the type
+ is gre or erspan. For a type of local, this field defines a lo‐
+ cal interface on the OVS integration bridge to be used as the
+ mirror destination. The interface must possess external-ids:mir‐
+ ror-id that matches this string.
mirror-del m
Deletes the mirror m.
@@ -1326,17 +1346,17 @@
Synchronization Commands
sync Ordinarily, --wait=sb or --wait=hv only waits for changes by the
current ovn-nbctl invocation to take effect. This means that, if
- none of the commands supplied to ovn-nbctl change the database,
- then the command does not wait at all. With the sync command,
- however, ovn-nbctl waits even for earlier changes to the data‐
- base to propagate down to the southbound database or all of the
+ none of the commands supplied to ovn-nbctl change the database,
+ then the command does not wait at all. With the sync command,
+ however, ovn-nbctl waits even for earlier changes to the data‐
+ base to propagate down to the southbound database or all of the
OVN chassis, according to the argument to --wait.
Remote Connectivity Commands
These commands manipulate the connections column in the NB_Global table
and rows in the Connection table. When ovsdb-server is configured to
- use the connections column for OVSDB connections, this allows the
- administrator to use ovn-nbctl to configure database connections.
+ use the connections column for OVSDB connections, this allows the ad‐
+ ministrator to use ovn-nbctl to configure database connections.
get-connection
Prints the configured connection(s).
@@ -1345,10 +1365,10 @@
Deletes the configured connection(s).
[--inactivity-probe=msecs] set-connection target...
- Sets the configured manager target or targets. Use
- --inactivity-probe=msecs to override the default idle
- connection inactivity probe time. Use 0 to disable inac‐
- tivity probes.
+ Sets the configured manager target or targets. Use --in‐‐
+ activity-probe=msecs to override the default idle connec‐
+ tion inactivity probe time. Use 0 to disable inactivity
+ probes.
SSL Configuration Commands
get-ssl
@@ -1357,7 +1377,7 @@
del-ssl
Deletes the current SSL configuration.
- [--bootstrap] set-ssl private-key certificate ca-cert [ssl-protocol-
+ [--bootstrap] set-ssl private-key certificate ca-cert [ssl-protocol-
list [ssl-cipher-list]]
Sets the SSL configuration.
@@ -1370,20 +1390,20 @@
Each of these commands has a table parameter to identify a table within
the database. Many of them also take a record parameter that identifies
- a particular record within a table. The record parameter may be the
- UUID for a record, which may be abbreviated to its first 4 (or more)
- hex digits, as long as that is unique. Many tables offer additional
- ways to identify records. Some commands also take column parameters
+ a particular record within a table. The record parameter may be the
+ UUID for a record, which may be abbreviated to its first 4 (or more)
+ hex digits, as long as that is unique. Many tables offer additional
+ ways to identify records. Some commands also take column parameters
that identify a particular field within the records in a table.
- For a list of tables and their columns, see ovn-nb(5) or see the table
+ For a list of tables and their columns, see ovn-nb(5) or see the table
listing from the --help option.
Record names must be specified in full and with correct capitalization,
except that UUIDs may be abbreviated to their first 4 (or more) hex
digits, as long as that is unique within the table. Names of tables and
- columns are not case-sensitive, and - and _ are treated interchange‐
- ably. Unique abbreviations of table and column names are acceptable,
+ columns are not case-sensitive, and - and _ are treated interchange‐
+ ably. Unique abbreviations of table and column names are acceptable,
e.g. d or dhcp is sufficient to identify the DHCP_Options table.
Database Values
@@ -1405,40 +1425,40 @@
begin with an English letter or underscore and consist
only of letters, underscores, hyphens, and periods. How‐
ever, true and false and strings that match the syntax of
- UUIDs (see below) must be enclosed in double quotes to
- distinguish them from other basic types. When double
- quotes are used, the syntax is that of strings in JSON,
- e.g. backslashes may be used to escape special charac‐
- ters. The empty string must be represented as a pair of
+ UUIDs (see below) must be enclosed in double quotes to
+ distinguish them from other basic types. When double
+ quotes are used, the syntax is that of strings in JSON,
+ e.g. backslashes may be used to escape special charac‐
+ ters. The empty string must be represented as a pair of
double quotes ("").
- UUID Either a universally unique identifier in the style of
- RFC 4122, e.g. f81d4fae-7dec-11d0-a765-00a0c91e6bf6, or
- an @name defined by a get or create command within the
+ UUID Either a universally unique identifier in the style of
+ RFC 4122, e.g. f81d4fae-7dec-11d0-a765-00a0c91e6bf6, or
+ an @name defined by a get or create command within the
same ovs-vsctl invocation.
Multiple values in a single column may be separated by spaces or a sin‐
- gle comma. When multiple values are present, duplicates are not
- allowed, and order is not important. Conversely, some database columns
+ gle comma. When multiple values are present, duplicates are not al‐
+ lowed, and order is not important. Conversely, some database columns
can have an empty set of values, represented as [], and square brackets
may optionally enclose other non-empty sets or single values as well.
- A few database columns are ``maps’’ of key-value pairs, where the key
+ A few database columns are ``maps’’ of key-value pairs, where the key
and the value are each some fixed database type. These are specified in
the form key=value, where key and value follow the syntax for the col‐
umn’s key type and value type, respectively. When multiple pairs are
- present (separated by spaces or a comma), duplicate keys are not
- allowed, and again the order is not important. Duplicate values are
- allowed. An empty map is represented as {}. Curly braces may optionally
+ present (separated by spaces or a comma), duplicate keys are not al‐
+ lowed, and again the order is not important. Duplicate values are al‐
+ lowed. An empty map is represented as {}. Curly braces may optionally
enclose non-empty maps as well (but use quotes to prevent the shell
- from expanding other-config={0=x,1=y} into other-config=0=x other-con‐
+ from expanding other-config={0=x,1=y} into other-config=0=x other-con‐‐
fig=1=y, which may not have the desired effect).
Database Command Syntax
- [--if-exists] [--columns=column[,column]...] list table
+ [--if-exists] [--columns=column[,column]...] list table
[record]...
- Lists the data in each specified record. If no records
+ Lists the data in each specified record. If no records
are specified, lists all the records in table.
If --columns is specified, only the requested columns are
@@ -1446,32 +1466,32 @@
are listed, in alphabetical order by column name.
Without --if-exists, it is an error if any specified
- record does not exist. With --if-exists, the command
- ignores any record that does not exist, without producing
+ record does not exist. With --if-exists, the command ig‐
+ nores any record that does not exist, without producing
any output.
- [--columns=column[,column]...] find table [col‐
+ [--columns=column[,column]...] find table [col
umn[:key]=value]...
- Lists the data in each record in table whose column
- equals value or, if key is specified, whose column con‐
+ Lists the data in each record in table whose column
+ equals value or, if key is specified, whose column con‐
tains a key with the specified value. The following oper‐
ators may be used where = is written in the syntax sum‐
mary:
= != gt;>gt; = >gt;>gt;=
Selects records in which column[:key] equals, does
- not equal, is less than, is greater than, is less
- than or equal to, or is greater than or equal to
+ not equal, is less than, is greater than, is less
+ than or equal to, or is greater than or equal to
value, respectively.
- Consider column[:key] and value as sets of ele‐
+ Consider column[:key] and value as sets of ele‐
ments. Identical sets are considered equal. Other‐
wise, if the sets have different numbers of ele‐
ments, then the set with more elements is consid‐
ered to be larger. Otherwise, consider a element
from each set pairwise, in increasing order within
- each set. The first pair that differs determines
- the result. (For a column that contains key-value
+ each set. The first pair that differs determines
+ the result. (For a column that contains key-value
pairs, first all the keys are compared, and values
are considered only if the two sets contain iden‐
tical keys.)
@@ -1490,30 +1510,30 @@
the empty set or contains 1 or 2 but not both.
{>gt;>gt;=} {>gt;>gt;}
- Same as {=} and {}, respectively, except that
- the relationship is reversed. For example,
- flood-vlans{>gt;>gt;=}1,2 selects records in which the
+ Same as {=} and {}, respectively, except that
+ the relationship is reversed. For example,
+ flood-vlans{>gt;>gt;=}1,2 selects records in which the
flood-vlans column contains both 1 and 2.
The following operators are available only in Open
vSwitch 2.16 and later:
- {in} Selects records in which every element in col‐
- umn[:key] is also in value. (This is the same as
+ {in} Selects records in which every element in col
+ umn[:key] is also in value. (This is the same as
{=}.)
{not-in}
- Selects records in which every element in col‐
+ Selects records in which every element in col
umn[:key] is not in value.
- For arithmetic operators (= != gt;>gt; = >gt;>gt;=), when key is
- specified but a particular record’s column does not con‐
- tain key, the record is always omitted from the results.
- Thus, the condition other-config:mtu!=1500 matches
- records that have a mtu key whose value is not 1500, but
+ For arithmetic operators (= != gt;>gt; = >gt;>gt;=), when key is
+ specified but a particular record’s column does not con‐
+ tain key, the record is always omitted from the results.
+ Thus, the condition other-config:mtu!=1500 matches
+ records that have a mtu key whose value is not 1500, but
not those that lack an mtu key.
- For the set operators, when key is specified but a par‐
+ For the set operators, when key is specified but a par‐
ticular record’s column does not contain key, the compar‐
ison is done against an empty set. Thus, the condition
other-config:mtu{!=}1500 matches records that have a mtu
@@ -1541,9 +1561,9 @@
record. With --if-exists, a missing record yields no out‐
put and a missing key prints a blank line.
- If @name is specified, then the UUID for record may be
- referred to by that name later in the same ovs-vsctl
- invocation in contexts where a UUID is expected.
+ If @name is specified, then the UUID for record may be
+ referred to by that name later in the same ovs-vsctl in‐
+ vocation in contexts where a UUID is expected.
Both --id and the column arguments are optional, but usu‐
ally at least one or the other should be specified. If
@@ -1553,41 +1573,40 @@
--id and --if-exists cannot be used together.
[--if-exists] set table record column[:key]=value...
- Sets the value of each specified column in the given
- record in table to value. For map columns, a key may
- optionally be specified, in which case the value associ‐
- ated with key in that column is changed (or added, if
- none exists), instead of the entire map.
+ Sets the value of each specified column in the given
+ record in table to value. For map columns, a key may op‐
+ tionally be specified, in which case the value associated
+ with key in that column is changed (or added, if none ex‐
+ ists), instead of the entire map.
- Without --if-exists, it is an error if record does not
- exist. With --if-exists, this command does nothing if
+ Without --if-exists, it is an error if record does not
+ exist. With --if-exists, this command does nothing if
record does not exist.
[--if-exists] add table record column [key=]value...
- Adds the specified value or key-value pair to column in
- record in table. If column is a map, then key is
- required, otherwise it is prohibited. If key already
- exists in a map column, then the current value is not
- replaced (use the set command to replace an existing
- value).
+ Adds the specified value or key-value pair to column in
+ record in table. If column is a map, then key is re‐
+ quired, otherwise it is prohibited. If key already exists
+ in a map column, then the current value is not replaced
+ (use the set command to replace an existing value).
- Without --if-exists, it is an error if record does not
- exist. With --if-exists, this command does nothing if
+ Without --if-exists, it is an error if record does not
+ exist. With --if-exists, this command does nothing if
record does not exist.
[--if-exists] remove table record column value...
[--if-exists] remove table record column key...
- [--if-exists] remove table record column key=value...
- Removes the specified values or key-value pairs from col‐
+ [--if-exists] remove table record column key=value...
+ Removes the specified values or key-value pairs from col
umn in record in table. The first form applies to columns
- that are not maps: each specified value is removed from
- the column. The second and third forms apply to map col‐
- umns: if only a key is specified, then any key-value pair
- with the given key is removed, regardless of its value;
- if a value is given then a pair is removed only if both
- key and value match.
+ that are not maps: each specified value is removed from
+ the column. The second and third forms apply to map
+ columns: if only a key is specified, then any key-value
+ pair with the given key is removed, regardless of its
+ value; if a value is given then a pair is removed only if
+ both key and value match.
It is not an error if the column does not contain the
specified key or value or pair.
@@ -1607,12 +1626,12 @@
[--id=(@name|uuid)] create table column[:key]=value...
Creates a new record in table and sets the initial values
- of each column. Columns not explicitly set will receive
+ of each column. Columns not explicitly set will receive
their default values. Outputs the UUID of the new row.
- If @name is specified, then the UUID for the new row may
- be referred to by that name elsewhere in the same \*(PN
- invocation in contexts where a UUID is expected. Such
+ If @name is specified, then the UUID for the new row may
+ be referred to by that name elsewhere in the same \*(PN
+ invocation in contexts where a UUID is expected. Such
references may precede or follow the create command.
If a valid uuid is specified, then it is used as the UUID
@@ -1620,23 +1639,23 @@
Caution (ovs-vsctl as example)
Records in the Open vSwitch database are signifi‐
- cant only when they can be reached directly or
- indirectly from the Open_vSwitch table. Except for
- records in the QoS or Queue tables, records that
- are not reachable from the Open_vSwitch table are
+ cant only when they can be reached directly or in‐
+ directly from the Open_vSwitch table. Except for
+ records in the QoS or Queue tables, records that
+ are not reachable from the Open_vSwitch table are
automatically deleted from the database. This
- deletion happens immediately, without waiting for
- additional ovs-vsctl commands or other database
+ deletion happens immediately, without waiting for
+ additional ovs-vsctl commands or other database
activity. Thus, a create command must generally be
accompanied by additional commands within the same
- ovs-vsctl invocation to add a chain of references
- to the newly created record from the top-level
- Open_vSwitch record. The EXAMPLES section gives
+ ovs-vsctl invocation to add a chain of references
+ to the newly created record from the top-level
+ Open_vSwitch record. The EXAMPLES section gives
some examples that show how to do this.
[--if-exists] destroy table record...
- Deletes each specified record from table. Unless
- --if-exists is specified, each records must exist.
+ Deletes each specified record from table. Unless --if-ex‐‐
+ ists is specified, each records must exist.
--all destroy table
Deletes all records from the table.
@@ -1655,19 +1674,19 @@
wait-until table record [column[:key]=value]...
Waits until table contains a record named record whose
column equals value or, if key is specified, whose column
- contains a key with the specified value. This command
- supports the same operators and semantics described for
+ contains a key with the specified value. This command
+ supports the same operators and semantics described for
the find command above.
- If no column[:key]=value arguments are given, this com‐
- mand waits only until record exists. If more than one
- such argument is given, the command waits until all of
+ If no column[:key]=value arguments are given, this com‐
+ mand waits only until record exists. If more than one
+ such argument is given, the command waits until all of
them are satisfied.
Caution (ovs-vsctl as example)
- Usually wait-until should be placed at the begin‐
- ning of a set of ovs-vsctl commands. For example,
- wait-until bridge br0 -- get bridge br0 data‐
+ Usually wait-until should be placed at the begin‐
+ ning of a set of ovs-vsctl commands. For example,
+ wait-until bridge br0 -- get bridge br0 data‐‐
path_id waits until a bridge named br0 is created,
then prints its datapath_id column, whereas get
bridge br0 datapath_id -- wait-until bridge br0
@@ -1689,11 +1708,11 @@
server process. See Daemon Mode, above, for more information.
OVN_NBCTL_OPTIONS
- If set, a set of options for ovn-nbctl to apply automatically,
+ If set, a set of options for ovn-nbctl to apply automatically,
in the same form as on the command line.
OVN_NB_DB
- If set, the default database to contact when the --db option is
+ If set, the default database to contact when the --db option is
not used.
EXIT STATUS
@@ -1704,7 +1723,5 @@
SEE ALSO
ovn-nb(5), ovn-appctl(8).
-
-
-OVN 22.12.90 ovn-nbctl ovn-nbctl(8)
+OVN 24.03.90 ovn-nbctl ovn-nbctl(8)
diff --git a/src/static/support/dist-docs/ovn-nbctl.8.pdf b/src/static/support/dist-docs/ovn-nbctl.8.pdf
index ac236621..fb8a42ed 100644
Binary files a/src/static/support/dist-docs/ovn-nbctl.8.pdf and b/src/static/support/dist-docs/ovn-nbctl.8.pdf differ
diff --git a/src/static/support/dist-docs/ovn-nbctl.8.txt b/src/static/support/dist-docs/ovn-nbctl.8.txt
index b4324271..c7576145 100644
--- a/src/static/support/dist-docs/ovn-nbctl.8.txt
+++ b/src/static/support/dist-docs/ovn-nbctl.8.txt
@@ -1,7 +1,5 @@
ovn-nbctl(8) OVN Manual ovn-nbctl(8)
-
-
NAME
ovn-nbctl - Open Virtual Network northbound db management utility
@@ -21,20 +19,20 @@ DESCRIPTION
ovn-nbctl can perform any number of commands in a single run, imple‐
mented as a single atomic transaction against the database.
- The ovn-nbctl command line begins with global options (see OPTIONS
- below for details). The global options are followed by one or more com‐
+ The ovn-nbctl command line begins with global options (see OPTIONS be‐
+ low for details). The global options are followed by one or more com‐
mands. Each command should begin with -- by itself as a command-line
argument, to separate it from the following commands. (The -- before
the first command is optional.) The command itself starts with command-
- specific options, if any, followed by the command name and any argu‐
+ specific options, if any, followed by the command name and any argu‐
ments.
DAEMON MODE
- When it is invoked in the most ordinary way, ovn-nbctl connects to an
- OVSDB server that hosts the northbound database, retrieves a partial
- copy of the database that is complete enough to do its work, sends a
- transaction request to the server, and receives and processes the
- server’s reply. In common interactive use, this is fine, but if the
+ When it is invoked in the most ordinary way, ovn-nbctl connects to an
+ OVSDB server that hosts the northbound database, retrieves a partial
+ copy of the database that is complete enough to do its work, sends a
+ transaction request to the server, and receives and processes the
+ server’s reply. In common interactive use, this is fine, but if the
database is large, the step in which ovn-nbctl retrieves a partial copy
of the database can take a long time, which yields poor performance
overall.
@@ -42,22 +40,22 @@ DAEMON MODE
To improve performance in such a case, ovn-nbctl offers a "daemon
mode," in which the user first starts ovn-nbctl running in the back‐
ground and afterward uses the daemon to execute operations. Over sev‐
- eral ovn-nbctl command invocations, this performs better overall
- because it retrieves a copy of the database only once at the beginning,
+ eral ovn-nbctl command invocations, this performs better overall be‐
+ cause it retrieves a copy of the database only once at the beginning,
not once per program run.
Use the --detach option to start an ovn-nbctl daemon. With this option,
- ovn-nbctl prints the name of a control socket to stdout. The client
- should save this name in environment variable OVN_NB_DAEMON. Under the
+ ovn-nbctl prints the name of a control socket to stdout. The client
+ should save this name in environment variable OVN_NB_DAEMON. Under the
Bourne shell this might be done like this:
export OVN_NB_DAEMON=$(ovn-nbctl --pidfile --detach)
- When OVN_NB_DAEMON is set, ovn-nbctl automatically and transparently
+ When OVN_NB_DAEMON is set, ovn-nbctl automatically and transparently
uses the daemon to execute its commands.
- When the daemon is no longer needed, kill it and unset the environment
+ When the daemon is no longer needed, kill it and unset the environment
variable, e.g.:
kill $(cat $OVN_RUNDIR/ovn-nbctl.pid)
@@ -84,23 +82,23 @@ DAEMON MODE
ovn-appctl. One may also use ovn-appctl directly with the following
commands:
- run [options] command [arg...] [-- [options] command [arg...]
+ run [options] command [arg...] [-- [options] command [arg...]
...]
Instructs the daemon process to run one or more ovn-nbctl
commands described above and reply with the results of
running these commands. Accepts the --no-wait, --wait,
- --timeout, --dry-run, --oneline, and the options
- described under Table Formatting Options in addition to
- the the command-specific options.
+ --timeout, --dry-run, --oneline, and the options de‐
+ scribed under Table Formatting Options in addition to the
+ the command-specific options.
exit Causes ovn-nbctl to gracefully terminate.
OPTIONS
- The options listed below affect the behavior of ovn-nbctl as a whole.
+ The options listed below affect the behavior of ovn-nbctl as a whole.
Some individual commands also accept their own options, which are given
just before the command name. If the first command on the command line
- has options, then those options must be separated from the global
- options by --.
+ has options, then those options must be separated from the global op‐
+ tions by --.
ovn-nbctl also accepts options from the OVN_NBCTL_OPTIONS environment
variable, in the same format as on the command line. Options from the
@@ -122,10 +120,10 @@ OPTIONS
the northbound database updates.
With --wait=hv, before ovn-nbctl exits, it additionally
- waits for all OVN chassis (hypervisors and gateways) to
- become up-to-date with the northbound database updates.
- (This can become an indefinite wait if any chassis is mal‐
- functioning.)
+ waits for all OVN chassis (hypervisors and gateways) to be‐
+ come up-to-date with the northbound database updates. (This
+ can become an indefinite wait if any chassis is malfunc‐
+ tioning.)
Ordinarily, --wait=sb or --wait=hv only waits for changes
by the current ovn-nbctl invocation to take effect. This
@@ -134,11 +132,11 @@ OPTIONS
Use the sync command to override this behavior.
--db database
- The OVSDB database remote to contact. If the OVN_NB_DB
- environment variable is set, its value is used as the
- default. Otherwise, the default is unix:/ovnnb_db.sock, but
- this default is unlikely to be useful outside of single-
- machine OVN test environments.
+ The OVSDB database remote to contact. If the OVN_NB_DB en‐
+ vironment variable is set, its value is used as the de‐
+ fault. Otherwise, the default is unix:/ovnnb_db.sock, but
+ this default is unlikely to be useful outside of single-ma‐
+ chine OVN test environments.
--leader-only
--no-leader-only
@@ -148,7 +146,7 @@ OPTIONS
ovn-nbctl reads and reports is up-to-date. With
--no-leader-only, ovn-nbctl will use any server in the
cluster, which means that for read-only transactions it can
- report and act on stale data (transactions that modify the
+ report and act on stale data (transactions that modify the
database are always serialized even with --no-leader-only).
Refer to Understanding Cluster Consistency in ovsdb(7) for
more information.
@@ -162,11 +160,11 @@ OPTIONS
tries to connect. The remotes will be shuffled only once to
a new order before the first connection attempt. The fol‐
lowing retries, if any, will follow the same new order. The
- default behavior is to make sure clients of a clustered
- database can distribute evenly to all members of the clus‐
- ter. With --no-shuffle-remotes, ovn-nbctl will use the
- original order specified in the connection string to con‐
- nect. This allows user to specify the preferred order,
+ default behavior is to make sure clients of a clustered
+ database can distribute evenly to all members of the clus‐
+ ter. With --no-shuffle-remotes, ovn-nbctl will use the
+ original order specified in the connection string to con‐
+ nect. This allows user to specify the preferred order,
which is particularly useful for testing.
--no-syslog
@@ -178,10 +176,10 @@ OPTIONS
--oneline
Modifies the output format so that the output for each com‐
- mand is printed on a single line. New-line characters that
- would otherwise separate lines are printed as \fB\\n\fR,
- and any instances of \fB\\\fR that would otherwise appear
- in the output are doubled. Prints a blank line for each
+ mand is printed on a single line. New-line characters that
+ would otherwise separate lines are printed as \fB\\n\fR,
+ and any instances of \fB\\\fR that would otherwise appear
+ in the output are doubled. Prints a blank line for each
command that has no output. This option does not affect the
formatting of output from the list or find commands; see
Table Formatting Options below.
@@ -210,8 +208,8 @@ OPTIONS
ovn-northd completes the Southbound DB updating success‐
fully. If --wait=hv is specified, in addition to the above
information, it also prints "ovn-controller(s) completion",
- which is the time between the Northbound DB update and the
- moment when the slowest hypervisor finishes processing the
+ which is the time between the Northbound DB update and the
+ moment when the slowest hypervisor finishes processing the
update.
Daemon Options
@@ -224,7 +222,7 @@ OPTIONS
If --pidfile is not specified, no pidfile is created.
--overwrite-pidfile
- By default, when --pidfile is specified and the specified pid‐
+ By default, when --pidfile is specified and the specified pid‐
file already exists and is locked by a running process, the dae‐
mon refuses to start. Specify --overwrite-pidfile to cause it to
instead overwrite the pidfile.
@@ -232,8 +230,8 @@ OPTIONS
When --pidfile is not specified, this option has no effect.
--detach
- Runs this program as a background process. The process forks,
- and in the child it starts a new session, closes the standard
+ Runs this program as a background process. The process forks,
+ and in the child it starts a new session, closes the standard
file descriptors (which has the side effect of disabling logging
to the console), and changes its current directory to the root
(unless --no-chdir is specified). After the child completes its
@@ -241,24 +239,24 @@ OPTIONS
--monitor
Creates an additional process to monitor this program. If it
- dies due to a signal that indicates a programming error (SIGA‐
+ dies due to a signal that indicates a programming error (SIGA‐
BRT, SIGALRM, SIGBUS, SIGFPE, SIGILL, SIGPIPE, SIGSEGV, SIGXCPU,
or SIGXFSZ) then the monitor process starts a new copy of it. If
the daemon dies or exits for another reason, the monitor process
exits.
- This option is normally used with --detach, but it also func‐
+ This option is normally used with --detach, but it also func‐
tions without it.
--no-chdir
- By default, when --detach is specified, the daemon changes its
- current working directory to the root directory after it
- detaches. Otherwise, invoking the daemon from a carelessly cho‐
- sen directory would prevent the administrator from unmounting
- the file system that holds that directory.
-
- Specifying --no-chdir suppresses this behavior, preventing the
- daemon from changing its current working directory. This may be
+ By default, when --detach is specified, the daemon changes its
+ current working directory to the root directory after it de‐
+ taches. Otherwise, invoking the daemon from a carelessly chosen
+ directory would prevent the administrator from unmounting the
+ file system that holds that directory.
+
+ Specifying --no-chdir suppresses this behavior, preventing the
+ daemon from changing its current working directory. This may be
useful for collecting core files, since it is common behavior to
write core dumps into the current working directory and the root
directory is not a good directory to use.
@@ -266,13 +264,13 @@ OPTIONS
This option has no effect when --detach is not specified.
--no-self-confinement
- By default this daemon will try to self-confine itself to work
- with files under well-known directories determined at build
- time. It is better to stick with this default behavior and not
- to use this flag unless some other Access Control is used to
- confine daemon. Note that in contrast to other access control
- implementations that are typically enforced from kernel-space
- (e.g. DAC or MAC), self-confinement is imposed from the user-
+ By default this daemon will try to self-confine itself to work
+ with files under well-known directories determined at build
+ time. It is better to stick with this default behavior and not
+ to use this flag unless some other Access Control is used to
+ confine daemon. Note that in contrast to other access control
+ implementations that are typically enforced from kernel-space
+ (e.g. DAC or MAC), self-confinement is imposed from the user-
space daemon itself and hence should not be considered as a full
confinement strategy, but instead should be viewed as an addi‐
tional layer of security.
@@ -292,32 +290,32 @@ OPTIONS
apply even if the new user is root.
On Windows, this option is not currently supported. For security
- reasons, specifying this option will cause the daemon process
+ reasons, specifying this option will cause the daemon process
not to start.
Logging options
-v[spec]
--verbose=[spec]
- Sets logging levels. Without any spec, sets the log level for
- every module and destination to dbg. Otherwise, spec is a list of
+ Sets logging levels. Without any spec, sets the log level for
+ every module and destination to dbg. Otherwise, spec is a list of
words separated by spaces or commas or colons, up to one from each
category below:
- · A valid module name, as displayed by the vlog/list command
+ • A valid module name, as displayed by the vlog/list command
on ovs-appctl(8), limits the log level change to the speci‐
fied module.
- · syslog, console, or file, to limit the log level change to
- only to the system log, to the console, or to a file,
- respectively. (If --detach is specified, the daemon closes
- its standard file descriptors, so logging to the console
+ • syslog, console, or file, to limit the log level change to
+ only to the system log, to the console, or to a file, re‐
+ spectively. (If --detach is specified, the daemon closes
+ its standard file descriptors, so logging to the console
will have no effect.)
- On Windows platform, syslog is accepted as a word and is
+ On Windows platform, syslog is accepted as a word and is
only useful along with the --syslog-target option (the word
has no effect otherwise).
- · off, emer, err, warn, info, or dbg, to control the log
+ • off, emer, err, warn, info, or dbg, to control the log
level. Messages of the given severity or higher will be
logged, and messages of lower severity will be filtered
out. off filters out all messages. See ovs-appctl(8) for a
@@ -333,26 +331,26 @@ OPTIONS
-v
--verbose
- Sets the maximum logging verbosity level, equivalent to --ver‐
+ Sets the maximum logging verbosity level, equivalent to --ver‐
bose=dbg.
-vPATTERN:destination:pattern
--verbose=PATTERN:destination:pattern
- Sets the log pattern for destination to pattern. Refer to
- ovs-appctl(8) for a description of the valid syntax for pattern.
+ Sets the log pattern for destination to pattern. Refer to ovs-ap‐
+ pctl(8) for a description of the valid syntax for pattern.
-vFACILITY:facility
--verbose=FACILITY:facility
- Sets the RFC5424 facility of the log message. facility can be one
+ Sets the RFC5424 facility of the log message. facility can be one
of kern, user, mail, daemon, auth, syslog, lpr, news, uucp, clock,
ftp, ntp, audit, alert, clock2, local0, local1, local2, local3,
local4, local5, local6 or local7. If this option is not specified,
- daemon is used as the default for the local system syslog and
- local0 is used while sending a message to the target provided via
+ daemon is used as the default for the local system syslog and lo‐
+ cal0 is used while sending a message to the target provided via
the --syslog-target option.
--log-file[=file]
- Enables logging to a file. If file is specified, then it is used
+ Enables logging to a file. If file is specified, then it is used
as the exact name for the log file. The default log file name used
if file is omitted is /usr/local/var/log/ovn/program.log.
@@ -365,30 +363,30 @@ OPTIONS
Specify method as how syslog messages should be sent to syslog
daemon. The following forms are supported:
- · libc, to use the libc syslog() function. Downside of using
+ • libc, to use the libc syslog() function. Downside of using
this options is that libc adds fixed prefix to every mes‐
sage before it is actually sent to the syslog daemon over
/dev/log UNIX domain socket.
- · unix:file, to use a UNIX domain socket directly. It is pos‐
+ • unix:file, to use a UNIX domain socket directly. It is pos‐
sible to specify arbitrary message format with this option.
However, rsyslogd 8.9 and older versions use hard coded
parser function anyway that limits UNIX domain socket use.
If you want to use arbitrary message format with older
- rsyslogd versions, then use UDP socket to localhost IP
- address instead.
+ rsyslogd versions, then use UDP socket to localhost IP ad‐
+ dress instead.
- · udp:ip:port, to use a UDP socket. With this method it is
+ • udp:ip:port, to use a UDP socket. With this method it is
possible to use arbitrary message format also with older
- rsyslogd. When sending syslog messages over UDP socket
- extra precaution needs to be taken into account, for exam‐
- ple, syslog daemon needs to be configured to listen on the
- specified UDP port, accidental iptables rules could be
- interfering with local syslog traffic and there are some
- security considerations that apply to UDP sockets, but do
- not apply to UNIX domain sockets.
+ rsyslogd. When sending syslog messages over UDP socket ex‐
+ tra precaution needs to be taken into account, for example,
+ syslog daemon needs to be configured to listen on the spec‐
+ ified UDP port, accidental iptables rules could be inter‐
+ fering with local syslog traffic and there are some secu‐
+ rity considerations that apply to UDP sockets, but do not
+ apply to UNIX domain sockets.
- · null, to discard all messages logged to syslog.
+ • null, to discard all messages logged to syslog.
The default is taken from the OVS_SYSLOG_METHOD environment vari‐
able; if it is unset, the default is libc.
@@ -430,14 +428,14 @@ OPTIONS
element is also an array with one element per
table column. The elements of this second-
level array are the cells that constitute the
- table. Cells that represent OVSDB data or
- data types are expressed in the format
- described in the OVSDB specification; other
+ table. Cells that represent OVSDB data or
+ data types are expressed in the format de‐
+ scribed in the OVSDB specification; other
cells are simply expressed as text strings.
-d format
--data=format
- Sets the formatting for cells within output tables unless
+ Sets the formatting for cells within output tables unless
the table format is set to json, in which case json format‐
ting is always used when formatting cells. The following
types of format are available:
@@ -447,19 +445,19 @@ OPTIONS
section of ovs-vsctl(8).
bare The simple format with punctuation stripped off: []
- and {} are omitted around sets, maps, and empty col‐
- umns, items within sets and maps are space-sepa‐
+ and {} are omitted around sets, maps, and empty
+ columns, items within sets and maps are space-sepa‐
rated, and strings are never quoted. This format may
be easier for scripts to parse.
json The RFC 4627 JSON format as described above.
--no-headings
- This option suppresses the heading row that otherwise
- appears in the first row of table output.
+ This option suppresses the heading row that otherwise ap‐
+ pears in the first row of table output.
--pretty
- By default, JSON in output is printed as compactly as pos‐
+ By default, JSON in output is printed as compactly as pos‐
sible. This option causes JSON in output to be printed in a
more readable fashion. Members of objects and elements of
arrays are printed one per line, with indentation.
@@ -471,27 +469,27 @@ OPTIONS
Equivalent to --format=list --data=bare --no-headings.
PKI Options
- PKI configuration is required to use SSL for the connection to the
+ PKI configuration is required to use SSL for the connection to the
database.
-p privkey.pem
--private-key=privkey.pem
- Specifies a PEM file containing the private key used as
+ Specifies a PEM file containing the private key used as
identity for outgoing SSL connections.
-c cert.pem
--certificate=cert.pem
- Specifies a PEM file containing a certificate that certi‐
+ Specifies a PEM file containing a certificate that certi‐
fies the private key specified on -p or --private-key to be
trustworthy. The certificate must be signed by the certifi‐
- cate authority (CA) that the peer in SSL connections will
+ cate authority (CA) that the peer in SSL connections will
use to verify it.
-C cacert.pem
--ca-cert=cacert.pem
Specifies a PEM file containing the CA certificate for ver‐
ifying certificates presented to this program by SSL peers.
- (This may be the same certificate that SSL peers use to
+ (This may be the same certificate that SSL peers use to
verify the certificate specified on -c or --certificate, or
it may be a different one, depending on the PKI design in
use.)
@@ -510,14 +508,14 @@ OPTIONS
the SSL peer on its first SSL connection and save it to
the named PEM file. If it is successful, it will immedi‐
ately drop the connection and reconnect, and from then on
- all SSL connections must be authenticated by a certifi‐
+ all SSL connections must be authenticated by a certifi‐
cate 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, but
+ This option exposes the SSL connection to a man-in-the-
+ middle attack obtaining the initial CA certificate, but
it may be useful for bootstrapping.
- This option is only useful if the SSL peer sends its CA
+ This option is only useful if the SSL peer sends its CA
certificate as part of the SSL certificate chain. The SSL
protocol does not require the server to send the CA cer‐
tificate.
@@ -543,105 +541,115 @@ COMMANDS
show [switch | router]
Prints a brief overview of the database contents. If switch is
provided, only records related to that logical switch are shown.
- If router is provided, only records related to that logical
+ If router is provided, only records related to that logical
router are shown.
Logical Switch Commands
- ls-add Creates a new, unnamed logical switch, which initially has no
- ports. The switch does not have a name, other commands must
- refer to this switch by its UUID.
+ ls-add Creates a new, unnamed logical switch, which initially has no
+ ports. The switch does not have a name, other commands must re‐
+ fer to this switch by its UUID.
[--may-exist | --add-duplicate] ls-add switch
- Creates a new logical switch named switch, which initially has
+ Creates a new logical switch named switch, which initially has
no ports.
- The OVN northbound database schema does not require logical
- switch names to be unique, but the whole point to the names is
+ The OVN northbound database schema does not require logical
+ switch names to be unique, but the whole point to the names is
to provide an easy way for humans to refer to the switches, mak‐
ing duplicate names unhelpful. Thus, without any options, this
command regards it as an error if switch is a duplicate name.
With --may-exist, adding a duplicate name succeeds but does not
create a new logical switch. With --add-duplicate, the command
really creates a new logical switch with a duplicate name. It is
- an error to specify both options. If there are multiple logical
- switches with a duplicate name, configure the logical switches
+ an error to specify both options. If there are multiple logical
+ switches with a duplicate name, configure the logical switches
using the UUID instead of the switch name.
[--if-exists] ls-del switch
- Deletes switch. It is an error if switch does not exist, unless
+ Deletes switch. It is an error if switch does not exist, unless
--if-exists is specified.
ls-list
Lists all existing switches on standard output, one per line.
ACL Commands
- These commands operates on ACL objects for a given entity. The entity
+ These commands operates on ACL objects for a given entity. The entity
can be either a logical switch or a port group. The entity can be spec‐
ified as uuid or name. The --type option can be used to specify the
- type of the entity, in case both a logical switch and a port groups
- exist with the same name specified for entity. type must be either
- switch or port-group.
-
- [--type={switch | port-group}] [--log] [--meter=meter] [--sever‐
- ity=severity] [--name=name] [--label=label] [--may-exist]
- [--apply-after-lb] acl-add entity direction priority match ver‐
- dict
- Adds the specified ACL to entity. direction must be
- either from-lport or to-lport. priority must be between 0
- and 32767, inclusive. A full description of the fields
- are in ovn-nb(5). If --may-exist is specified, adding a
- duplicated ACL succeeds but the ACL is not really cre‐
- ated. Without --may-exist, adding a duplicated ACL
- results in error.
-
- The --log option enables packet logging for the ACL. The
- options --severity and --name specify a severity and
+ type of the entity, in case both a logical switch and a port groups ex‐
+ ist with the same name specified for entity. type must be either switch
+ or port-group.
+
+ [--type={switch | port-group}] [--log] [--meter=meter] [--sever‐
+ ity=severity] [--name=name] [--label=label] [--may-exist] [--ap‐
+ ply-after-lb] [--tier] acl-add entity direction priority match
+ verdict
+ Adds the specified ACL to entity. direction must be ei‐
+ ther from-lport or to-lport. priority must be between 0
+ and 32767, inclusive. A full description of the fields
+ are in ovn-nb(5). If --may-exist is specified, adding a
+ duplicated ACL succeeds but the ACL is not really cre‐
+ ated. Without --may-exist, adding a duplicated ACL re‐
+ sults in error.
+
+ The --log option enables packet logging for the ACL. The
+ options --severity and --name specify a severity and
name, respectively, for log entries (and also enable log‐
- ging). The severity must be one of alert, warning,
- notice, info, or debug. If a severity is not specified,
- the default is info. The --meter=meter option is used to
- rate-limit packet logging. The meter argument names a
- meter configured by meter-add.
+ ging). The severity must be one of alert, warning, no‐
+ tice, info, or debug. If a severity is not specified, the
+ default is info. The --meter=meter option is used to
+ rate-limit packet logging. The meter argument names a me‐
+ ter configured by meter-add.
The --apply-after-lb option sets apply-after-lb=true in
the options column of the ACL table. As the option name
suggests, the ACL will be applied after the logical
switch load balancer stage.
- [--type={switch | port-group}] acl-del entity [direction [prior‐
- ity match]]
+ The --tier option sets the ACL’s tier to the specified
+ value. For more information about ACL tiers, see the doc‐
+ umentation for the ovn-nb(5) database.
+
+ [--type={switch | port-group}] [--tier] acl-del entity [direc‐
+ tion [priority match]]
Deletes ACLs from entity. If only entity is supplied, all
- the ACLs from the entity are deleted. If direction is
+ the ACLs from the entity are deleted. If direction is
also specified, then all the flows in that direction will
be deleted from the entity. If all the fields are given,
then a single flow that matches all the fields will be
deleted.
+ If the --tier option is provided, then only ACLs of the
+ given tier value will be deleted, in addition to whatever
+ other criteria have been provided.
+
[--type={switch | port-group}] acl-list entity
Lists the ACLs on entity.
Logical Switch QoS Rule Commands
- [--may-exist] qos-add switch direction priority match [dscp=dscp]
- [rate=rate [burst=burst]]
+ [--may-exist] qos-add switch direction priority match [mark=mark]
+ [dscp=dscp] [rate=rate [burst=burst]]
Adds QoS marking and metering rules to switch. direction must be
- either from-lport or to-lport. priority must be between 0 and
+ either from-lport or to-lport. priority must be between 0 and
32767, inclusive.
- If dscp=dscp is specified, then matching packets will have DSCP
- marking applied. dscp must be between 0 and 63, inclusive. If
- rate=rate is specified then matching packets will have metering
- applied at rate kbps. If metering is configured, then
- burst=burst specifies the burst rate limit in kilobits. dscp
- and/or rate are required arguments.
+ If dscp=dscp is specified, then matching packets will have DSCP
+ marking applied. dscp must be between 0 and 63, inclusive. If
+ rate=rate is specified then matching packets will have metering
+ applied at rate kbps. If metering is configured, then
+ burst=burst specifies the burst rate limit in kilobits. dscp
+ and/or rate are required arguments. If mark=mark is specified,
+ then matching packets will be marked (through pkt.mark). mark
+ must be a positive integer.
- If --may-exist is specified, adding a duplicated QoS rule suc‐
- ceeds but the QoS rule is not really created. Without
- --may-exist, adding a duplicated QoS rule results in error.
+ If --may-exist is specified, adding a duplicated QoS rule suc‐
+ ceeds but the QoS rule is not really created. Without --may-ex‐
+ ist, adding a duplicated QoS rule results in error.
qos-del switch [direction [priority match]]
- Deletes QoS rules from switch. If only switch is supplied, all
- the QoS rules from the logical switch are deleted. If direction
- is also specified, then all the flows in that direction will be
+ Deletes QoS rules from switch. If only switch is supplied, all
+ the QoS rules from the logical switch are deleted. If direction
+ is also specified, then all the flows in that direction will be
deleted from the logical switch. If all the fields are supplied,
then a single flow that matches the given fields will be
deleted.
@@ -655,14 +663,14 @@ COMMANDS
Meter Commands
meter-add name action rate unit [burst]
Adds the specified meter. name must be a unique name to identify
- this meter. The action argument specifies what should happen
+ this meter. The action argument specifies what should happen
when this meter is exceeded. The only supported action is drop.
- The unit specifies the unit for the rate argument; valid values
- are kbps and pktps for kilobits per second and packets per sec‐
+ The unit specifies the unit for the rate argument; valid values
+ are kbps and pktps for kilobits per second and packets per sec‐
ond, respectively. The burst option configures the maximum burst
allowed for the band in kilobits or packets depending on whether
- the unit chosen was kbps or pktps, respectively. If a burst is
+ the unit chosen was kbps or pktps, respectively. If a burst is
not supplied, the switch is free to select some reasonable value
depending on its configuration.
@@ -683,9 +691,9 @@ COMMANDS
[--may-exist] lsp-add switch port
Creates on lswitch a new logical switch port named port.
- It is an error if a logical port named port already exists,
- unless --may-exist is specified. Regardless of --may-exist, it
- is an error if the existing port is in some logical switch other
+ It is an error if a logical port named port already exists, un‐
+ less --may-exist is specified. Regardless of --may-exist, it is
+ an error if the existing port is in some logical switch other
than switch or if it has a parent port.
[--may-exist] lsp-add switch port parent tag_request
@@ -698,10 +706,10 @@ COMMANDS
tion to the container’s port and it must be shared with the vir‐
tual machine’s port.
- It is an error if a logical port named port already exists,
- unless --may-exist is specified. Regardless of --may-exist, it
- is an error if the existing port is not in switch or if it does
- not have the specified parent and tag_request.
+ It is an error if a logical port named port already exists, un‐
+ less --may-exist is specified. Regardless of --may-exist, it is
+ an error if the existing port is not in switch or if it does not
+ have the specified parent and tag_request.
[--if-exists] lsp-del port
Deletes port. It is an error if port does not exist, unless
@@ -721,7 +729,7 @@ COMMANDS
Sets the addresses associated with port to address. Each address
should be one of the following:
- an Ethernet address, optionally followed by a space and one or
+ an Ethernet address, optionally followed by a space and one or
more IP addresses
OVN delivers packets for the Ethernet address to this
port.
@@ -732,13 +740,13 @@ COMMANDS
to ports with address unknown.
dynamic
- Use this keyword to make ovn-northd generate a globally
+ Use this keyword to make ovn-northd generate a globally
unique MAC address and choose an unused IPv4 address with
the logical port’s subnet and store them in the port’s
dynamic_addresses column.
router Accepted only when the type of the logical switch port is
- router. This indicates that the Ethernet, IPv4, and IPv6
+ router. This indicates that the Ethernet, IPv4, and IPv6
addresses for this logical switch port should be obtained
from the connected logical router port, as specified by
router-port in lsp-set-options.
@@ -751,34 +759,34 @@ COMMANDS
one per line.
lsp-set-port-security port [addrs]...
- Sets the port security addresses associated with port to addrs.
- Multiple sets of addresses may be set by using multiple addrs
- arguments. If no addrs argument is given, port will not have
+ Sets the port security addresses associated with port to addrs.
+ Multiple sets of addresses may be set by using multiple addrs
+ arguments. If no addrs argument is given, port will not have
port security enabled.
Port security limits the addresses from which a logical port may
send packets and to which it may receive packets. See the
- ovn-nb(5) documentation for the port_security column in the Log‐
+ ovn-nb(5) documentation for the port_security column in the Log‐
ical_Switch_Port table for details.
lsp-get-port-security port
- Lists all the port security addresses associated with port on
+ Lists all the port security addresses associated with port on
standard output, one per line.
lsp-get-up port
Prints the state of port, either up or down.
lsp-set-enabled port state
- Set the administrative state of port, either enabled or dis‐
- abled. When a port is disabled, no traffic is allowed into or
+ Set the administrative state of port, either enabled or dis‐
+ abled. When a port is disabled, no traffic is allowed into or
out of the port.
lsp-get-enabled port
- Prints the administrative state of port, either enabled or dis‐
+ Prints the administrative state of port, either enabled or dis‐
abled.
lsp-set-type port type
- Set the type for the logical port. The type must be one of the
+ Set the type for the logical port. The type must be one of the
following:
(empty string)
@@ -787,10 +795,10 @@ COMMANDS
router A connection to a logical router.
localnet
- A connection to a locally accessible network from each
+ A connection to a locally accessible network from each
ovn-controller instance. A logical switch can only have a
- single localnet port attached. This is used to model
- direct connectivity to an existing network.
+ single localnet port attached. This is used to model di‐
+ rect connectivity to an existing network.
localport
A connection to a local VIF. Traffic that arrives on a
@@ -816,7 +824,7 @@ COMMANDS
lsp-set-dhcpv4-options port dhcp_options
Set the DHCPv4 options for the logical port. The dhcp_options is
- a UUID referring to a set of DHCP options in the DHCP_Options
+ a UUID referring to a set of DHCP options in the DHCP_Options
table.
lsp-get-dhcpv4-options port
@@ -836,7 +844,7 @@ COMMANDS
lsp-attach-mirror port m
Attaches the mirror m to the logical port port.
- lsp-dettach-mirror port m
+ lsp-detach-mirror port m
Detaches the mirror m from the logical port port.
Forwarding Group Commands
@@ -851,42 +859,42 @@ COMMANDS
When --liveness is specified then child ports are expected to be
bound to external devices like routers. BFD should be configured
- between hypervisors and the external devices. The child port
- selection will become dependent on BFD status with its external
+ between hypervisors and the external devices. The child port se‐
+ lection will become dependent on BFD status with its external
device.
[--if-exists] fwd-group-del group
- Deletes group. It is an error if group does not exist, unless
+ Deletes group. It is an error if group does not exist, unless
--if-exists is specified.
fwd-group-list [switch]
- Lists all existing forwarding groups, If switch is specified
- then only the forwarding groups configured for switch will be
+ Lists all existing forwarding groups, If switch is specified
+ then only the forwarding groups configured for switch will be
listed.
Logical Router Commands
- lr-add Creates a new, unnamed logical router, which initially has no
- ports. The router does not have a name, other commands must
- refer to this router by its UUID.
+ lr-add Creates a new, unnamed logical router, which initially has no
+ ports. The router does not have a name, other commands must re‐
+ fer to this router by its UUID.
[--may-exist | --add-duplicate] lr-add router
- Creates a new logical router named router, which initially has
+ Creates a new logical router named router, which initially has
no ports.
- The OVN northbound database schema does not require logical
- router names to be unique, but the whole point to the names is
- to provide an easy way for humans to refer to the routers, mak‐
- ing duplicate names unhelpful. Thus, without any options, this
- command regards it as an error if router is a duplicate name.
- With --may-exist, adding a duplicate name succeeds but does not
- create a new logical router. With --add-duplicate, the command
+ The OVN northbound database schema does not require logical
+ router names to be unique, but the whole point to the names is
+ to provide an easy way for humans to refer to the routers, mak‐
+ ing duplicate names unhelpful. Thus, without any options, this
+ command regards it as an error if router is a duplicate name.
+ With --may-exist, adding a duplicate name succeeds but does not
+ create a new logical router. With --add-duplicate, the command
really creates a new logical router with a duplicate name. It is
an error to specify both options. If there are multiple logical
- routers with a duplicate name, configure the logical routers
- using the UUID instead of the router name.
+ routers with a duplicate name, configure the logical routers us‐
+ ing the UUID instead of the router name.
[--if-exists] lr-del router
- Deletes router. It is an error if router does not exist, unless
+ Deletes router. It is an error if router does not exist, unless
--if-exists is specified.
lr-list
@@ -899,36 +907,36 @@ COMMANDS
network.
The optional argument peer identifies a logical router port that
- connects to this one. The following example adds a router port
+ connects to this one. The following example adds a router port
with an IPv4 and IPv6 address with peer lr1:
lrp-add lr0 lrp0 00:11:22:33:44:55 192.168.0.1/24 2001:db8::1/64
peer=lr1
- It is an error if a logical router port named port already
- exists, unless --may-exist is specified. Regardless of
- --may-exist, it is an error if the existing router port is in
- some logical router other than router.
+ It is an error if a logical router port named port already ex‐
+ ists, unless --may-exist is specified. Regardless of --may-ex‐
+ ist, it is an error if the existing router port is in some logi‐
+ cal router other than router.
[--if-exists] lrp-del port
- Deletes port. It is an error if port does not exist, unless
+ Deletes port. It is an error if port does not exist, unless
--if-exists is specified.
lrp-list router
- Lists all the logical router ports within router on standard
+ Lists all the logical router ports within router on standard
output, one per line.
lrp-set-enabled port state
- Set the administrative state of port, either enabled or dis‐
- abled. When a port is disabled, no traffic is allowed into or
+ Set the administrative state of port, either enabled or dis‐
+ abled. When a port is disabled, no traffic is allowed into or
out of the port.
lrp-get-enabled port
- Prints the administrative state of port, either enabled or dis‐
+ Prints the administrative state of port, either enabled or dis‐
abled.
lrp-set-gateway-chassis port chassis [priority]
- Set gateway chassis for port. chassis is the name of the chas‐
+ Set gateway chassis for port. chassis is the name of the chas‐
sis. This creates a gateway chassis entry in Gateway_Chassis ta‐
ble. It won’t check if chassis really exists in OVN_Southbound
database. Priority will be set to 0 if priority is not provided
@@ -943,14 +951,14 @@ COMMANDS
dard output, one per line, ordered based on priority.
Logical Router Static Route Commands
- [--may-exist] [--policy=POLICY] [--ecmp] [--ecmp-symmetric-reply]
+ [--may-exist] [--policy=POLICY] [--ecmp] [--ecmp-symmetric-reply]
[--bfd[=UUID]] lr-route-add router prefix nexthop [port]
Adds the specified route to router. prefix describes an IPv4 or
IPv6 prefix for this route, such as 192.168.100.0/24. nexthop
specifies the gateway to use for this route, which should be the
- IP address of one of router logical router ports or the IP
- address of a logical port. If port is specified, packets that
- match this route will be sent out that port. When port is omit‐
+ IP address of one of router logical router ports or the IP ad‐
+ dress of a logical port. If port is specified, packets that
+ match this route will be sent out that port. When port is omit‐
ted, OVN infers the output port based on nexthop. Nexthop can be
set to discard for dropping packets which match the given route.
@@ -969,23 +977,23 @@ COMMANDS
--bfd option is used to link a BFD session to the OVN route. If
the BFD session UUID is provided, it will be used for the OVN
route otherwise the next-hop will be used to perform a lookup in
- the OVN BFD table. If the lookup fails and port is specified, a
- new entry in the BFD table will be created using the nexthop as
+ the OVN BFD table. If the lookup fails and port is specified, a
+ new entry in the BFD table will be created using the nexthop as
dst_ip and port as logical_port.
It is an error if a route with prefix and POLICY already exists,
unless --may-exist, --ecmp, or --ecmp-symmetric-reply is speci‐
- fied. If --may-exist is specified but not --ecmp or --ecmp-sym‐
+ fied. If --may-exist is specified but not --ecmp or --ecmp-sym‐
metric-reply, the existed route will be updated with the new
nexthop and port. If --ecmp or --ecmp-symmetric-reply is speci‐
fied, a new route will be added, regardless of the existed
route., which is useful when adding ECMP routes, i.e. routes
with same POLICY and prefix but different nexthop and port.
- [--if-exists] [--policy=POLICY] lr-route-del router [prefix [nexthop
+ [--if-exists] [--policy=POLICY] lr-route-del router [prefix [nexthop
[port]]]
- Deletes routes from router. If only router is supplied, all the
- routes from the logical router are deleted. If POLICY, prefix,
+ Deletes routes from router. If only router is supplied, all the
+ routes from the logical router are deleted. If POLICY, prefix,
nexthop and/or port are also specified, then all the routes that
match the conditions will be deleted from the logical router.
@@ -996,30 +1004,36 @@ COMMANDS
Lists the routes on router.
Logical Router Policy Commands
- [--may-exist]lr-policy-add router priority match action [nexthop[,nex‐
+ [--may-exist]lr-policy-add router priority match action [nexthop[,nex‐
thop,...]] [options key=value]]
- Add Policy to router which provides a way to configure per‐
- mit/deny and reroute policies on the router. Permit/deny poli‐
- cies are similar to OVN ACLs, but exist on the logical-router.
- Reroute policies are needed for service-insertion and service-
- chaining. nexthop is an optional parameter. It needs to be pro‐
- vided only when action is reroute. Multiple nexthops can be
- specified for ECMP routing. A policy is uniquely identified by
- priority and match. Multiple policies can have the same prior‐
- ity. options sets the router policy options as key-value pair.
+ Add Policy to router which provides a way to configure per‐
+ mit/deny and reroute policies on the router. Permit/deny poli‐
+ cies are similar to OVN ACLs, but exist on the logical-router.
+ Reroute policies are needed for service-insertion and service-
+ chaining. nexthop is an optional parameter. It needs to be pro‐
+ vided only when action is reroute. Multiple nexthops can be
+ specified for ECMP routing. A policy is uniquely identified by
+ priority and match. Multiple policies can have the same prior‐
+ ity. options sets the router policy options as key-value pair.
The supported option is : pkt_mark.
- If --may-exist is specified, adding a duplicated routing policy
- with the same priority and match string is not really created.
- Without --may-exist, adding a duplicated routing policy results
+ If --may-exist is specified, adding a duplicated routing policy
+ with the same priority and match string is not really created.
+ Without --may-exist, adding a duplicated routing policy results
in error.
- The following example shows a policy to lr1, which will drop
+ --bfd option is used to link a BFD session to the OVN reroute
+ policy. OVN will look for an already running BFD session using
+ next-hop as lookup key in the BFD table. If the lookup fails, a
+ new entry in the BFD table will be created using the nexthop as
+ dst_ip.
+
+ The following example shows a policy to lr1, which will drop
packets from192.168.100.0/24.
lr-policy-add lr1 100 ip4.src == 192.168.100.0/24 drop.
- lr-policy-add lr1 100 ip4.src == 192.168.100.0/24 allow
+ lr-policy-add lr1 100 ip4.src == 192.168.100.0/24 allow
pkt_mark=100 .
[--if-exists] lr-policy-del router [{priority | uuid} [match]]
@@ -1036,14 +1050,14 @@ COMMANDS
Lists the polices on router.
NAT Commands
- [--may-exist] [--stateless] [--gateway_port=GATEWAY_PORT] lr-nat-add
+ [--may-exist] [--stateless] [--gateway-port=GATEWAY_PORT] lr-nat-add
router type external_ip logical_ip [logical_port external_mac]
- Adds the specified NAT to router. The type must be one of snat,
- dnat, or dnat_and_snat. The external_ip is an IPv4 address. The
- logical_ip is an IPv4 network (e.g 192.168.1.0/24) or an IPv4
- address. The logical_port and external_mac are only accepted
- when router is a distributed router (rather than a gateway
- router) and type is dnat_and_snat. The logical_port is the name
+ Adds the specified NAT to router. The type must be one of snat,
+ dnat, or dnat_and_snat. The external_ip is an IPv4 address. The
+ logical_ip is an IPv4 network (e.g 192.168.1.0/24) or an IPv4
+ address. The logical_port and external_mac are only accepted
+ when router is a distributed router (rather than a gateway
+ router) and type is dnat_and_snat. The logical_port is the name
of an existing logical switch port where the logical_ip resides.
The external_mac is an Ethernet address.
@@ -1064,69 +1078,69 @@ COMMANDS
When type is dnat, the externally visible IP address external_ip
is DNATted to the IP address logical_ip in the logical space.
- When type is snat, IP packets with their source IP address that
+ When type is snat, IP packets with their source IP address that
either matches the IP address in logical_ip or is in the network
provided by logical_ip is SNATed into the IP address in exter‐
nal_ip.
When type is dnat_and_snat, the externally visible IP address
external_ip is DNATted to the IP address logical_ip in the logi‐
- cal space. In addition, IP packets with the source IP address
- that matches logical_ip is SNATed into the IP address in exter‐
+ cal space. In addition, IP packets with the source IP address
+ that matches logical_ip is SNATed into the IP address in exter‐
nal_ip.
- When the logical_port and external_mac are specified, the NAT
- rule will be programmed on the chassis where the logical_port
- resides. This includes ARP replies for the external_ip, which
- return the value of external_mac. All packets transmitted with
- source IP address equal to external_ip will be sent using the
+ When the logical_port and external_mac are specified, the NAT
+ rule will be programmed on the chassis where the logical_port
+ resides. This includes ARP replies for the external_ip, which
+ return the value of external_mac. All packets transmitted with
+ source IP address equal to external_ip will be sent using the
external_mac.
- It is an error if a NAT already exists with the same values of
- router, type, external_ip, logical_ip and GATEWAY_PORT (in case
- of multiple distributed gateway ports), unless --may-exist is
- specified. When --may-exist, logical_port, and external_mac are
- all specified, the existing values of logical_port and exter‐
+ It is an error if a NAT already exists with the same values of
+ router, type, external_ip, logical_ip and GATEWAY_PORT (in case
+ of multiple distributed gateway ports), unless --may-exist is
+ specified. When --may-exist, logical_port, and external_mac are
+ all specified, the existing values of logical_port and exter‐
nal_mac are overwritten.
[--if-exists] lr-nat-del router [type [ip] [gateway_port]]
- Deletes NATs from router. If only router is supplied, all the
+ Deletes NATs from router. If only router is supplied, all the
NATs from the logical router are deleted. If type is also speci‐
fied, then all the NATs that match the type will be deleted from
- the logical router. If ip is also specified without specifying
- gateway_port, then all the NATs that match the type and ip will
+ the logical router. If ip is also specified without specifying
+ gateway_port, then all the NATs that match the type and ip will
be deleted from the logical router. If gateway_port is specified
without specifying ip, then all the NATs that match the type and
gateway_port will be deleted from the logical router. If all the
fields are given, then a single NAT rule that matches all the
fields will be deleted. When type is snat, the ip should be log‐
- ical_ip. When type is dnat or dnat_and_snat, the ip should be
+ ical_ip. When type is dnat or dnat_and_snat, the ip should be
external_ip.
- It is an error if both ip and gateway_port are specified and
+ It is an error if both ip and gateway_port are specified and
there is no matching NAT entry, unless --if-exists is specified.
lr-nat-list router
Lists the NATs on router.
Load Balancer Commands
- [--may-exist | --add-duplicate | --reject | --event] lb-add lb vip ips
+ [--may-exist | --add-duplicate | --reject | --event] lb-add lb vip ips
[protocol]
Creates a new load balancer named lb with the provided vip and
ips or adds the vip to an existing lb. vip should be a virtual
IP address (or an IP address and a port number with : as a sepa‐
- rator). Examples for vip are 192.168.1.4, fd0f::1, and
+ rator). Examples for vip are 192.168.1.4, fd0f::1, and
192.168.1.5:8080. ips should be comma separated IP endpoints (or
comma separated IP addresses and port numbers with : as a sepa‐
rator). ips must be the same address family as vip. Examples for
ips are 10.0.0.1,10.0.0.2or [fdef::1]:8800,[fdef::2]:8800.
- The optional argument protocol must be either tcp, udp or sctp.
- This argument is useful when a port number is provided as part
- of the vip. If the protocol is unspecified and a port number is
+ The optional argument protocol must be either tcp, udp or sctp.
+ This argument is useful when a port number is provided as part
+ of the vip. If the protocol is unspecified and a port number is
provided as part of the vip, OVN assumes the protocol to be tcp.
- It is an error if the vip already exists in the load balancer
+ It is an error if the vip already exists in the load balancer
named lb, unless --may-exist is specified. With --add-duplicate,
the command really creates a new load balancer with a duplicate
name.
@@ -1155,34 +1169,34 @@ COMMANDS
lb, unless --if-exists is specified.
lb-list [lb]
- Lists the LBs. If lb is also specified, then only the specified
+ Lists the LBs. If lb is also specified, then only the specified
lb will be listed.
[--may-exist] ls-lb-add switch lb
- Adds the specified lb to switch. It is an error if a load bal‐
- ancer named lb already exists in the switch, unless --may-exist
+ Adds the specified lb to switch. It is an error if a load bal‐
+ ancer named lb already exists in the switch, unless --may-exist
is specified.
[--if-exists] ls-lb-del switch [lb]
- Removes lb from switch. If only switch is supplied, all the LBs
- from the logical switch are removed. If lb is also specified,
- then only the lb will be removed from the logical switch. It is
- an error if lb does not exist in the switch, unless --if-exists
+ Removes lb from switch. If only switch is supplied, all the LBs
+ from the logical switch are removed. If lb is also specified,
+ then only the lb will be removed from the logical switch. It is
+ an error if lb does not exist in the switch, unless --if-exists
is specified.
ls-lb-list switch
Lists the LBs for the given switch.
[--may-exist] lr-lb-add router lb
- Adds the specified lb to router. It is an error if a load bal‐
- ancer named lb already exists in the router, unless --may-exist
+ Adds the specified lb to router. It is an error if a load bal‐
+ ancer named lb already exists in the router, unless --may-exist
is specified.
[--if-exists] lr-lb-del router [lb]
- Removes lb from router. If only router is supplied, all the LBs
- from the logical router are removed. If lb is also specified,
- then only the lb will be removed from the logical router. It is
- an error if lb does not exist in the router, unless --if-exists
+ Removes lb from router. If only router is supplied, all the LBs
+ from the logical router are removed. If lb is also specified,
+ then only the lb will be removed from the logical router. It is
+ an error if lb does not exist in the router, unless --if-exists
is specified.
lr-lb-list router
@@ -1190,7 +1204,7 @@ COMMANDS
DHCP Options commands
dhcp-options-create cidr [key=value]
- Creates a new DHCP Options entry in the DHCP_Options table with
+ Creates a new DHCP Options entry in the DHCP_Options table with
the specified cidr and optional external-ids.
dhcp-options-list
@@ -1207,33 +1221,34 @@ COMMANDS
Port Group commands
pg-add group [port]...
- Creates a new port group in the Port_Group table named group
+ Creates a new port group in the Port_Group table named group
with optional ports added to the group.
pg-set-ports group port...
- Sets ports on the port group named group. It is an error if
+ Sets ports on the port group named group. It is an error if
group does not exist.
pg-del group
- Deletes port group group. It is an error if group does not
- exist.
+ Deletes port group group. It is an error if group does not ex‐
+ ist.
HA Chassis Group commands
ha-chassis-group-add group
- Creates a new HA chassis group in the HA_Chassis_Group table
+ Creates a new HA chassis group in the HA_Chassis_Group table
named group.
ha-chassis-group-del group
Deletes the HA chassis group group. It is an error if group does
not exist.
- ha-chassis-group-list
- Lists the HA chassis group group along with the HA chassis if
- any associated with it.
+ ha-chassis-group-list [ha-chassis-group]
+ Lists all HA chassis groups along with the HA chassis if any as‐
+ sociated with it. If ha-chassis-group is also specified, then
+ only the specified ha-chassis-group will be listed.
ha-chassis-group-add-chassis group chassis priority
Adds a new HA chassis chassis to the HA Chassis group group with
- the specified priority. If the chassis already exists, then the
+ the specified priority. If the chassis already exists, then the
priority is updated. The chassis should be the name of the chas‐
sis in the OVN_Southbound.
@@ -1243,41 +1258,41 @@ COMMANDS
Control Plane Protection Policy commands
These commands manage meters configured in Copp table linking them to
- logical datapaths through copp column in Logical_Switch or Logi‐
+ logical datapaths through copp column in Logical_Switch or Logi‐
cal_Router tables. Protocol packets for which CoPP is enforced when
sending packets to ovn-controller (if configured):
- · ARP
+ • ARP
- · ND_NS
+ • ND_NS
- · ND_NA
+ • ND_NA
- · ND_RA
+ • ND_RA
- · ND
+ • ND
- · DNS
+ • DNS
- · IGMP
+ • IGMP
- · packets that require ARP resolution before forwarding
+ • packets that require ARP resolution before forwarding
- · packets that require ND_NS before forwarding
+ • packets that require ND_NS before forwarding
- · packets that need to be replied to with ICMP Errors
+ • packets that need to be replied to with ICMP Errors
- · packets that need to be replied to with TCP RST
+ • packets that need to be replied to with TCP RST
- · packets that need to be replied to with DHCP_OPTS
+ • packets that need to be replied to with DHCP_OPTS
- · packets that trigger a reject action
+ • packets that trigger a reject action
- · packets that trigger a SCTP abort action
+ • packets that trigger a SCTP abort action
- · controller_events
+ • controller_events
- · BFD
+ • BFD
copp-add name proto meter
Adds the control proto to meter mapping to the control
@@ -1303,18 +1318,23 @@ COMMANDS
ical router router.
Mirror commands
- mirror-add m type index filter dest
+ mirror-add m type [index] filter dest
Creates a new mirror in the Mirror table with the name m with
the below mandatory arguments.
- type specifies the mirror type - gre or erspan.
+ type specifies the mirror type - gre , erspan or local.
- index specifies the tunnel index value (which is an integer).
+ index specifies the tunnel index value (which is an integer) if
+ the type is gre or erspan.
- filter specifies the mirror source selection. Can be from-lport
- or to-lport.
+ filter specifies the mirror source selection. Can be from-lport,
+ to-lport or both.
- dest specifies the mirror destination IP (v4 or v6).
+ dest specifies the mirror destination IP (v4 or v6) if the type
+ is gre or erspan. For a type of local, this field defines a lo‐
+ cal interface on the OVS integration bridge to be used as the
+ mirror destination. The interface must possess external-ids:mir‐
+ ror-id that matches this string.
mirror-del m
Deletes the mirror m.
@@ -1325,17 +1345,17 @@ COMMANDS
Synchronization Commands
sync Ordinarily, --wait=sb or --wait=hv only waits for changes by the
current ovn-nbctl invocation to take effect. This means that, if
- none of the commands supplied to ovn-nbctl change the database,
- then the command does not wait at all. With the sync command,
- however, ovn-nbctl waits even for earlier changes to the data‐
- base to propagate down to the southbound database or all of the
+ none of the commands supplied to ovn-nbctl change the database,
+ then the command does not wait at all. With the sync command,
+ however, ovn-nbctl waits even for earlier changes to the data‐
+ base to propagate down to the southbound database or all of the
OVN chassis, according to the argument to --wait.
Remote Connectivity Commands
These commands manipulate the connections column in the NB_Global table
and rows in the Connection table. When ovsdb-server is configured to
- use the connections column for OVSDB connections, this allows the
- administrator to use ovn-nbctl to configure database connections.
+ use the connections column for OVSDB connections, this allows the ad‐
+ ministrator to use ovn-nbctl to configure database connections.
get-connection
Prints the configured connection(s).
@@ -1344,10 +1364,10 @@ COMMANDS
Deletes the configured connection(s).
[--inactivity-probe=msecs] set-connection target...
- Sets the configured manager target or targets. Use
- --inactivity-probe=msecs to override the default idle
- connection inactivity probe time. Use 0 to disable inac‐
- tivity probes.
+ Sets the configured manager target or targets. Use --in‐
+ activity-probe=msecs to override the default idle connec‐
+ tion inactivity probe time. Use 0 to disable inactivity
+ probes.
SSL Configuration Commands
get-ssl
@@ -1356,7 +1376,7 @@ COMMANDS
del-ssl
Deletes the current SSL configuration.
- [--bootstrap] set-ssl private-key certificate ca-cert [ssl-protocol-
+ [--bootstrap] set-ssl private-key certificate ca-cert [ssl-protocol-
list [ssl-cipher-list]]
Sets the SSL configuration.
@@ -1369,20 +1389,20 @@ COMMANDS
Each of these commands has a table parameter to identify a table within
the database. Many of them also take a record parameter that identifies
- a particular record within a table. The record parameter may be the
- UUID for a record, which may be abbreviated to its first 4 (or more)
- hex digits, as long as that is unique. Many tables offer additional
- ways to identify records. Some commands also take column parameters
+ a particular record within a table. The record parameter may be the
+ UUID for a record, which may be abbreviated to its first 4 (or more)
+ hex digits, as long as that is unique. Many tables offer additional
+ ways to identify records. Some commands also take column parameters
that identify a particular field within the records in a table.
- For a list of tables and their columns, see ovn-nb(5) or see the table
+ For a list of tables and their columns, see ovn-nb(5) or see the table
listing from the --help option.
Record names must be specified in full and with correct capitalization,
except that UUIDs may be abbreviated to their first 4 (or more) hex
digits, as long as that is unique within the table. Names of tables and
- columns are not case-sensitive, and - and _ are treated interchange‐
- ably. Unique abbreviations of table and column names are acceptable,
+ columns are not case-sensitive, and - and _ are treated interchange‐
+ ably. Unique abbreviations of table and column names are acceptable,
e.g. d or dhcp is sufficient to identify the DHCP_Options table.
Database Values
@@ -1404,40 +1424,40 @@ COMMANDS
begin with an English letter or underscore and consist
only of letters, underscores, hyphens, and periods. How‐
ever, true and false and strings that match the syntax of
- UUIDs (see below) must be enclosed in double quotes to
- distinguish them from other basic types. When double
- quotes are used, the syntax is that of strings in JSON,
- e.g. backslashes may be used to escape special charac‐
- ters. The empty string must be represented as a pair of
+ UUIDs (see below) must be enclosed in double quotes to
+ distinguish them from other basic types. When double
+ quotes are used, the syntax is that of strings in JSON,
+ e.g. backslashes may be used to escape special charac‐
+ ters. The empty string must be represented as a pair of
double quotes ("").
- UUID Either a universally unique identifier in the style of
- RFC 4122, e.g. f81d4fae-7dec-11d0-a765-00a0c91e6bf6, or
- an @name defined by a get or create command within the
+ UUID Either a universally unique identifier in the style of
+ RFC 4122, e.g. f81d4fae-7dec-11d0-a765-00a0c91e6bf6, or
+ an @name defined by a get or create command within the
same ovs-vsctl invocation.
Multiple values in a single column may be separated by spaces or a sin‐
- gle comma. When multiple values are present, duplicates are not
- allowed, and order is not important. Conversely, some database columns
+ gle comma. When multiple values are present, duplicates are not al‐
+ lowed, and order is not important. Conversely, some database columns
can have an empty set of values, represented as [], and square brackets
may optionally enclose other non-empty sets or single values as well.
- A few database columns are ``maps’’ of key-value pairs, where the key
+ A few database columns are ``maps’’ of key-value pairs, where the key
and the value are each some fixed database type. These are specified in
the form key=value, where key and value follow the syntax for the col‐
umn’s key type and value type, respectively. When multiple pairs are
- present (separated by spaces or a comma), duplicate keys are not
- allowed, and again the order is not important. Duplicate values are
- allowed. An empty map is represented as {}. Curly braces may optionally
+ present (separated by spaces or a comma), duplicate keys are not al‐
+ lowed, and again the order is not important. Duplicate values are al‐
+ lowed. An empty map is represented as {}. Curly braces may optionally
enclose non-empty maps as well (but use quotes to prevent the shell
- from expanding other-config={0=x,1=y} into other-config=0=x other-con‐
+ from expanding other-config={0=x,1=y} into other-config=0=x other-con‐
fig=1=y, which may not have the desired effect).
Database Command Syntax
- [--if-exists] [--columns=column[,column]...] list table
+ [--if-exists] [--columns=column[,column]...] list table
[record]...
- Lists the data in each specified record. If no records
+ Lists the data in each specified record. If no records
are specified, lists all the records in table.
If --columns is specified, only the requested columns are
@@ -1445,32 +1465,32 @@ COMMANDS
are listed, in alphabetical order by column name.
Without --if-exists, it is an error if any specified
- record does not exist. With --if-exists, the command
- ignores any record that does not exist, without producing
+ record does not exist. With --if-exists, the command ig‐
+ nores any record that does not exist, without producing
any output.
- [--columns=column[,column]...] find table [col‐
+ [--columns=column[,column]...] find table [col‐
umn[:key]=value]...
- Lists the data in each record in table whose column
- equals value or, if key is specified, whose column con‐
+ Lists the data in each record in table whose column
+ equals value or, if key is specified, whose column con‐
tains a key with the specified value. The following oper‐
ators may be used where = is written in the syntax sum‐
mary:
= != < > <= >=
Selects records in which column[:key] equals, does
- not equal, is less than, is greater than, is less
- than or equal to, or is greater than or equal to
+ not equal, is less than, is greater than, is less
+ than or equal to, or is greater than or equal to
value, respectively.
- Consider column[:key] and value as sets of ele‐
+ Consider column[:key] and value as sets of ele‐
ments. Identical sets are considered equal. Other‐
wise, if the sets have different numbers of ele‐
ments, then the set with more elements is consid‐
ered to be larger. Otherwise, consider a element
from each set pairwise, in increasing order within
- each set. The first pair that differs determines
- the result. (For a column that contains key-value
+ each set. The first pair that differs determines
+ the result. (For a column that contains key-value
pairs, first all the keys are compared, and values
are considered only if the two sets contain iden‐
tical keys.)
@@ -1489,30 +1509,30 @@ COMMANDS
the empty set or contains 1 or 2 but not both.
{>=} {>}
- Same as {<=} and {<}, respectively, except that
- the relationship is reversed. For example,
- flood-vlans{>=}1,2 selects records in which the
+ Same as {<=} and {<}, respectively, except that
+ the relationship is reversed. For example,
+ flood-vlans{>=}1,2 selects records in which the
flood-vlans column contains both 1 and 2.
The following operators are available only in Open
vSwitch 2.16 and later:
- {in} Selects records in which every element in col‐
- umn[:key] is also in value. (This is the same as
+ {in} Selects records in which every element in col‐
+ umn[:key] is also in value. (This is the same as
{<=}.)
{not-in}
- Selects records in which every element in col‐
+ Selects records in which every element in col‐
umn[:key] is not in value.
- For arithmetic operators (= != < > <= >=), when key is
- specified but a particular record’s column does not con‐
- tain key, the record is always omitted from the results.
- Thus, the condition other-config:mtu!=1500 matches
- records that have a mtu key whose value is not 1500, but
+ For arithmetic operators (= != < > <= >=), when key is
+ specified but a particular record’s column does not con‐
+ tain key, the record is always omitted from the results.
+ Thus, the condition other-config:mtu!=1500 matches
+ records that have a mtu key whose value is not 1500, but
not those that lack an mtu key.
- For the set operators, when key is specified but a par‐
+ For the set operators, when key is specified but a par‐
ticular record’s column does not contain key, the compar‐
ison is done against an empty set. Thus, the condition
other-config:mtu{!=}1500 matches records that have a mtu
@@ -1540,9 +1560,9 @@ COMMANDS
record. With --if-exists, a missing record yields no out‐
put and a missing key prints a blank line.
- If @name is specified, then the UUID for record may be
- referred to by that name later in the same ovs-vsctl
- invocation in contexts where a UUID is expected.
+ If @name is specified, then the UUID for record may be
+ referred to by that name later in the same ovs-vsctl in‐
+ vocation in contexts where a UUID is expected.
Both --id and the column arguments are optional, but usu‐
ally at least one or the other should be specified. If
@@ -1552,41 +1572,40 @@ COMMANDS
--id and --if-exists cannot be used together.
[--if-exists] set table record column[:key]=value...
- Sets the value of each specified column in the given
- record in table to value. For map columns, a key may
- optionally be specified, in which case the value associ‐
- ated with key in that column is changed (or added, if
- none exists), instead of the entire map.
+ Sets the value of each specified column in the given
+ record in table to value. For map columns, a key may op‐
+ tionally be specified, in which case the value associated
+ with key in that column is changed (or added, if none ex‐
+ ists), instead of the entire map.
- Without --if-exists, it is an error if record does not
- exist. With --if-exists, this command does nothing if
+ Without --if-exists, it is an error if record does not
+ exist. With --if-exists, this command does nothing if
record does not exist.
[--if-exists] add table record column [key=]value...
- Adds the specified value or key-value pair to column in
- record in table. If column is a map, then key is
- required, otherwise it is prohibited. If key already
- exists in a map column, then the current value is not
- replaced (use the set command to replace an existing
- value).
+ Adds the specified value or key-value pair to column in
+ record in table. If column is a map, then key is re‐
+ quired, otherwise it is prohibited. If key already exists
+ in a map column, then the current value is not replaced
+ (use the set command to replace an existing value).
- Without --if-exists, it is an error if record does not
- exist. With --if-exists, this command does nothing if
+ Without --if-exists, it is an error if record does not
+ exist. With --if-exists, this command does nothing if
record does not exist.
[--if-exists] remove table record column value...
[--if-exists] remove table record column key...
- [--if-exists] remove table record column key=value...
+ [--if-exists] remove table record column key=value...
Removes the specified values or key-value pairs from col‐
umn in record in table. The first form applies to columns
- that are not maps: each specified value is removed from
- the column. The second and third forms apply to map col‐
- umns: if only a key is specified, then any key-value pair
- with the given key is removed, regardless of its value;
- if a value is given then a pair is removed only if both
- key and value match.
+ that are not maps: each specified value is removed from
+ the column. The second and third forms apply to map
+ columns: if only a key is specified, then any key-value
+ pair with the given key is removed, regardless of its
+ value; if a value is given then a pair is removed only if
+ both key and value match.
It is not an error if the column does not contain the
specified key or value or pair.
@@ -1606,12 +1625,12 @@ COMMANDS
[--id=(@name|uuid)] create table column[:key]=value...
Creates a new record in table and sets the initial values
- of each column. Columns not explicitly set will receive
+ of each column. Columns not explicitly set will receive
their default values. Outputs the UUID of the new row.
- If @name is specified, then the UUID for the new row may
- be referred to by that name elsewhere in the same \*(PN
- invocation in contexts where a UUID is expected. Such
+ If @name is specified, then the UUID for the new row may
+ be referred to by that name elsewhere in the same \*(PN
+ invocation in contexts where a UUID is expected. Such
references may precede or follow the create command.
If a valid uuid is specified, then it is used as the UUID
@@ -1619,23 +1638,23 @@ COMMANDS
Caution (ovs-vsctl as example)
Records in the Open vSwitch database are signifi‐
- cant only when they can be reached directly or
- indirectly from the Open_vSwitch table. Except for
- records in the QoS or Queue tables, records that
- are not reachable from the Open_vSwitch table are
+ cant only when they can be reached directly or in‐
+ directly from the Open_vSwitch table. Except for
+ records in the QoS or Queue tables, records that
+ are not reachable from the Open_vSwitch table are
automatically deleted from the database. This
- deletion happens immediately, without waiting for
- additional ovs-vsctl commands or other database
+ deletion happens immediately, without waiting for
+ additional ovs-vsctl commands or other database
activity. Thus, a create command must generally be
accompanied by additional commands within the same
- ovs-vsctl invocation to add a chain of references
- to the newly created record from the top-level
- Open_vSwitch record. The EXAMPLES section gives
+ ovs-vsctl invocation to add a chain of references
+ to the newly created record from the top-level
+ Open_vSwitch record. The EXAMPLES section gives
some examples that show how to do this.
[--if-exists] destroy table record...
- Deletes each specified record from table. Unless
- --if-exists is specified, each records must exist.
+ Deletes each specified record from table. Unless --if-ex‐
+ ists is specified, each records must exist.
--all destroy table
Deletes all records from the table.
@@ -1654,19 +1673,19 @@ COMMANDS
wait-until table record [column[:key]=value]...
Waits until table contains a record named record whose
column equals value or, if key is specified, whose column
- contains a key with the specified value. This command
- supports the same operators and semantics described for
+ contains a key with the specified value. This command
+ supports the same operators and semantics described for
the find command above.
- If no column[:key]=value arguments are given, this com‐
- mand waits only until record exists. If more than one
- such argument is given, the command waits until all of
+ If no column[:key]=value arguments are given, this com‐
+ mand waits only until record exists. If more than one
+ such argument is given, the command waits until all of
them are satisfied.
Caution (ovs-vsctl as example)
- Usually wait-until should be placed at the begin‐
- ning of a set of ovs-vsctl commands. For example,
- wait-until bridge br0 -- get bridge br0 data‐
+ Usually wait-until should be placed at the begin‐
+ ning of a set of ovs-vsctl commands. For example,
+ wait-until bridge br0 -- get bridge br0 data‐
path_id waits until a bridge named br0 is created,
then prints its datapath_id column, whereas get
bridge br0 datapath_id -- wait-until bridge br0
@@ -1688,11 +1707,11 @@ ENVIRONMENT
server process. See Daemon Mode, above, for more information.
OVN_NBCTL_OPTIONS
- If set, a set of options for ovn-nbctl to apply automatically,
+ If set, a set of options for ovn-nbctl to apply automatically,
in the same form as on the command line.
OVN_NB_DB
- If set, the default database to contact when the --db option is
+ If set, the default database to contact when the --db option is
not used.
EXIT STATUS
@@ -1703,6 +1722,4 @@ EXIT STATUS
SEE ALSO
ovn-nb(5), ovn-appctl(8).
-
-
-OVN 22.12.90 ovn-nbctl ovn-nbctl(8)
+OVN 24.03.90 ovn-nbctl ovn-nbctl(8)
diff --git a/src/static/support/dist-docs/ovn-northd.8 b/src/static/support/dist-docs/ovn-northd.8
index c652a2aa..1e910156 100644
--- a/src/static/support/dist-docs/ovn-northd.8
+++ b/src/static/support/dist-docs/ovn-northd.8
@@ -1,6 +1,6 @@
'\" p
.\" -*- nroff -*-
-.TH "ovn-northd" 8 "ovn-northd" "OVN 22\[char46]12\[char46]90" "OVN Manual"
+.TH "ovn-northd" 8 "ovn-northd" "OVN 24\[char46]03\[char46]90" "OVN Manual"
.fp 5 L CR \\" Make fixed-width font available as \\fL.
.de TQ
. br
@@ -21,7 +21,7 @@
.SH "NAME"
.PP
.PP
-ovn-northd and ovn-northd-ddlog \- Open Virtual Network central control daemon
+ovn-northd \- Open Virtual Network central control daemon
.SH "SYNOPSIS"
.PP
\fBovn\-northd\fR [\fIoptions\fR]
@@ -29,9 +29,6 @@ ovn-northd and ovn-northd-ddlog \- Open Virtual Network central control daemon
.PP
.PP
\fBovn\-northd\fR is a centralized daemon responsible for translating the high-level OVN configuration into logical configuration consumable by daemons such as \fBovn\-controller\fR\[char46] It translates the logical network configuration in terms of conventional network concepts, taken from the OVN Northbound Database (see \fBovn\-nb\fR(5)), into logical datapath flows in the OVN Southbound Database (see \fBovn\-sb\fR(5)) below it\[char46]
-.PP
-.PP
-\fBovn\-northd\fR is implemented in C\[char46] \fBovn\-northd\-ddlog\fR is a compatible implementation written in DDlog, a language for incremental database processing\[char46] This documentation applies to both implementations, with differences indicated where relevant\[char46]
.SH "OPTIONS"
.TP
\fB\-\-ovnnb\-db=\fIdatabase\fB\fR
@@ -40,21 +37,14 @@ The OVSDB database containing the OVN Northbound Database\[char46] If the \fBOVN
\fB\-\-ovnsb\-db=\fIdatabase\fB\fR
The OVSDB database containing the OVN Southbound Database\[char46] If the \fBOVN_SB_DB\fR environment variable is set, its value is used as the default\[char46] Otherwise, the default is \fBunix:/ovnsb_db\[char46]sock\fR\[char46]
.TP
-\fB\-\-ddlog\-record=\fIfile\fB\fR
-This option is for \fBovn\-north\-ddlog\fR only\[char46] It causes the daemon to record the initial database state and later changes to \fIfile\fR in the text-based DDlog command format\[char46] The \fBovn_northd_cli\fR program can later replay these changes for debugging purposes\[char46] This option has a performance impact\[char46] See \fBdebugging\-ddlog\[char46]rst\fR in the OVN documentation for more details\[char46]
-.TP
\fB\-\-dry\-run\fR
Causes \fBovn\-northd\fR to start paused\[char46] In the paused state, \fBovn\-northd\fR does not apply any changes to the databases, although it continues to monitor them\[char46] For more information, see the \fBpause\fR command, under \fBRuntime Management
Commands\fR below\[char46]
-.IP
-For \fBovn\-northd\-ddlog\fR, one could use this option with \fB\-\-ddlog\-record\fR to generate a replay log without restarting a process or disturbing a running system\[char46]
.TP
\fBn\-threads N\fR
In certain situations, it may be desirable to enable parallelization on a system to decrease latency (at the potential cost of increasing CPU usage)\[char46]
.IP
This option will cause ovn-northd to use N threads when building logical flows, when N is within [2\-256]\[char46] If N is 1, parallelization is disabled (default behavior)\[char46] If N is less than 1, then N is set to 1, parallelization is disabled and a warning is logged\[char46] If N is more than 256, then N is set to 256, parallelization is enabled (with 256 threads) and a warning is logged\[char46]
-.IP
-ovn-northd-ddlog does not support this option\[char46]
.PP
.PP
\fIdatabase\fR in the above options must be an OVSDB active or passive connection method, as described in \fBovsdb\fR(7)\[char46]
@@ -251,19 +241,6 @@ Display the \fBovn\-northd\fR engine counter(s) for the specified \fIengine_node
\fBinc\-engine/clear\-stats\fR
Reset \fBovn\-northd\fR engine counters\[char46]
.RE
-.PP
-.PP
-Only \fBovn\-northd\-ddlog\fR supports the following commands:
-.RS
-.TP
-\fBenable\-cpu\-profiling\fR
-.TQ .5in
-\fBdisable\-cpu\-profiling\fR
-Enables or disables profiling of CPU time used by the DDlog engine\[char46] When CPU profiling is enabled, the \fBprofile\fR command (see below) will include DDlog CPU usage statistics in its output\[char46] Enabling CPU profiling will slow \fBovn\-northd\-ddlog\fR\[char46] Disabling CPU profiling does not clear any previously recorded statistics\[char46]
-.TP
-\fBprofile\fR
-Outputs a profile of the current and peak sizes of arrangements inside DDlog\[char46] This profiling data can be useful for optimizing DDlog code\[char46] If CPU profiling was previously enabled (even if it was later disabled), the output also includes a CPU time profile\[char46] See \fBProfiling\fR inside the tutorial in the DDlog repository for an introduction to profiling DDlog\[char46]
-.RE
.SH "ACTIVE-STANDBY FOR HIGH AVAILABILITY"
.PP
.PP
@@ -299,7 +276,7 @@ Priority 100 flows to drop packets with VLAN tags or multicast Ethernet source a
.IP \(bu
For each disabled logical port, a priority 100 flow is added which matches on all packets and applies the action \fBREGBIT_PORT_SEC_DROP\(dq = 1; next;\(dq\fR so that the packets are dropped in the next stage\[char46]
.IP \(bu
-For each (enabled) vtep logical port, a priority 70 flow is added which matches on all packets and applies the action \fBnext(pipeline=ingress, table=S_SWITCH_IN_L2_LKUP) = 1;\fR to skip most stages of ingress pipeline and go directly to ingress L2 lookup table to determine the output port\[char46] Packets from VTEP (RAMP) switch should not be subjected to any ACL checks\[char46] Egress pipeline will do the ACL checks\[char46]
+For each (enabled) vtep logical port, a priority 70 flow is added which matches on all packets and applies the action \fBnext(pipeline=ingress, table=S_SWITCH_IN_L3_LKUP) = 1;\fR to skip most stages of ingress pipeline and go directly to ingress L2 lookup table to determine the output port\[char46] Packets from VTEP (RAMP) switch should not be subjected to any ACL checks\[char46] Egress pipeline will do the ACL checks\[char46]
.IP \(bu
For each enabled logical port configured with qdisc queue id in the \fBoptions:qdisc_queue_id\fR column of \fBLogical_Switch_Port\fR, a priority 70 flow is added which matches on all packets and applies the action \fBset_queue(id);
REGBIT_PORT_SEC_DROP\(dq = check_in_port_sec(); next;\(dq\fR\[char46]
@@ -309,6 +286,18 @@ A priority 1 flow is added which matches on all packets for all the logical port
.ST "Ingress Table 1: Ingress Port Security - Apply"
.PP
.PP
+For each logical switch port \fIP\fR of type router connected to a gw router a priority\-120 flow that matches \(cqrecirculated\(cq icmp{4,6} error \(cqpacket too big\(cq and \fBeth\[char46]src == \fID\fB &&
+outport == \fIP\fB && flags\[char46]tunnel_rx == 1\fR where \fID\fR is the peer logical router port \fIRP\fR mac address, swaps inport and outport and applies the action \fB
+next(pipeline=S_SWITCH_IN_L2_LKUP)\fR\[char46]
+.PP
+.PP
+For each logical switch port \fIP\fR of type router connected to a distributed router a priority\-120 flow that matches \(cqrecirculated\(cq icmp{4,6} error \(cqpacket too big\(cq and \fBeth\[char46]dst == \fID\fB
+&& flags\[char46]tunnel_rx == 1\fR where \fID\fR is the peer logical router port \fIRP\fR mac address, swaps inport and outport and applies the action \fB next(pipeline=S_SWITCH_IN_L2_LKUP)\fR\[char46]
+.PP
+.PP
+This table adds a priority\-110 flow that matches \(cqrecirculated\(cq icmp{4,6} error \(cqpacket too big\(cq to drop the packet\[char46]
+.PP
+.PP
This table drops the packets if the port security check failed in the previous stage i\[char46]e the register bit \fBREGBIT_PORT_SEC_DROP\fR is set to 1\[char46]
.PP
.PP
@@ -322,24 +311,30 @@ One priority\-0 fallback flow that matches all packets and advances to the next
.ST "Ingress Table 2: Lookup MAC address learning table"
.PP
.PP
-This table looks up the MAC learning table of the logical switch datapath to check if the \fBport\-mac\fR pair is present or not\[char46] MAC is learnt only for logical switch VIF ports whose port security is disabled and \(cqunknown\(cq address set\[char46]
+This table looks up the MAC learning table of the logical switch datapath to check if the \fBport\-mac\fR pair is present or not\[char46] MAC is learnt for logical switch VIF ports whose port security is disabled and \(cqunknown\(cq address setn as well as for localnet ports with option localnet_learn_fdb\[char46] A localnet port entry does not overwrite a VIF port entry\[char46]
.RS
.IP \(bu
-For each such logical port \fIp\fR whose port security is disabled and \(cqunknown\(cq address set following flow is added\[char46]
+For each such VIF logical port \fIp\fR whose port security is disabled and \(cqunknown\(cq address set following flow is added\[char46]
.RS
.IP \(bu
Priority 100 flow with the match \fBinport == \fIp\fB\fR and action \fBreg0[11] = lookup_fdb(inport, eth\[char46]src); next;\fR
.RE
.IP \(bu
+For each such localnet logical port \fIp\fR following flow is added\[char46]
+.RS
+.IP \(bu
+Priority 100 flow with the match \fBinport == \fIp\fB\fR and action \fBflags\[char46]localnet = 1;\fR \fBreg0[11] = lookup_fdb(inport, eth\[char46]src); next;\fR
+.RE
+.IP \(bu
One priority\-0 fallback flow that matches all packets and advances to the next table\[char46]
.RE
.ST "Ingress Table 3: Learn MAC of \(cqunknown\(cq ports\[char46]"
.PP
.PP
-This table learns the MAC addresses seen on the logical ports whose port security is disabled and \(cqunknown\(cq address set if the \fBlookup_fdb\fR action returned false in the previous table\[char46]
+This table learns the MAC addresses seen on the VIF logical ports whose port security is disabled and \(cqunknown\(cq address set as well as on localnet ports with localnet_learn_fdb option set if the \fBlookup_fdb\fR action returned false in the previous table\[char46] For localnet ports (with flags\[char46]localnet = 1), lookup_fdb returns true if (port, mac) is found or if a mac is found for a port of type vif\[char46]
.RS
.IP \(bu
-For each such logical port \fIp\fR whose port security is disabled and \(cqunknown\(cq address set following flow is added\[char46]
+For each such VIF logical port \fIp\fR whose port security is disabled and \(cqunknown\(cq address set and localnet port following flow is added\[char46]
.RS
.IP \(bu
Priority 100 flow with the match \fBinport == \fIp\fB && reg0[11] == 0\fR and action \fBput_fdb(inport, eth\[char46]src); next;\fR which stores the \fBport\-mac\fR in the mac learning table of the logical switch datapath and advances the packet to the next table\[char46]
@@ -350,7 +345,7 @@ One priority\-0 fallback flow that matches all packets and advances to the next
.ST "Ingress Table 4: \fBfrom\-lport\fI Pre-ACLs"
.PP
.PP
-This table prepares flows for possible stateful ACL processing in ingress table \fBACLs\fR\[char46] It contains a priority\-0 flow that simply moves traffic to the next table\[char46] If stateful ACLs are used in the logical datapath, a priority\-100 flow is added that sets a hint (with \fBreg0[0] = 1; next;\fR) for table \fBPre\-stateful\fR to send IP packets to the connection tracker before eventually advancing to ingress table \fBACLs\fR\[char46] If special ports such as route ports or localnet ports can\(cqt use ct(), a priority\-110 flow is added to skip over stateful ACLs\[char46] Multicast, IPv6 Neighbor Discovery and MLD traffic also skips stateful ACLs\[char46] For \(dqallow-stateless\(dq ACLs, a flow is added to bypass setting the hint for connection tracker processing when there are stateful ACLs or LB rules; \fBREGBIT_ACL_STATELESS\fR is set for traffic matching stateless ACL flows\[char46]
+This table prepares flows for possible stateful ACL processing in ingress table \fBACLs\fR\[char46] It contains a priority\-0 flow that simply moves traffic to the next table\[char46] If stateful ACLs are used in the logical datapath, a priority\-100 flow is added that sets a hint (with \fBreg0[0] = 1; next;\fR) for table \fBPre\-stateful\fR to send IP packets to the connection tracker before eventually advancing to ingress table \fBACLs\fR\[char46] If special ports such as route ports or localnet ports can\(cqt use ct(), a priority\-110 flow is added to skip over stateful ACLs\[char46] This priority\-110 flow is not addd for router ports if the option enable_router_port_acl is set to true in \fBoptions:enable_router_port_acl\fR column of \fBLogical_Switch_Port\fR\[char46] Multicast, IPv6 Neighbor Discovery and MLD traffic also skips stateful ACLs\[char46] For \(dqallow-stateless\(dq ACLs, a flow is added to bypass setting the hint for connection tracker processing when there are stateful ACLs or LB rules; \fBREGBIT_ACL_STATELESS\fR is set for traffic matching stateless ACL flows\[char46]
.PP
.PP
This table also has a priority\-110 flow with the match \fBeth\[char46]dst == \fIE\fB\fR for all logical switch datapaths to move traffic to the next table\[char46] Where \fIE\fR is the service monitor mac defined in the \fBoptions:svc_monitor_mac\fR column of \fBNB_Global\fR table\[char46]
@@ -422,27 +417,36 @@ A priority\-2 flow that matches on packets that are part of an established sessi
.IP \(bu
A priority\-1 flow that matches on packets that are part of an established session that has not been marked as blocked\[char46] This flow sets \fBreg0[10]\fR and then advances to the next table\[char46]
.RE
-.ST "Ingress table 8: \fBfrom\-lport\fI ACLs before LB"
+.ST "Ingress table 8: \fBfrom\-lport\fI ACL evaluation before LB"
.PP
.PP
Logical flows in this table closely reproduce those in the \fBACL\fR table in the \fBOVN_Northbound\fR database for the \fBfrom\-lport\fR direction without the option \fBapply\-after\-lb\fR set or set to \fBfalse\fR\[char46] The \fBpriority\fR values from the \fBACL\fR table have a limited range and have 1000 added to them to leave room for OVN default flows at both higher and lower priorities\[char46]
.RS
.IP \(bu
-\fBallow\fR ACLs translate into logical flows with the \fBnext;\fR action\[char46] If there are any stateful ACLs on this datapath, then \fBallow\fR ACLs translate to \fBct_commit; next;\fR (which acts as a hint for the next tables to commit the connection to conntrack)\[char46] In case the \fBACL\fR has a label then \fBreg3\fR is loaded with the label value and \fBreg0[13]\fR bit is set to 1 (which acts as a hint for the next tables to commit the label to conntrack)\[char46]
+This table is responsible for evaluating ACLs, and setting a register bit to indicate whether the ACL decided to allow, drop, or reject the traffic\[char46] The allow bit is \fBreg8[16]\fR\[char46] The drop bit is \fBreg8[17]\fR\[char46] All flows in this table will advance the packet to the next table, where the bits from before are evaluated to determine what to do with the packet\[char46] Any flows in this table that intend for the packet to pass will set \fBreg8[16]\fR to 1, even if an ACL with an allow-type action was not matched\[char46] This lets the next table know to allow the traffic to pass\[char46] These bits will be referred to as the \(dqallow\(dq, \(dqdrop\(dq, and \(dqreject\(dq bits in the upcoming paragraphs\[char46]
.IP \(bu
-\fBallow\-related\fR ACLs translate into logical flows with the \fBct_commit(ct_label=0/1); next;\fR actions for new connections and \fBreg0[1] = 1; next;\fR for existing connections\[char46] In case the \fBACL\fR has a label then \fBreg3\fR is loaded with the label value and \fBreg0[13]\fR bit is set to 1 (which acts as a hint for the next tables to commit the label to conntrack)\[char46]
+If the \fBtier\fR column has been configured on the ACL, then OVN will also match the current tier counter against the configured ACL tier\[char46] OVN keeps count of the current tier in \fBreg8[30\[char46]\[char46]31]\fR\[char46]
.IP \(bu
-\fBallow\-stateless\fR ACLs translate into logical flows with the \fBnext;\fR action\[char46]
+\fBallow\fR ACLs translate into logical flows that set the allow bit to 1 and advance the packet to the next table\[char46] If there are any stateful ACLs on this datapath, then \fBallow\fR ACLs set the allow bit to one and in addition perform \fBct_commit;\fR (which acts as a hint for future tables to commit the connection to conntrack)\[char46] In case the \fBACL\fR has a label then \fBreg3\fR is loaded with the label value and \fBreg0[13]\fR bit is set to 1 (which acts as a hint for the next tables to commit the label to conntrack)\[char46]
.IP \(bu
-\fBreject\fR ACLs translate into logical flows with the \fBtcp_reset { output <\-> inport;
-next(pipeline=egress,table=5);}\fR action for TCP connections,\fBicmp4/icmp6\fR action for UDP connections, and \fBsctp_abort {output <\-%gt; inport;
-next(pipeline=egress,table=5);}\fR action for SCTP associations\[char46]
+\fBallow\-related\fR ACLs translate into logical flows that set the allow bit and additionally have \fBct_commit(ct_label=0/1);
+next;\fR actions for new connections and \fBreg0[1] = 1;
+next;\fR for existing connections\[char46] In case the \fBACL\fR has a label then \fBreg3\fR is loaded with the label value and \fBreg0[13]\fR bit is set to 1 (which acts as a hint for the next tables to commit the label to conntrack)\[char46]
+.IP \(bu
+\fBallow\-stateless\fR ACLs translate into logical flows that set the allow bit and advance to the next table\[char46]
+.IP \(bu
+\fBreject\fR ACLs translate into logical flows with that set the reject bit and advance to the next table\[char46]
.IP \(bu
-Other ACLs translate to \fBdrop;\fR for new or untracked connections and \fBct_commit(ct_label=1/1);\fR for known connections\[char46] Setting \fBct_label\fR marks a connection as one that was previously allowed, but should no longer be allowed due to a policy change\[char46]
+\fBpass\fR ACLs translate into logical flows that do not set the allow, drop, or reject bit and advance to the next table\[char46]
+.IP \(bu
+Other ACLs set the drop bit and advance to the next table for new or untracked connections\[char46] For known connections, they set the drop bit, as well as running the \fBct_commit(ct_label=1/1);\fR action\[char46] Setting \fBct_label\fR marks a connection as one that was previously allowed, but should no longer be allowed due to a policy change\[char46]
.RE
.PP
.PP
-This table contains a priority\-65535 flow to advance to the next table if the logical switch has \fBno\fR ACLs configured, otherwise a priority\-0 flow to advance to the next table so that ACLs allow packets by default if \fBoptions:default_acl_drop\fR column of \fBNB_Global\fR is \fBfalse\fR or not set\[char46] Otherwise the flow action is set to \fBdrop;\fR to implement a default drop behavior\[char46]
+This table contains a priority\-65535 flow to set the allow bit and advance to the next table if the logical switch has \fBno\fR ACLs configured, otherwise a priority\-0 flow to advance to the next table is added\[char46] This flow does not set the allow bit, so that the next table can decide whether to allow or drop the packet based on the value of the \fBoptions:default_acl_drop\fR column of the \fBNB_Global\fR table\[char46]
+.PP
+.PP
+A priority\-65532 flow is added that sets the allow bit for IPv6 Neighbor solicitation, Neighbor discover, Router solicitation, Router advertisement and MLD packets regardless of other ACLs defined\[char46]
.PP
.PP
If the logical datapath has a stateful ACL or a load balancer with VIP configured, the following flows will also be added:
@@ -450,28 +454,43 @@ If the logical datapath has a stateful ACL or a load balancer with VIP configure
.IP \(bu
If \fBoptions:default_acl_drop\fR column of \fBNB_Global\fR is \fBfalse\fR or not set, a priority\-1 flow that sets the hint to commit IP traffic that is not part of established sessions to the connection tracker (with action \fBreg0[1] = 1; next;\fR)\[char46] This is needed for the default allow policy because, while the initiator\(cqs direction may not have any stateful rules, the server\(cqs may and then its return traffic would not be known and marked as invalid\[char46]
.IP \(bu
-If \fBoptions:default_acl_drop\fR column of \fBNB_Global\fR is \fBtrue\fR, a priority\-1 flow that drops IP traffic that is not part of established sessions\[char46]
+A priority\-1 flow that sets the allow bit and sets the hint to commit IP traffic to the connection tracker (with action \fBreg0[1] = 1;
+next;\fR)\[char46] This is needed for the default allow policy because, while the initiator\(cqs direction may not have any stateful rules, the server\(cqs may and then its return traffic would not be known and marked as invalid\[char46]
.IP \(bu
-A priority\-1 flow that sets the hint to commit IP traffic to the connection tracker (with action \fBreg0[1] = 1; next;\fR)\[char46] This is needed for the default allow policy because, while the initiator\(cqs direction may not have any stateful rules, the server\(cqs may and then its return traffic would not be known and marked as invalid\[char46]
+A priority\-65532 flow that sets the allow bit for any traffic in the reply direction for a connection that has been committed to the connection tracker (i\[char46]e\[char46], established flows), as long as the committed flow does not have \fBct_mark\[char46]blocked\fR set\[char46] We only handle traffic in the reply direction here because we want all packets going in the request direction to still go through the flows that implement the currently defined policy based on ACLs\[char46] If a connection is no longer allowed by policy, \fBct_mark\[char46]blocked\fR will get set and packets in the reply direction will no longer be allowed, either\[char46] This flow also clears the register bits \fBreg0[9]\fR and \fBreg0[10]\fR and sets register bit \fBreg0[17]\fR\[char46] If ACL logging and logging of related packets is enabled, then a companion priority\-65533 flow will be installed that accomplishes the same thing but also logs the traffic\[char46]
.IP \(bu
-A priority\-65532 flow that allows any traffic in the reply direction for a connection that has been committed to the connection tracker (i\[char46]e\[char46], established flows), as long as the committed flow does not have \fBct_mark\[char46]blocked\fR set\[char46] We only handle traffic in the reply direction here because we want all packets going in the request direction to still go through the flows that implement the currently defined policy based on ACLs\[char46] If a connection is no longer allowed by policy, \fBct_mark\[char46]blocked\fR will get set and packets in the reply direction will no longer be allowed, either\[char46] This flow also clears the register bits \fBreg0[9]\fR and \fBreg0[10]\fR\[char46] If ACL logging and logging of related packets is enabled, then a companion priority\-65533 flow will be installed that accomplishes the same thing but also logs the traffic\[char46]
+A priority\-65532 flow that sets the allow bit for any traffic that is considered related to a committed flow in the connection tracker (e\[char46]g\[char46], an ICMP Port Unreachable from a non-listening UDP port), as long as the committed flow does not have \fBct_mark\[char46]blocked\fR set\[char46] This flow also applies NAT to the related traffic so that ICMP headers and the inner packet have correct addresses\[char46] If ACL logging and logging of related packets is enabled, then a companion priority\-65533 flow will be installed that accomplishes the same thing but also logs the traffic\[char46]
.IP \(bu
-A priority\-65532 flow that allows any traffic that is considered related to a committed flow in the connection tracker (e\[char46]g\[char46], an ICMP Port Unreachable from a non-listening UDP port), as long as the committed flow does not have \fBct_mark\[char46]blocked\fR set\[char46] This flow also applies NAT to the related traffic so that ICMP headers and the inner packet have correct addresses\[char46] If ACL logging and logging of related packets is enabled, then a companion priority\-65533 flow will be installed that accomplishes the same thing but also logs the traffic\[char46]
+A priority\-65532 flow that sets the drop bit for all traffic marked by the connection tracker as invalid\[char46]
.IP \(bu
-A priority\-65532 flow that drops all traffic marked by the connection tracker as invalid\[char46]
-.IP \(bu
-A priority\-65532 flow that drops all traffic in the reply direction with \fBct_mark\[char46]blocked\fR set meaning that the connection should no longer be allowed due to a policy change\[char46] Packets in the request direction are skipped here to let a newly created ACL re-allow this connection\[char46]
-.IP \(bu
-A priority\-65532 flow that allows IPv6 Neighbor solicitation, Neighbor discover, Router solicitation, Router advertisement and MLD packets\[char46]
+A priority\-65532 flow that sets the drop bit for all traffic in the reply direction with \fBct_mark\[char46]blocked\fR set meaning that the connection should no longer be allowed due to a policy change\[char46] Packets in the request direction are skipped here to let a newly created ACL re-allow this connection\[char46]
.RE
.PP
.PP
If the logical datapath has any ACL or a load balancer with VIP configured, the following flow will also be added:
.RS
.IP \(bu
-A priority 34000 logical flow is added for each logical switch datapath with the match \fBeth\[char46]dst = \fIE\fB\fR to allow the service monitor reply packet destined to \fBovn\-controller\fR with the action \fBnext\fR, where \fIE\fR is the service monitor mac defined in the \fBoptions:svc_monitor_mac\fR column of \fBNB_Global\fR table\[char46]
+A priority 34000 logical flow is added for each logical switch datapath with the match \fBeth\[char46]dst = \fIE\fB\fR to allow the service monitor reply packet destined to \fBovn\-controller\fR that sets the allow bit, where \fIE\fR is the service monitor mac defined in the \fBoptions:svc_monitor_mac\fR column of \fBNB_Global\fR table\[char46]
+.RE
+.ST "Ingress Table 9: \fBfrom\-lport\fI ACL action"
+.PP
+.PP
+Logical flows in this table decide how to proceed based on the values of the allow, drop, and reject bits that may have been set in the previous table\[char46]
+.RS
+.IP \(bu
+If no ACLs are configured, then a priority 0 flow is installed that matches everything and advances to the next table\[char46]
+.IP \(bu
+A priority 1000 flow is installed that will advance the packet to the next table if the allow bit is set\[char46]
+.IP \(bu
+A priority 1000 flow is installed that will run the \fBdrop;\fR action if the drop bit is set\[char46]
+.IP \(bu
+A priority 1000 flow is installed that will run the \fBtcp_reset
+{ output <\-> inport; next(pipeline=egress,table=5);}\fR action for TCP connections,\fBicmp4/icmp6\fR action for UDP connections, and \fBsctp_abort {output <\-%gt; inport;
+next(pipeline=egress,table=5);}\fR action for SCTP associations\[char46]
+.IP \(bu
+If any ACLs have tiers configured on them, then three priority 500 flows are installed\[char46] If the current tier counter is 0, 1, or 2, then the current tier counter is incremented by one and the packet is sent back to the previous table for re-evaluation\[char46]
.RE
-.ST "Ingress Table 9: \fBfrom\-lport\fI QoS Marking"
+.ST "Ingress Table 10: \fBfrom\-lport\fI QoS Marking"
.PP
.PP
Logical flows in this table closely reproduce those in the \fBQoS\fR table with the \fBaction\fR column set in the \fBOVN_Northbound\fR database for the \fBfrom\-lport\fR direction\[char46]
@@ -479,9 +498,11 @@ Logical flows in this table closely reproduce those in the \fBQoS\fR table with
.IP \(bu
For every qos_rules entry in a logical switch with DSCP marking enabled, a flow will be added at the priority mentioned in the QoS table\[char46]
.IP \(bu
+For every qos_rules entry in a logical switch with packet marking enabled, a flow will be added at the priority mentioned in the QoS table\[char46]
+.IP \(bu
One priority\-0 fallback flow that matches all packets and advances to the next table\[char46]
.RE
-.ST "Ingress Table 10: \fBfrom\-lport\fI QoS Meter"
+.ST "Ingress Table 11: \fBfrom\-lport\fI QoS Meter"
.PP
.PP
Logical flows in this table closely reproduce those in the \fBQoS\fR table with the \fBbandwidth\fR column set in the \fBOVN_Northbound\fR database for the \fBfrom\-lport\fR direction\[char46]
@@ -491,7 +512,7 @@ For every qos_rules entry in a logical switch with metering enabled, a flow will
.IP \(bu
One priority\-0 fallback flow that matches all packets and advances to the next table\[char46]
.RE
-.ST "Ingress Table 11: Load balancing affinity check"
+.ST "Ingress Table 12: Load balancing affinity check"
.PP
.PP
Load balancing affinity check table contains the following logical flows:
@@ -504,7 +525,7 @@ ip6\[char46]dst == \fIVIP\fB&& \fIP\fB &&
.IP \(bu
A priority 0 flow is added which matches on all packets and applies the action \fBnext;\fR\[char46]
.RE
-.ST "Ingress Table 12: LB"
+.ST "Ingress Table 13: LB"
.RS
.IP \(bu
For all the configured load balancing rules for a switch in \fBOVN_Northbound\fR database where a positive affinity timeout is specified in \fBoptions\fR column, that includes a L4 port \fIPORT\fR of protocol \fIP\fR and IP address \fIVIP\fR, a priority\-150 flow is added\[char46] For IPv4 \fIVIPs\fR, the flow matches \fBreg9[6] == 1 && ct\[char46]new && ip &&
@@ -528,7 +549,7 @@ ct_lb_mark(\fIargs\fB)\fR, where \fIargs\fR contains comma separated IP addresse
.IP \(bu
If the load balancer is created with \fB\-\-reject\fR option and it has no active backends, a TCP reset segment (for tcp) or an ICMP port unreachable packet (for all other kind of traffic) will be sent whenever an incoming packet is received for this load-balancer\[char46] Please note using \fB\-\-reject\fR option will disable empty_lb SB controller event for this load balancer\[char46]
.RE
-.ST "Ingress Table 13: Load balancing affinity learn"
+.ST "Ingress Table 14: Load balancing affinity learn"
.PP
.PP
Load balancing affinity learn table contains the following logical flows:
@@ -545,72 +566,106 @@ For all the configured load balancing rules for a switch in \fBOVN_Northbound\fR
.IP \(bu
A priority 0 flow is added which matches on all packets and applies the action \fBnext;\fR\[char46]
.RE
-.ST "Ingress table 14: \fBfrom\-lport\fI ACLs after LB"
-.PP
-.PP
-Logical flows in this table closely reproduce those in the \fBACL\fR table in the \fBOVN_Northbound\fR database for the \fBfrom\-lport\fR direction with the option \fBapply\-after\-lb\fR set to \fBtrue\fR\[char46] The \fBpriority\fR values from the \fBACL\fR table have a limited range and have 1000 added to them to leave room for OVN default flows at both higher and lower priorities\[char46]
+.ST "Ingress Table 15: Pre-Hairpin"
.RS
.IP \(bu
-\fBallow\fR apply-after-lb ACLs translate into logical flows with the \fBnext;\fR action\[char46] If there are any stateful ACLs (including both before-lb and after-lb ACLs) on this datapath, then \fBallow\fR ACLs translate to \fBct_commit; next;\fR (which acts as a hint for the next tables to commit the connection to conntrack)\[char46] In case the \fBACL\fR has a label then \fBreg3\fR is loaded with the label value and \fBreg0[13]\fR bit is set to 1 (which acts as a hint for the next tables to commit the label to conntrack)\[char46]
+If the logical switch has load balancer(s) configured, then a priority\-100 flow is added with the match \fBip && ct\[char46]trk\fR to check if the packet needs to be hairpinned (if after load balancing the destination IP matches the source IP) or not by executing the actions \fBreg0[6] = chk_lb_hairpin();\fR and \fBreg0[12] = chk_lb_hairpin_reply();\fR and advances the packet to the next table\[char46]
+.IP \(bu
+A priority\-0 flow that simply moves traffic to the next table\[char46]
+.RE
+.ST "Ingress Table 16: Nat-Hairpin"
+.RS
.IP \(bu
-\fBallow\-related\fR apply-after-lb ACLs translate into logical flows with the \fBct_commit(ct_label=0/1); next;\fR actions for new connections and \fBreg0[1] = 1; next;\fR for existing connections\[char46] In case the \fBACL\fR has a label then \fBreg3\fR is loaded with the label value and \fBreg0[13]\fR bit is set to 1 (which acts as a hint for the next tables to commit the label to conntrack)\[char46]
+If the logical switch has load balancer(s) configured, then a priority\-100 flow is added with the match \fBip && ct\[char46]new && ct\[char46]trk &&
+reg0[6] == 1\fR which hairpins the traffic by NATting source IP to the load balancer VIP by executing the action \fBct_snat_to_vip\fR and advances the packet to the next table\[char46]
.IP \(bu
-\fBallow\-stateless\fR apply-after-lb ACLs translate into logical flows with the \fBnext;\fR action\[char46]
+If the logical switch has load balancer(s) configured, then a priority\-100 flow is added with the match \fBip && ct\[char46]est && ct\[char46]trk &&
+reg0[6] == 1\fR which hairpins the traffic by NATting source IP to the load balancer VIP by executing the action \fBct_snat\fR and advances the packet to the next table\[char46]
.IP \(bu
-\fBreject\fR apply-after-lb ACLs translate into logical flows with the \fBtcp_reset { output <\-> inport;
-next(pipeline=egress,table=5);}\fR action for TCP connections,\fBicmp4/icmp6\fR action for UDP connections, and \fBsctp_abort {output <\-%gt; inport;
-next(pipeline=egress,table=5);}\fR action for SCTP associations\[char46]
+If the logical switch has load balancer(s) configured, then a priority\-90 flow is added with the match \fBip && reg0[12] == 1\fR which matches on the replies of hairpinned traffic (i\[char46]e\[char46], destination IP is VIP, source IP is the backend IP and source L4 port is backend port for L4 load balancers) and executes \fBct_snat\fR and advances the packet to the next table\[char46]
.IP \(bu
-Other apply-after-lb ACLs translate to \fBdrop;\fR for new or untracked connections and \fBct_commit(ct_label=1/1);\fR for known connections\[char46] Setting \fBct_label\fR marks a connection as one that was previously allowed, but should no longer be allowed due to a policy change\[char46]
+A priority\-0 flow that simply moves traffic to the next table\[char46]
.RE
+.ST "Ingress Table 17: Hairpin"
.RS
.IP \(bu
-One priority\-0 fallback flow that matches all packets and advances to the next table\[char46]
+If logical switch has attached logical switch port of \fIvtep\fR type, then for each distributed gateway router port \fIRP\fR attached to this logical switch and has chassis redirect port \fIcr-RP\fR, a priority\-2000 flow is added with the match .IP
+.nf
+\fB
+.br
+\fB\fR\fBreg0[14] == 1 && is_chassis_resident(\fIcr-RP\fB)\fB\fR
+.br
+\fB \fR
+.fi
+and action \fBnext;\fR\[char46]
+.IP
+\fBreg0[14]\fR register bit is set in the ingress L2 port security check table for traffic received from HW VTEP (ramp) ports\[char46]
+.IP \(bu
+If logical switch has attached logical switch port of \fIvtep\fR type, then a priority\-1000 flow that matches on \fBreg0[14]\fR register bit for the traffic received from HW VTEP (ramp) ports\[char46] This traffic is passed to ingress table ls_in_l2_lkup\[char46]
+.IP \(bu
+A priority\-1 flow that hairpins traffic matched by non-default flows in the Pre-Hairpin table\[char46] Hairpinning is done at L2, Ethernet addresses are swapped and the packets are looped back on the input port\[char46]
+.IP \(bu
+A priority\-0 flow that simply moves traffic to the next table\[char46]
.RE
-.ST "Ingress Table 15: Stateful"
+.ST "Ingress table 18: \fBfrom\-lport\fI ACL evaluation after LB"
+.PP
+.PP
+Logical flows in this table closely reproduce those in the \fBACL eval\fR table in the \fBOVN_Northbound\fR database for the \fBfrom\-lport\fR direction with the option \fBapply\-after\-lb\fR set to \fBtrue\fR\[char46] The \fBpriority\fR values from the \fBACL\fR table have a limited range and have 1000 added to them to leave room for OVN default flows at both higher and lower priorities\[char46] The flows in this table indicate the ACL verdict by setting \fBreg8[16]\fR for \fBallow\-type\fR ACLs, \fBreg8[17]\fR for \fBdrop\fR ACLs, and \fBreg8[17]\fR for \fBreject\fR ACLs, and then advancing the packet to the next table\[char46] These will be reffered to as the allow bit, drop bit, and reject bit throughout the documentation for this table and the next one\[char46]
+.PP
+.PP
+Like with ACLs that are evaluated before load balancers, if the ACL is configured with a tier value, then the current tier counter, supplied in reg8[30\[char46]\[char46]31] is matched against the ACL\(cqs configured tier in addition to the ACL\(cqs match\[char46]
.RS
.IP \(bu
-A priority 100 flow is added which commits the packet to the conntrack and sets the most significant 32-bits of \fBct_label\fR with the \fBreg3\fR value based on the hint provided by previous tables (with a match for \fBreg0[1] == 1 && reg0[13] == 1\fR)\[char46] This is used by the \fBACLs\fR with label to commit the label value to conntrack\[char46]
+\fBallow\fR apply-after-lb ACLs translate into logical flows that set the allow bit\[char46] If there are any stateful ACLs (including both before-lb and after-lb ACLs) on this datapath, then \fBallow\fR ACLs also run \fBct_commit; next;\fR (which acts as a hint for an upcoming table to commit the connection to conntrack)\[char46] In case the \fBACL\fR has a label then \fBreg3\fR is loaded with the label value and \fBreg0[13]\fR bit is set to 1 (which acts as a hint for the next tables to commit the label to conntrack)\[char46]
.IP \(bu
-For \fBACLs\fR without label, a second priority\-100 flow commits packets to connection tracker using \fBct_commit; next;\fR action based on a hint provided by the previous tables (with a match for \fBreg0[1] == 1 && reg0[13] == 0\fR)\[char46]
+\fBallow\-related\fR apply-after-lb ACLs translate into logical flows that set the allow bit and run the \fBct_commit(ct_label=0/1);
+next;\fR actions for new connections and \fBreg0[1] = 1;
+next;\fR for existing connections\[char46] In case the \fBACL\fR has a label then \fBreg3\fR is loaded with the label value and \fBreg0[13]\fR bit is set to 1 (which acts as a hint for the next tables to commit the label to conntrack)\[char46]
.IP \(bu
-A priority\-0 flow that simply moves traffic to the next table\[char46]
+\fBallow\-stateless\fR apply-after-lb ACLs translate into logical flows that set the allow bit and advance to the next table\[char46]
+.IP \(bu
+\fBreject\fR apply-after-lb ACLs translate into logical flows that set the reject bit and advance to the next table\[char46]
+.IP \(bu
+\fBpass\fR apply-after-lb ACLs translate into logical flows that do not set the allow, drop, or reject bit and advance to the next table\[char46]
+.IP \(bu
+Other apply-after-lb ACLs set the drop bit for new or untracked connections and \fBct_commit(ct_label=1/1);\fR for known connections\[char46] Setting \fBct_label\fR marks a connection as one that was previously allowed, but should no longer be allowed due to a policy change\[char46]
.RE
-.ST "Ingress Table 16: Pre-Hairpin"
.RS
.IP \(bu
-If the logical switch has load balancer(s) configured, then a priority\-100 flow is added with the match \fBip && ct\[char46]trk\fR to check if the packet needs to be hairpinned (if after load balancing the destination IP matches the source IP) or not by executing the actions \fBreg0[6] = chk_lb_hairpin();\fR and \fBreg0[12] = chk_lb_hairpin_reply();\fR and advances the packet to the next table\[char46]
+One priority\-65532 flow matching packets with \fBreg0[17]\fR set (either replies to existing sessions or traffic related to existing sessions) and allows these by setting the allow bit and advancing to the next table\[char46]
+.RE
+.RS
.IP \(bu
-A priority\-0 flow that simply moves traffic to the next table\[char46]
+One priority\-0 fallback flow that matches all packets and advances to the next table\[char46]
.RE
-.ST "Ingress Table 17: Nat-Hairpin"
+.ST "Ingress Table 19: \fBfrom\-lport\fI ACL action after LB"
+.PP
+.PP
+Logical flows in this table decide how to proceed based on the values of the allow, drop, and reject bits that may have been set in the previous table\[char46]
.RS
.IP \(bu
-If the logical switch has load balancer(s) configured, then a priority\-100 flow is added with the match \fBip && ct\[char46]new && ct\[char46]trk &&
-reg0[6] == 1\fR which hairpins the traffic by NATting source IP to the load balancer VIP by executing the action \fBct_snat_to_vip\fR and advances the packet to the next table\[char46]
+If no ACLs are configured, then a priority 0 flow is installed that matches everything and advances to the next table\[char46]
.IP \(bu
-If the logical switch has load balancer(s) configured, then a priority\-100 flow is added with the match \fBip && ct\[char46]est && ct\[char46]trk &&
-reg0[6] == 1\fR which hairpins the traffic by NATting source IP to the load balancer VIP by executing the action \fBct_snat\fR and advances the packet to the next table\[char46]
+A priority 1000 flow is installed that will advance the packet to the next table if the allow bit is set\[char46]
.IP \(bu
-If the logical switch has load balancer(s) configured, then a priority\-90 flow is added with the match \fBip && reg0[12] == 1\fR which matches on the replies of hairpinned traffic (i\[char46]e\[char46], destination IP is VIP, source IP is the backend IP and source L4 port is backend port for L4 load balancers) and executes \fBct_snat\fR and advances the packet to the next table\[char46]
+A priority 1000 flow is installed that will run the \fBdrop;\fR action if the drop bit is set\[char46]
.IP \(bu
-A priority\-0 flow that simply moves traffic to the next table\[char46]
+A priority 1000 flow is installed that will run the \fBtcp_reset
+{ output <\-> inport; next(pipeline=egress,table=5);}\fR action for TCP connections,\fBicmp4/icmp6\fR action for UDP connections, and \fBsctp_abort {output <\-%gt; inport;
+next(pipeline=egress,table=5);}\fR action for SCTP associations\[char46]
+.IP \(bu
+If any ACLs have tiers configured on them, then three priority 500 flows are installed\[char46] If the current tier counter is 0, 1, or 2, then the current tier counter is incremented by one and the packet is sent back to the previous table for re-evaluation\[char46]
.RE
-.ST "Ingress Table 18: Hairpin"
+.ST "Ingress Table 20: Stateful"
.RS
.IP \(bu
-For each distributed gateway router port \fIRP\fR attached to the logical switch, a priority\-2000 flow is added with the match \fBreg0[14] == 1 && is_chassis_resident(\fIRP\fB)
-\fR and action \fBnext;\fR to pass the traffic to the next table to respond to the ARP requests for the router port IPs\[char46]
-.IP
-\fBreg0[14]\fR register bit is set in the ingress L2 port security check table for traffic received from HW VTEP (ramp) ports\[char46]
-.IP \(bu
-A priority\-1000 flow that matches on \fBreg0[14]\fR register bit for the traffic received from HW VTEP (ramp) ports\[char46] This traffic is passed to ingress table ls_in_l2_lkup\[char46]
+A priority 100 flow is added which commits the packet to the conntrack and sets the most significant 32-bits of \fBct_label\fR with the \fBreg3\fR value based on the hint provided by previous tables (with a match for \fBreg0[1] == 1 && reg0[13] == 1\fR)\[char46] This is used by the \fBACLs\fR with label to commit the label value to conntrack\[char46]
.IP \(bu
-A priority\-1 flow that hairpins traffic matched by non-default flows in the Pre-Hairpin table\[char46] Hairpinning is done at L2, Ethernet addresses are swapped and the packets are looped back on the input port\[char46]
+For \fBACLs\fR without label, a second priority\-100 flow commits packets to connection tracker using \fBct_commit; next;\fR action based on a hint provided by the previous tables (with a match for \fBreg0[1] == 1 && reg0[13] == 0\fR)\[char46]
.IP \(bu
A priority\-0 flow that simply moves traffic to the next table\[char46]
.RE
-.ST "Ingress Table 19: ARP/ND responder"
+.ST "Ingress Table 21: ARP/ND responder"
.PP
.PP
This table implements ARP/ND responder in a logical switch for known IPs\[char46] The advantage of the ARP responder flow is to limit ARP broadcasts by locally responding to ARP requests without the need to send to other hypervisors\[char46] One common case is when the inport is a logical port associated with a VIF and the broadcast is responded to on the local hypervisor rather than broadcast across the whole network and responded to by the destination VM\[char46] This behavior is proxy ARP\[char46]
@@ -625,7 +680,9 @@ Logical switch ARP responder proxy ARP rules can also be hit when receiving ARP
Note that ARP requests received from \fBlocalnet\fR logical inports can either go directly to VMs, in which case the VM responds or can hit an ARP responder for a logical router port if the packet is used to resolve a logical router port next hop address\[char46] In either case, logical switch ARP responder rules will not be hit\[char46] It contains these logical flows:
.RS
.IP \(bu
-Priority\-100 flows to skip the ARP responder if inport is of type \fBlocalnet\fR advances directly to the next table\[char46] ARP requests sent to \fBlocalnet\fR ports can be received by multiple hypervisors\[char46] Now, because the same mac binding rules are downloaded to all hypervisors, each of the multiple hypervisors will respond\[char46] This will confuse L2 learning on the source of the ARP requests\[char46] ARP requests received on an inport of type \fBrouter\fR are not expected to hit any logical switch ARP responder flows\[char46] However, no skip flows are installed for these packets, as there would be some additional flow cost for this and the value appears limited\[char46]
+If packet was received from HW VTEP (ramp switch), and this packet is ARP or Neighbor Solicitation, such packet is passed to next table with max proirity\[char46] ARP/ND requests from HW VTEP must be handled in logical router ingress pipeline\[char46]
+.IP \(bu
+If the logical switch has no router ports with options:arp_proxy configured add a priority\-100 flows to skip the ARP responder if inport is of type \fBlocalnet\fR advances directly to the next table\[char46] ARP requests sent to \fBlocalnet\fR ports can be received by multiple hypervisors\[char46] Now, because the same mac binding rules are downloaded to all hypervisors, each of the multiple hypervisors will respond\[char46] This will confuse L2 learning on the source of the ARP requests\[char46] ARP requests received on an inport of type \fBrouter\fR are not expected to hit any logical switch ARP responder flows\[char46] However, no skip flows are installed for these packets, as there would be some additional flow cost for this and the value appears limited\[char46]
.IP \(bu
If inport \fBV\fR is of type \fBvirtual\fR adds a priority\-100 logical flows for each \fIP\fR configured in the \fBoptions:virtual-parents\fR column with the match
.IP
@@ -740,6 +797,8 @@ Priority\-50 flows that match IPv6 ND neighbor solicitations to each known IP ad
.IP
These flows are omitted for logical ports (other than router ports or \fBlocalport\fR ports) that are down (unless \fB
ignore_lsp_down\fR is configured as true in \fBoptions\fR column of \fBNB_Global\fR table of the \fBNorthbound\fR database), for logical ports of type \fBvirtual\fR and for logical ports with \(cqunknown\(cq address set\[char46]
+.IP
+The above NDP responder flows are added for the list of IPv6 addresses if defined in \fBoptions:arp_proxy\fR column of \fBLogical_Switch_Port\fR table for logical switch ports of type \fBrouter\fR\[char46]
.IP \(bu
Priority\-100 flows with match criteria like the ARP and ND flows above, except that they only match packets from the \fBinport\fR that owns the IP addresses in question, with action \fBnext;\fR\[char46] These flows prevent OVN from replying to, for example, an ARP request emitted by a VM for its own IP address\[char46] A VM only makes this kind of request to attempt to detect a duplicate IP address assignment, so sending a reply will prevent the VM from accepting the IP address that it owns\[char46]
.IP
@@ -779,6 +838,34 @@ where \fIE\fR is the service monitor source mac defined in the \fBoptions:svc_mo
\fISVC_MON_SRC_IP\fR is used as the source ip in the service monitor IPv4 packets for the load balancer endpoint IP health checks\[char46]
.IP
These flows are required if an ARP request is sent for the IP \fISVC_MON_SRC_IP\fR\[char46]
+.IP
+For IPv6 the similar flow is added with the following action
+.IP
+.nf
+\fB
+.br
+\fBnd_na {
+.br
+\fB eth\[char46]dst = eth\[char46]src;
+.br
+\fB eth\[char46]src = \fR\fIE\fB\fR;
+.br
+\fB ip6\[char46]src = \fR\fIA\fB\fR;
+.br
+\fB nd\[char46]target = \fR\fIA\fB\fR;
+.br
+\fB nd\[char46]tll = \fR\fIE\fB\fR;
+.br
+\fB outport = inport;
+.br
+\fB flags\[char46]loopback = 1;
+.br
+\fB output;
+.br
+\fB};
+.br
+\fB \fR
+.fi
.IP \(bu
For each \fIVIP\fR configured in the table \fBForwarding_Group\fR a priority\-50 logical flow is added with the match \fBarp\[char46]tpa == \fIvip\fB && && arp\[char46]op == 1
\fR and applies the action
@@ -817,7 +904,7 @@ These flows are required to respond to an ARP request if an ARP request is sent
.IP \(bu
One priority\-0 fallback flow that matches all packets and advances to the next table\[char46]
.RE
-.ST "Ingress Table 20: DHCP option processing"
+.ST "Ingress Table 22: DHCP option processing"
.PP
.PP
This table adds the DHCPv4 options to a DHCPv4 packet from the logical ports configured with IPv4 address(es) and DHCPv4 options, and similarly for DHCPv6 options\[char46] This table also adds flows for the logical ports of type \fBexternal\fR\[char46]
@@ -853,7 +940,7 @@ For DHCPv6 Solicit/Request/Confirm packets, this transforms the packet into a DH
.IP \(bu
A priority\-0 flow that matches all packets to advances to table 16\[char46]
.RE
-.ST "Ingress Table 21: DHCP responses"
+.ST "Ingress Table 23: DHCP responses"
.PP
.PP
This table implements DHCP responder for the DHCP replies generated by the previous table\[char46]
@@ -921,7 +1008,7 @@ where \fIE\fR is the server MAC address and \fIS\fR is the server IPv6 LLA addre
.IP \(bu
A priority\-0 flow that matches all packets to advances to table 17\[char46]
.RE
-.ST "Ingress Table 22 DNS Lookup"
+.ST "Ingress Table 24 DNS Lookup"
.PP
.PP
This table looks up and resolves the DNS names to the corresponding configured IP address(es)\[char46]
@@ -939,7 +1026,7 @@ A priority\-100 logical flow for each logical switch datapath if it is configure
.IP
For valid DNS packets, this transforms the packet into a DNS reply if the DNS name can be resolved, and stores 1 into reg0[4]\[char46] For failed DNS resolution or other kinds of packets, it just stores 0 into reg0[4]\[char46] Either way, it continues to the next table\[char46]
.RE
-.ST "Ingress Table 23 DNS Responses"
+.ST "Ingress Table 25 DNS Responses"
.PP
.PP
This table implements DNS responder for the DNS replies generated by the previous table\[char46]
@@ -969,7 +1056,7 @@ A priority\-100 logical flow for each logical switch datapath if it is configure
.IP
(This terminates ingress packet processing; the packet does not go to the next ingress table\[char46])
.RE
-.ST "Ingress table 24 External ports"
+.ST "Ingress table 26 External ports"
.PP
.PP
Traffic from the \fBexternal\fR logical ports enter the ingress datapath pipeline via the \fBlocalnet\fR port\[char46] This table adds the below logical flows to handle the traffic from these ports\[char46]
@@ -985,7 +1072,7 @@ eth\[char46]src == \fIE\fB && eth\[char46]dst == \fIR\fB
.IP \(bu
A priority\-0 flow that matches all packets to advances to table 20\[char46]
.RE
-.ST "Ingress Table 25 Destination Lookup"
+.ST "Ingress Table 27 Destination Lookup"
.PP
.PP
This table implements switching behavior\[char46] It contains these logical flows:
@@ -1009,6 +1096,8 @@ Priority\-80 flows for each IP address/VIP/NAT address owned by a router port co
.IP \(bu
Priority\-75 flows for each port connected to a logical router matching self originated ARP request/RARP request/ND packets\[char46] These packets are flooded to the \fBMC_FLOOD_L2\fR which contains all non-router logical ports\[char46]
.IP \(bu
+A priority\-72 flow that outputs all ARP requests and ND packets with an Ethernet broadcast or multicast \fBeth\[char46]dst\fR to the \fBMC_FLOOD_L2\fR multicast group if \fBother_config:broadcast\-arps\-to\-all\-routers=true\fR\[char46]
+.IP \(bu
A priority\-70 flow that outputs all packets with an Ethernet broadcast or multicast \fBeth\[char46]dst\fR to the \fBMC_FLOOD\fR multicast group\[char46]
.IP \(bu
One priority\-50 flow that matches each known Ethernet address against \fBeth\[char46]dst\fR\[char46] Action of this flow outputs the packet to the single associated output port if it is enabled\[char46] \fBdrop;\fR action is applied if LSP is disabled\[char46]
@@ -1033,7 +1122,7 @@ For each forwarding group configured on the logical switch datapath, a priority\
.IP \(bu
One priority\-0 fallback flow that matches all packets with the action \fBoutport = get_fdb(eth\[char46]dst); next;\fR\[char46] The action \fBget_fdb\fR gets the port for the \fBeth\[char46]dst\fR in the MAC learning table of the logical switch datapath\[char46] If there is no entry for \fBeth\[char46]dst\fR in the MAC learning table, then it stores \fBnone\fR in the \fBoutport\fR\[char46]
.RE
-.ST "Ingress Table 26 Destination unknown"
+.ST "Ingress Table 28 Destination unknown"
.PP
.PP
This table handles the packets whose destination was not found or and looked up in the MAC learning table of the logical switch datapath\[char46] It contains the following flows\[char46]
@@ -1072,6 +1161,9 @@ This table is similar to ingress table \fBPre\-LB\fR\[char46] It contains a prio
.PP
.PP
This table also has a priority\-110 flow with the match \fBeth\[char46]src == \fIE\fB\fR for all logical switch datapaths to move traffic to the next table\[char46] Where \fIE\fR is the service monitor mac defined in the \fBoptions:svc_monitor_mac\fR column of \fBNB_Global\fR table\[char46]
+.PP
+.PP
+This table also has a priority\-110 flow with the match \fBoutport == \fII\fB\fR for all logical switch datapaths to move traffic to the next table, and, if there are no stateful_acl, clear the ct_state\[char46] Where \fII\fR is the peer of a logical router port\[char46] This flow is added to skip the connection tracking of packets which will be entering logical router datapath from logical switch datapath for routing\[char46]
.ST "Egress Table 2: Pre-stateful"
.PP
.PP
@@ -1088,34 +1180,44 @@ A priority\-0 flow that matches all packets to advance to the next table\[char46
.PP
.PP
This is similar to ingress table \fBACL hints\fR\[char46]
-.ST "Egress Table 4: \fBto\-lport\fI ACLs"
+.ST "Egress Table 4: \fBto\-lport\fI ACL evaluation"
+.PP
.PP
+This is similar to ingress table \fBACL eval\fR except for \fBto\-lport\fR ACLs\[char46] As a reminder, these flows use the following register bits to indicate their verdicts\[char46] \fBAllow\-type\fR ACLs set \fBreg8[16]\fR, \fBdrop\fR ACLs set \fBreg8[17]\fR, and \fBreject\fR ACLs set \fBreg8[18]\fR\[char46]
.PP
-This is similar to ingress table \fBACLs\fR except for \fBto\-lport\fR ACLs\[char46]
+.PP
+Also like with ingress ACLs, egress ACLs can have a configured \fBtier\fR\[char46] If a tier is configured, then the current tier counter is evaluated against the ACL\(cqs configured tier in addition to the ACL\(cqs match\[char46] The current tier counter is stored in \fBreg8[30\[char46]\[char46]31]\fR\[char46]
+.PP
+.PP
+Similar to ingress table, a priority\-65532 flow is added to allow IPv6 Neighbor solicitation, Neighbor discover, Router solicitation, Router advertisement and MLD packets regardless of other ACLs defined\[char46]
.PP
.PP
In addition, the following flows are added\[char46]
.RS
.IP \(bu
-A priority 34000 logical flow is added for each logical port which has DHCPv4 options defined to allow the DHCPv4 reply packet and which has DHCPv6 options defined to allow the DHCPv6 reply packet from the \fBIngress Table 18: DHCP responses\fR\[char46]
+A priority 34000 logical flow is added for each logical port which has DHCPv4 options defined to allow the DHCPv4 reply packet and which has DHCPv6 options defined to allow the DHCPv6 reply packet from the \fBIngress Table 18: DHCP responses\fR\[char46] This is indicated by setting the allow bit\[char46]
.IP \(bu
-A priority 34000 logical flow is added for each logical switch datapath configured with DNS records with the match \fBudp\[char46]dst = 53\fR to allow the DNS reply packet from the \fBIngress Table 20: DNS responses\fR\[char46]
+A priority 34000 logical flow is added for each logical switch datapath configured with DNS records with the match \fBudp\[char46]dst = 53\fR to allow the DNS reply packet from the \fBIngress Table 20: DNS responses\fR\[char46] This is indicated by setting the allow bit\[char46]
.IP \(bu
-A priority 34000 logical flow is added for each logical switch datapath with the match \fBeth\[char46]src = \fIE\fB\fR to allow the service monitor request packet generated by \fBovn\-controller\fR with the action \fBnext\fR, where \fIE\fR is the service monitor mac defined in the \fBoptions:svc_monitor_mac\fR column of \fBNB_Global\fR table\[char46]
+A priority 34000 logical flow is added for each logical switch datapath with the match \fBeth\[char46]src = \fIE\fB\fR to allow the service monitor request packet generated by \fBovn\-controller\fR with the action \fBnext\fR, where \fIE\fR is the service monitor mac defined in the \fBoptions:svc_monitor_mac\fR column of \fBNB_Global\fR table\[char46] This is indicated by setting the allow bit\[char46]
.RE
-.ST "Egress Table 5: \fBto\-lport\fI QoS Marking"
+.ST "Egress Table 5: \fBto\-lport\fI ACL action"
+.PP
+.PP
+This is similar to ingress table \fBACL action\fR\[char46]
+.ST "Egress Table 6: \fBto\-lport\fI QoS Marking"
.PP
.PP
This is similar to ingress table \fBQoS marking\fR except they apply to \fBto\-lport\fR QoS rules\[char46]
-.ST "Egress Table 6: \fBto\-lport\fI QoS Meter"
+.ST "Egress Table 7: \fBto\-lport\fI QoS Meter"
.PP
.PP
This is similar to ingress table \fBQoS meter\fR except they apply to \fBto\-lport\fR QoS rules\[char46]
-.ST "Egress Table 7: Stateful"
+.ST "Egress Table 8: Stateful"
.PP
.PP
This is similar to ingress table \fBStateful\fR except that there are no rules added for load balancing new connections\[char46]
-.ST "Egress Table 8: Egress Port Security - check"
+.ST "Egress Table 9: Egress Port Security - check"
.PP
.PP
This is similar to the port security logic in table \fBIngress Port Security check\fR except that action \fBcheck_out_port_sec\fR is used to check the port security rules\[char46] This table adds the below logical flows\[char46]
@@ -1125,7 +1227,7 @@ A priority 100 flow which matches on the multicast traffic and applies the actio
.IP \(bu
A priority 0 logical flow is added which matches on all the packets and applies the action \fBREGBIT_PORT_SEC_DROP\(dq = check_out_port_sec(); next;\(dq\fR\[char46] The action \fBcheck_out_port_sec\fR applies the port security rules based on the addresses defined in the \fBport_security\fR column of \fBLogical_Switch_Port\fR table before delivering the packet to the \fBoutport\fR\[char46]
.RE
-.ST "Egress Table 9: Egress Port Security - Apply"
+.ST "Egress Table 10: Egress Port Security - Apply"
.PP
.PP
This is similar to the ingress port security logic in ingress table \fBA Ingress Port Security \- Apply\fR\[char46] This table drops the packets if the port security check failed in the previous stage i\[char46]e the register bit \fBREGBIT_PORT_SEC_DROP\fR is set to 1\[char46]
@@ -1134,6 +1236,8 @@ This is similar to the ingress port security logic in ingress table \fBA Ingress
The following flows are added\[char46]
.RS
.IP \(bu
+For each port configured with egress qos in the \fBoptions:qdisc_queue_id\fR column of \fBLogical_Switch_Port\fR, running a localnet port on the same logical switch, a priority 110 flow is added which matches on the localnet \fBoutport\fR and on the port \fBinport\fR and applies the action \fBset_queue(id); output;\(dq\fR\[char46]
+.IP \(bu
For each localnet port configured with egress qos in the \fBoptions:qdisc_queue_id\fR column of \fBLogical_Switch_Port\fR, a priority 100 flow is added which matches on the localnet \fBoutport\fR and applies the action \fBset_queue(id); output;\(dq\fR\[char46]
.IP
Please remember to mark the corresponding physical interface with \fBovn\-egress\-iface\fR set to true in \fBexternal_ids\fR\[char46]
@@ -1160,6 +1264,11 @@ For each enabled router port \fIP\fR with Ethernet address \fIE\fR, a priority\-
.IP
For the gateway port on a distributed logical router (where one of the logical router ports specifies a gateway chassis), the above flow matching \fBeth\[char46]dst == \fIE\fB\fR is only programmed on the gateway port instance on the gateway chassis\[char46] If LRP\(cqs logical switch has attached LSP of \fBvtep\fR type, the \fBis_chassis_resident()\fR part is not added to lflow to allow traffic originated from logical switch to reach LR services (LBs, NAT)\[char46]
.IP
+For each gateway port \fIGW\fR on a distributed logical router a priority\-120 flow that matches \(cqrecirculated\(cq icmp{4,6} error \(cqpacket too big\(cq and \fBeth\[char46]dst == \fID\fB &&
+!is_chassis_resident(\fI cr-GW\fB)\fR where \fID\fR is the gateway port mac address and \fIcr-GW\fR is the chassis resident port of \fIGW\fR, swap inport and outport and stores \fIGW\fR as inport\[char46]
+.IP
+This table adds a priority\-110 flow that matches \(cqrecirculated\(cq icmp{4,6} error \(cqpacket too big\(cq to drop the packet\[char46]
+.IP
For a distributed logical router or for gateway router where the port is configured with \fBoptions:gateway_mtu\fR the action of the above flow is modified adding \fBcheck_pkt_larger\fR in order to mark the packet setting \fBREGBIT_PKT_LARGER\fR if the size is greater than the MTU\[char46] If the port is also configured with \fBoptions:gateway_mtu_bypass\fR then another flow is added, with priority\-55, to bypass the \fBcheck_pkt_larger\fR flow\[char46] This is useful for traffic that normally doesn\(cqt need to be fragmented and for which check_pkt_larger, which might not be offloadable, is not really needed\[char46] One such example is TCP traffic\[char46]
.IP \(bu
For each \fBdnat_and_snat\fR NAT rule on a distributed router that specifies an external Ethernet address \fIE\fR, a priority\-50 flow that matches \fBinport == \fIGW\fB
@@ -1742,7 +1851,10 @@ The flows above handle all of the traffic that might be directed to the router i
.IP \(bu
Drop Ethernet local broadcast\[char46] A priority\-50 flow with match \fBeth\[char46]bcast\fR drops traffic destined to the local Ethernet broadcast address\[char46] By definition this traffic should not be forwarded\[char46]
.IP \(bu
-ICMP time exceeded\[char46] For each router port \fIP\fR, whose IP address is \fIA\fR, a priority\-100 flow with match \fBinport
+Avoid ICMP time exceeded for multicast\[char46] A priority\-32 flow with match \fBip\[char46]ttl == {0, 1} && !ip\[char46]later_frag &&
+(ip4\[char46]mcast || ip6\[char46]mcast)\fR and actions \fBdrop;\fR drops multicast packets whose TTL has expired without sending ICMP time exceeded\[char46]
+.IP \(bu
+ICMP time exceeded\[char46] For each router port \fIP\fR, whose IP address is \fIA\fR, a priority\-31 flow with match \fBinport
== \fIP\fB && ip\[char46]ttl == {0, 1} &&
!ip\[char46]later_frag\fR matches packets whose TTL has expired, with the following actions to send an ICMP time exceeded reply for IPv4 and IPv6 respectively:
.IP
@@ -1836,20 +1948,8 @@ If the NAT rule cannot be handled in a distributed manner, then the below priori
.IP \(bu
The first flow matches \fBip &&
ip4\[char46]dst == \fIB\fB && inport == \fIGW\fB
-&& flags\[char46]loopback == 0\fR or \fBip &&
-ip6\[char46]dst == \fIB\fB && inport == \fIGW\fB
-&& flags\[char46]loopback == 0\fR where \fIGW\fR is the distributed gateway port corresponding to the NAT rule (specified or inferred), with an action \fBct_snat_in_czone;\fR to unSNAT in the common zone\[char46] If the NAT rule is of type dnat_and_snat and has \fBstateless=true\fR in the options, then the action would be \fBnext;\fR\[char46]
-.IP
-If the NAT entry is of type \fBsnat\fR, then there is an additional match \fBis_chassis_resident(\fIcr-GW\fB)
-\fR where \fIcr-GW\fR is the chassis resident port of \fIGW\fR\[char46]
-.IP \(bu
-The second flow matches \fBip &&
-ip4\[char46]dst == \fIB\fB && inport == \fIGW\fB
-&& flags\[char46]loopback == 1 &&
-flags\[char46]use_snat_zone == 1\fR or \fBip &&
-ip6\[char46]dst == \fIB\fB && inport == \fIGW\fB
-&& flags\[char46]loopback == 0 &&
-flags\[char46]use_snat_zone == 1\fR where \fIGW\fR is the distributed gateway port corresponding to the NAT rule (specified or inferred), with an action \fBct_snat;\fR to unSNAT in the snat zone\[char46] If the NAT rule is of type dnat_and_snat and has \fBstateless=true\fR in the options, then the action would be \fBip4/6\[char46]dst=(\fIB\fB)\fR\[char46]
+\fR or \fBip && ip6\[char46]dst == \fIB\fB &&
+inport == \fIGW\fB\fR where \fIGW\fR is the distributed gateway port corresponding to the NAT rule (specified or inferred), with an action \fBct_snat;\fR to unSNAT in the common zone\[char46] If the NAT rule is of type dnat_and_snat and has \fBstateless=true\fR in the options, then the action would be \fBnext;\fR\[char46]
.IP
If the NAT entry is of type \fBsnat\fR, then there is an additional match \fBis_chassis_resident(\fIcr-GW\fB)
\fR where \fIcr-GW\fR is the chassis resident port of \fIGW\fR\[char46]
@@ -1863,17 +1963,8 @@ A priority\-0 logical flow with match \fB1\fR has actions \fBnext;\fR\[char46]
This is to send packets to connection tracker for tracking and defragmentation\[char46] It contains a priority\-0 flow that simply moves traffic to the next table\[char46]
.PP
.PP
-If load balancing rules with only virtual IP addresses are configured in \fBOVN_Northbound\fR database for a Gateway router, a priority\-100 flow is added for each configured virtual IP address \fIVIP\fR\[char46] For IPv4 \fIVIPs\fR the flow matches \fBip && ip4\[char46]dst == \fIVIP\fB\fR\[char46] For IPv6 \fIVIPs\fR, the flow matches \fBip && ip6\[char46]dst ==
-\fIVIP\fB\fR\[char46] The flow applies the action \fBreg0 =
-\fIVIP\fB; ct_dnat;\fR (or \fBxxreg0\fR for IPv6) to send IP packets to the connection tracker for packet de-fragmentation and to dnat the destination IP for the committed connection before sending it to the next table\[char46]
-.PP
-.PP
-If load balancing rules with virtual IP addresses and ports are configured in \fBOVN_Northbound\fR database for a Gateway router, a priority\-110 flow is added for each configured virtual IP address \fIVIP\fR, protocol \fIPROTO\fR and port \fIPORT\fR\[char46] For IPv4 \fIVIPs\fR the flow matches \fBip && ip4\[char46]dst == \fIVIP\fB &&
-\fIPROTO\fB && \fIPROTO\fB\[char46]dst ==
-\fIPORT\fB\fR\[char46] For IPv6 \fIVIPs\fR, the flow matches \fBip && ip6\[char46]dst == \fIVIP\fB &&
-\fIPROTO\fB && \fIPROTO\fB\[char46]dst ==
-\fIPORT\fB\fR\[char46] The flow applies the action \fBreg0 =
-\fIVIP\fB; reg9[16\[char46]\[char46]31] = \fIPROTO\fB\[char46]dst; ct_dnat;\fR (or \fBxxreg0\fR for IPv6) to send IP packets to the connection tracker for packet de-fragmentation and to dnat the destination IP for the committed connection before sending it to the next table\[char46]
+For all load balancing rules that are configured in \fBOVN_Northbound\fR database for a Gateway router, a priority\-100 flow is added for each configured virtual IP address \fIVIP\fR\[char46] For IPv4 \fIVIPs\fR the flow matches \fBip && ip4\[char46]dst == \fIVIP\fB\fR\[char46] For IPv6 \fIVIPs\fR, the flow matches \fBip && ip6\[char46]dst ==
+\fIVIP\fB\fR\[char46] The flow applies the action \fB ct_dnat;\fR to send IP packets to the connection tracker for packet de-fragmentation and to dnat the destination IP for the committed connection before sending it to the next table\[char46]
.PP
.PP
If ECMP routes with symmetric reply are configured in the \fBOVN_Northbound\fR database for a gateway router, a priority\-100 flow is added for each router port on which symmetric replies are configured\[char46] The matching logic for these ports essentially reverses the configured logic of the ECMP route\[char46] So for instance, a route with a destination routing policy will instead match if the source IP address matches the static route\(cqs prefix\[char46] The flow uses the actions \fBchk_ecmp_nh_mac(); ct_next\fR or \fBchk_ecmp_nh(); ct_next\fR to send IP packets to table \fB76\fR or to table \fB77\fR in order to check if source info are already stored by OVN and then to the connection tracker for packet de-fragmentation and tracking before sending it to the next table\[char46]
@@ -1887,10 +1978,10 @@ Load balancing affinity check table contains the following logical flows:
.RS
.IP \(bu
For all the configured load balancing rules for a logical router where a positive affinity timeout is specified in \fBoptions\fR column, that includes a L4 port \fIPORT\fR of protocol \fIP\fR and IPv4 or IPv6 address \fIVIP\fR, a priority\-100 flow that matches on \fBct\[char46]new && ip &&
-reg0 == \fIVIP\fB && \fIP\fB && reg9[16\[char46]\[char46]31]
+ip\[char46]dst == \fIVIP\fB && \fIP\fB && P\[char46]dst
== \fR \fB\fIPORT\fB\fR (\fBxxreg0 == \fIVIP
-\fB\fR in the IPv6 case) with an action of \fBreg9[6] =
-chk_lb_aff(); next;\fR
+\fB\fR in the IPv6 case) with an action of \fBreg0 = ip\[char46]dst;
+reg9[16\[char46]\[char46]31] = P\[char46]dst; reg9[6] = chk_lb_aff(); next;\fR (\fBxxreg0 == \fIip6\[char46]dst\fB \fR in the IPv6 case)
.IP \(bu
A priority 0 flow is added which matches on all packets and applies the action \fBnext;\fR\[char46]
.RE
@@ -1907,40 +1998,30 @@ Following load balancing DNAT flows are added for Gateway router or Router with
.RS
.IP \(bu
For all the configured load balancing rules for a logical router where a positive affinity timeout is specified in \fBoptions\fR column, that includes a L4 port \fIPORT\fR of protocol \fIP\fR and IPv4 or IPv6 address \fIVIP\fR, a priority\-150 flow that matches on \fBreg9[6] == 1 && ct\[char46]new &&
-ip && reg0 == \fIVIP\fB && \fIP\fB &&
-reg9[16\[char46]\[char46]31] == \fR \fB\fIPORT\fB\fR (\fBxxreg0
-== \fIVIP\fB\fR in the IPv6 case) with an action of \fBct_lb_mark(\fIargs\fB) \fR, where \fIargs\fR contains comma separated IP addresses (and optional port numbers) to load balance to\[char46] The address family of the IP addresses of \fIargs\fR is the same as the address family of \fIVIP\fR\[char46]
+ip && ip\[char46]dst == \fIVIP\fB && \fIP\fB &&
+P\[char46]dst == \fR \fB\fIPORT\fB\fR with an action of \fBct_lb_mark(\fIargs\fB) \fR, where \fIargs\fR contains comma separated IP addresses (and optional port numbers) to load balance to\[char46] The address family of the IP addresses of \fIargs\fR is the same as the address family of \fIVIP\fR\[char46]
.IP \(bu
If controller_event has been enabled for all the configured load balancing rules for a Gateway router or Router with gateway port in \fBOVN_Northbound\fR database that does not have configured backends, a priority\-130 flow is added to trigger ovn-controller events whenever the chassis receives a packet for that particular VIP\[char46] If \fBevent\-elb\fR meter has been previously created, it will be associated to the empty_lb logical flow
.IP \(bu
-For all the configured load balancing rules for a Gateway router or Router with gateway port in \fBOVN_Northbound\fR database that includes a L4 port \fIPORT\fR of protocol \fIP\fR and IPv4 or IPv6 address \fIVIP\fR, a priority\-120 flow that matches on \fBct\[char46]new && !ct\[char46]rel && ip && reg0 ==
-\fIVIP\fB && \fIP\fB && reg9[16\[char46]\[char46]31] ==
-\fR \fB\fIPORT\fB\fR (\fBxxreg0 == \fIVIP\fB
-\fR in the IPv6 case) with an action of \fBct_lb_mark(\fIargs\fB)\fR, where \fIargs\fR contains comma separated IPv4 or IPv6 addresses (and optional port numbers) to load balance to\[char46] If the router is configured to force SNAT any load-balanced packets, the above action will be replaced by \fBflags\[char46]force_snat_for_lb = 1; ct_lb_mark(\fIargs\fB);\fR\[char46] If the load balancing rule is configured with \fBskip_snat\fR set to true, the above action will be replaced by \fBflags\[char46]skip_snat_for_lb = 1; ct_lb_mark(\fIargs\fB);\fR\[char46] If health check is enabled, then \fIargs\fR will only contain those endpoints whose service monitor status entry in \fBOVN_Southbound\fR db is either \fBonline\fR or empty\[char46]
-.IP
-The previous table \fBlr_in_defrag\fR sets the register \fBreg0\fR (or \fBxxreg0\fR for IPv6) and does \fBct_dnat\fR\[char46] Hence for established traffic, this table just advances the packet to the next stage\[char46]
-.IP \(bu
-For all the configured load balancing rules for a router in \fBOVN_Northbound\fR database that includes a L4 port \fIPORT\fR of protocol \fIP\fR and IPv4 or IPv6 address \fIVIP\fR, a priority\-120 flow that matches on \fBct\[char46]est && !ct\[char46]rel && ip4 && reg0 ==
-\fIVIP\fB && \fIP\fB && reg9[16\[char46]\[char46]31] ==
-\fR \fB\fIPORT\fB\fR (\fBip6\fR and \fBxxreg0 == \fIVIP\fB\fR in the IPv6 case) with an action of \fBnext;\fR\[char46] If the router is configured to force SNAT any load-balanced packets, the above action will be replaced by \fBflags\[char46]force_snat_for_lb = 1; next;\fR\[char46] If the load balancing rule is configured with \fBskip_snat\fR set to true, the above action will be replaced by \fBflags\[char46]skip_snat_for_lb = 1; next;\fR\[char46]
-.IP
-The previous table \fBlr_in_defrag\fR sets the register \fBreg0\fR (or \fBxxreg0\fR for IPv6) and does \fBct_dnat\fR\[char46] Hence for established traffic, this table just advances the packet to the next stage\[char46]
+For all the configured load balancing rules for a Gateway router or Router with gateway port in \fBOVN_Northbound\fR database that includes a L4 port \fIPORT\fR of protocol \fIP\fR and IPv4 or IPv6 address \fIVIP\fR, a priority\-120 flow that matches on \fBct\[char46]new && !ct\[char46]rel && ip && ip\[char46]dst ==
+\fIVIP\fB && \fIP\fB && P\[char46]dst ==
+\fR \fB\fIPORT\fB\fR with an action of \fBct_lb_mark(\fIargs\fB)\fR, where \fIargs\fR contains comma separated IPv4 or IPv6 addresses (and optional port numbers) to load balance to\[char46] If the router is configured to force SNAT any load-balanced packets, the above action will be replaced by \fBflags\[char46]force_snat_for_lb = 1; ct_lb_mark(\fIargs\fB;
+force_snat);\fR\[char46] If the load balancing rule is configured with \fBskip_snat\fR set to true, the above action will be replaced by \fBflags\[char46]skip_snat_for_lb = 1; ct_lb_mark(\fIargs\fB;
+skip_snat);\fR\[char46] If health check is enabled, then \fIargs\fR will only contain those endpoints whose service monitor status entry in \fBOVN_Southbound\fR db is either \fBonline\fR or empty\[char46]
.IP \(bu
-For all the configured load balancing rules for a router in \fBOVN_Northbound\fR database that includes just an IP address \fIVIP\fR to match on, a priority\-110 flow that matches on \fBct\[char46]new && !ct\[char46]rel && ip4 && reg0 ==
-\fIVIP\fB\fR (\fBip6\fR and \fBxxreg0 ==
-\fIVIP\fB\fR in the IPv6 case) with an action of \fBct_lb_mark(\fIargs\fB)\fR, where \fIargs\fR contains comma separated IPv4 or IPv6 addresses\[char46] If the router is configured to force SNAT any load-balanced packets, the above action will be replaced by \fBflags\[char46]force_snat_for_lb = 1;
-ct_lb_mark(\fIargs\fB);\fR\[char46] If the load balancing rule is configured with \fBskip_snat\fR set to true, the above action will be replaced by \fBflags\[char46]skip_snat_for_lb = 1; ct_lb_mark(\fIargs\fB);\fR\[char46]
-.IP
-The previous table \fBlr_in_defrag\fR sets the register \fBreg0\fR (or \fBxxreg0\fR for IPv6) and does \fBct_dnat\fR\[char46] Hence for established traffic, this table just advances the packet to the next stage\[char46]
-.IP \(bu
-For all the configured load balancing rules for a router in \fBOVN_Northbound\fR database that includes just an IP address \fIVIP\fR to match on, a priority\-110 flow that matches on \fBct\[char46]est && !ct\[char46]rel && ip4 && reg0 ==
-\fIVIP\fB\fR (or \fBip6\fR and \fBxxreg0 == \fIVIP\fB\fR) with an action of \fBnext;\fR\[char46] If the router is configured to force SNAT any load-balanced packets, the above action will be replaced by \fBflags\[char46]force_snat_for_lb = 1; next;\fR\[char46] If the load balancing rule is configured with \fBskip_snat\fR set to true, the above action will be replaced by \fBflags\[char46]skip_snat_for_lb = 1; next;\fR\[char46]
+For all the configured load balancing rules for a router in \fBOVN_Northbound\fR database that includes just an IP address \fIVIP\fR to match on, a priority\-110 flow that matches on \fBct\[char46]new && !ct\[char46]rel && ip4 && ip\[char46]dst ==
+\fIVIP\fB\fR with an action of \fBct_lb_mark(\fIargs\fB)\fR, where \fIargs\fR contains comma separated IPv4 or IPv6 addresses\[char46] If the router is configured to force SNAT any load-balanced packets, the above action will be replaced by \fBflags\[char46]force_snat_for_lb = 1;
+ct_lb_mark(\fIargs\fB; force_snat);\fR\[char46] If the load balancing rule is configured with \fBskip_snat\fR set to true, the above action will be replaced by \fBflags\[char46]skip_snat_for_lb = 1; ct_lb_mark(\fIargs\fB;
+skip_snat);\fR\[char46]
.IP
The previous table \fBlr_in_defrag\fR sets the register \fBreg0\fR (or \fBxxreg0\fR for IPv6) and does \fBct_dnat\fR\[char46] Hence for established traffic, this table just advances the packet to the next stage\[char46]
.IP \(bu
If the load balancer is created with \fB\-\-reject\fR option and it has no active backends, a TCP reset segment (for tcp) or an ICMP port unreachable packet (for all other kind of traffic) will be sent whenever an incoming packet is received for this load-balancer\[char46] Please note using \fB\-\-reject\fR option will disable empty_lb SB controller event for this load balancer\[char46]
.IP \(bu
-For the related traffic, a priority 50 flow that matches \fBct\[char46]rel && !ct\[char46]est && !ct\[char46]new \fR with an action of \fBct_commit_nat;\fR, if the router has load balancer assigned to it\[char46] Along with two priority 70 flows that match \fBskip_snat\fR and \fBforce_snat\fR flags\[char46]
+For the related traffic, a priority 50 flow that matches \fBct\[char46]rel && !ct\[char46]est && !ct\[char46]new \fR with an action of \fBct_commit_nat;\fR, if the router has load balancer assigned to it\[char46] Along with two priority 70 flows that match \fBskip_snat\fR and \fBforce_snat\fR flags, setting the \fBflags\[char46]force_snat_for_lb = 1\fR or \fBflags\[char46]skip_snat_for_lb = 1\fR accordingly\[char46]
+.IP \(bu
+For the established traffic, a priority 50 flow that matches \fBct\[char46]est && !ct\[char46]rel && !ct\[char46]new &&
+ct_mark\[char46]natted\fR with an action of \fBnext;\fR, if the router has load balancer assigned to it\[char46] Along with two priority 70 flows that match \fBskip_snat\fR and \fBforce_snat\fR flags, setting the \fBflags\[char46]force_snat_for_lb = 1\fR or \fBflags\[char46]skip_snat_for_lb = 1\fR accordingly\[char46]
.RE
.PP
.PP
@@ -2293,17 +2374,12 @@ A priority\-500 flow that matches IP multicast traffic that was allowed in the r
.IP \(bu
Priority\-200 flows that match ECMP reply traffic for the routes configured to use symmetric replies, with actions \fBpush(xxreg1); xxreg1 = ct_label; eth\[char46]dst = xxreg1[32\[char46]\[char46]79]; pop(xxreg1); next;\fR\[char46] \fBxxreg1\fR is used here to avoid masked access to ct_label, to make the flow HW-offloading friendly\[char46]
.IP \(bu
-Static MAC bindings\[char46] MAC bindings can be known statically based on data in the \fBOVN_Northbound\fR database\[char46] For router ports connected to logical switches, MAC bindings can be known statically from the \fBaddresses\fR column in the \fBLogical_Switch_Port\fR table\[char46] For router ports connected to other logical routers, MAC bindings can be known statically from the \fBmac\fR and \fBnetworks\fR column in the \fBLogical_Router_Port\fR table\[char46] (Note: the flow is NOT installed for the IP addresses that belong to a neighbor logical router port if the current router has the \fBoptions:dynamic_neigh_routers\fR set to \fBtrue\fR)
+Static MAC bindings\[char46] MAC bindings can be known statically based on data in the \fBOVN_Northbound\fR database\[char46] For router ports connected to logical switches, MAC bindings can be known statically from the \fBaddresses\fR column in the \fBLogical_Switch_Port\fR table\[char46] (Note: the flow is not installed for IPs of logical switch ports of type \fBvirtual\fR, and dynamic MAC binding is used for those IPs instead, so that virtual parent failover does not depend on \fB
+ovn\-northd\fR, to achieve better failover performance\[char46]) For router ports connected to other logical routers, MAC bindings can be known statically from the \fBmac\fR and \fBnetworks\fR column in the \fBLogical_Router_Port\fR table\[char46] (Note: the flow is NOT installed for the IP addresses that belong to a neighbor logical router port if the current router has the \fBoptions:dynamic_neigh_routers\fR set to \fBtrue\fR)
.IP
For each IPv4 address \fIA\fR whose host is known to have Ethernet address \fIE\fR on router port \fIP\fR, a priority\-100 flow with match \fBoutport === \fIP\fB
&& reg0 == \fIA\fB\fR has actions \fBeth\[char46]dst = \fIE\fB; next;\fR\[char46]
.IP
-For each virtual ip \fIA\fR configured on a logical port of type \fBvirtual\fR and its virtual parent set in its corresponding \fBPort_Binding\fR record and the virtual parent with the Ethernet address \fIE\fR and the virtual ip is reachable via the router port \fIP\fR, a priority\-100 flow with match \fBoutport === \fIP\fB
-&& xxreg0/reg0 == \fIA\fB\fR has actions \fBeth\[char46]dst = \fIE\fB; next;\fR\[char46]
-.IP
-For each virtual ip \fIA\fR configured on a logical port of type \fBvirtual\fR and its virtual parent \fBnot\fR set in its corresponding \fBPort_Binding\fR record and the virtual ip \fIA\fR is reachable via the router port \fIP\fR, a priority\-100 flow with match \fBoutport === \fIP\fB
-&& xxreg0/reg0 == \fIA\fB\fR has actions \fBeth\[char46]dst = \fI00:00:00:00:00:00\fB; next;\fR\[char46] This flow is added so that the ARP is always resolved for the virtual ip \fIA\fR by generating ARP request and \fBnot\fR consulting the MAC_Binding table as it can have incorrect value for the virtual ip \fIA\fR\[char46]
-.IP
For each IPv6 address \fIA\fR whose host is known to have Ethernet address \fIE\fR on router port \fIP\fR, a priority\-100 flow with match \fBoutport === \fIP\fB
&& xxreg0 == \fIA\fB\fR has actions \fBeth\[char46]dst = \fIE\fB; next;\fR\[char46]
.IP
@@ -2317,11 +2393,16 @@ next;\fR\[char46]
.IP \(bu
Static MAC bindings from NAT entries\[char46] MAC bindings can also be known for the entries in the \fBNAT\fR table\[char46] Below flows are programmed for distributed logical routers i\[char46]e with a distributed router port\[char46]
.IP
-For each row in the \fBNAT\fR table with IPv4 address \fIA\fR in the \fBexternal_ip\fR column of \fBNAT\fR table, a priority\-100 flow with the match \fBoutport === \fIP\fB &&
-reg0 == \fIA\fB\fR has actions \fBeth\[char46]dst = \fIE\fB;
-next;\fR, where \fBP\fR is the distributed logical router port, \fIE\fR is the Ethernet address if set in the \fBexternal_mac\fR column of \fBNAT\fR table for of type \fBdnat_and_snat\fR, otherwise the Ethernet address of the distributed logical router port\[char46] Note that if the \fBexternal_ip\fR is not within a subnet on the owning logical router, then OVN will only create ARP resolution flows if the \fBoptions:add_route\fR is set to \fBtrue\fR\[char46] Otherwise, no ARP resolution flows will be added\[char46]
+For each row in the \fBNAT\fR table with IPv4 address \fIA\fR in the \fBexternal_ip\fR column of \fBNAT\fR table, below two flows are programmed:
.IP
-For IPv6 NAT entries, same flows are added, but using the register \fBxxreg0\fR for the match\[char46]
+A priority\-100 flow with the match \fBoutport == \fIP\fB
+&& reg0 == \fIA\fB\fR has actions \fBeth\[char46]dst =
+\fIE\fB; next;\fR, where \fBP\fR is the distributed logical router port, \fIE\fR is the Ethernet address if set in the \fBexternal_mac\fR column of \fBNAT\fR table for of type \fBdnat_and_snat\fR, otherwise the Ethernet address of the distributed logical router port\[char46] Note that if the \fBexternal_ip\fR is not within a subnet on the owning logical router, then OVN will only create ARP resolution flows if the \fBoptions:add_route\fR is set to \fBtrue\fR\[char46] Otherwise, no ARP resolution flows will be added\[char46]
+.IP
+Corresponding to the above flow, a priority\-150 flow with the match \fBinport == \fIP\fB && outport == \fIP\fB
+&& ip4\[char46]dst == \fIA\fB\fR has actions \fBdrop;\fR to exclude packets that have gone through DNAT/unSNAT stage but failed to convert the destination, to avoid loop\[char46]
+.IP
+For IPv6 NAT entries, same flows are added, but using the register \fBxxreg0\fR and field \fBip6\fR for the match\[char46]
.IP \(bu
If the router datapath runs a port with \fBredirect\-type\fR set to \fBbridged\fR, for each distributed NAT rule with IP \fIA\fR in the \fBlogical_ip\fR column and logical port \fIP\fR in the \fBlogical_port\fR column of \fBNAT\fR table, a priority\-90 flow with the match \fBoutport == \fIQ\fB && ip\[char46]src ===
\fIA\fB && is_chassis_resident(\fIP\fB)\fR, where \fBQ\fR is the distributed logical router port and action \fBget_arp(outport, reg0); next;\fR for IPv4 and \fBget_nd(outport, xxreg0); next;\fR for IPv6\[char46]
@@ -2444,6 +2525,11 @@ This table adds one priority\-0 fallback flow that matches all packets and advan
For distributed logical routers where one or more of the logical router ports specifies a gateway chassis, this table redirects certain packets to the distributed gateway port instances on the gateway chassises\[char46] This table has the following flows:
.RS
.IP \(bu
+For all the configured load balancing rules that include an IPv4 address \fIVIP\fR, and a list of IPv4 backend addresses \fIB0\fR, \fIB1\fR \[char46]\[char46] \fIBn\fR defined for the \fIVIP\fR a priority\-200 flow is added that matches \fB
+ip4 && (ip4\[char46]src == \fIB0\fB || ip4\[char46]src == \fIB1\fB
+|| \[char46]\[char46]\[char46] || ip4\[char46]src == \fIBn\fB)\fR with an action \fB
+outport = \fICR\fB; next;\fR where \fICR\fR is the \fBchassisredirect\fR port representing the instance of the logical router distributed gateway port on the gateway chassis\[char46] If the backend IPv4 address \fIBx\fR is also configured with L4 port \fIPORT\fR of protocol \fIP\fR, then the match also includes \fBP\[char46]src\fR == \fIPORT\fR\[char46] Similar flows are added for IPv6\[char46]
+.IP \(bu
For each NAT rule in the OVN Northbound database that can be handled in a distributed manner, a priority\-100 logical flow with match \fBip4\[char46]src == \fIB\fB &&
outport == \fIGW\fB\fR && is_chassis_resident(\fIP\fR), where \fIGW\fR is the distributed gateway port specified in the NAT rule and \fIP\fR is the NAT logical port\[char46] IP traffic matching the above rule will be managed locally setting \fBreg1\fR to \fIC\fR and \fBeth\[char46]src\fR to \fID\fR, where \fIC\fR is NAT external ip and \fID\fR is NAT external mac\[char46]
.IP \(bu
@@ -2534,14 +2620,8 @@ Known MAC address\[char46] A priority\-0 flow with match \fB1\fR has actions \fB
This table checks if the packet needs to be DNATed in the router ingress table \fBlr_in_dnat\fR after it is SNATed and looped back to the ingress pipeline\[char46] This check is done only for routers configured with distributed gateway ports and NAT entries\[char46] This check is done so that SNAT and DNAT is done in different zones instead of a common zone\[char46]
.RS
.IP \(bu
-For each NAT rule in the OVN Northbound database on a distributed router, a priority\-50 logical flow with match \fBip4\[char46]dst == \fIE\fB &&
-is_chassis_resident(\fIP\fB)\fR, where \fIE\fR is the external IP address specified in the NAT rule, \fIGW\fR is the logical router distributed gateway port\[char46] For dnat_and_snat NAT rule, \fIP\fR is the logical port specified in the NAT rule\[char46] If \fBlogical_port\fR column of \fBNAT\fR table is NOT set, then \fIP\fR is the \fBchassisredirect port\fR of \fIGW\fR with the actions: \fBREGBIT_DST_NAT_IP_LOCAL = 1; next; \fR
-.IP \(bu
A priority\-0 logical flow with match \fB1\fR has actions \fBREGBIT_DST_NAT_IP_LOCAL = 0; next;\fR\[char46]
.RE
-.PP
-.PP
-This table also installs a priority\-50 logical flow for each logical router that has NATs configured on it\[char46] The flow has match \fBip && ct_label\[char46]natted == 1\fR and action \fBREGBIT_DST_NAT_IP_LOCAL = 1; next;\fR\[char46] This is intended to ensure that traffic that was DNATted locally will use a separate conntrack zone for SNAT if SNAT is required later in the egress pipeline\[char46] Note that this flow checks the value of \fBct_label\[char46]natted\fR, which is set in the ingress pipeline\[char46] This means that ovn-northd assumes that this value is carried over from the ingress pipeline to the egress pipeline and is not altered or cleared\[char46] If conntrack label values are ever changed to be cleared between the ingress and egress pipelines, then the match conditions of this flow will be updated accordingly\[char46]
.ST "Egress Table 1: UNDNAT"
.PP
.PP
@@ -2553,20 +2633,22 @@ A priority\-0 logical flow with match \fB1\fR has actions \fBnext;\fR\[char46]
.ST "Egress Table 1: UNDNAT on Gateway Routers"
.RS
.IP \(bu
+For IPv6 Neighbor Discovery or Router Solicitation/Advertisement traffic, a priority\-100 flow with action \fBnext;\fR\[char46]
+.IP \(bu
For all IP packets, a priority\-50 flow with an action \fBflags\[char46]loopback = 1; ct_dnat;\fR\[char46]
.RE
.ST "Egress Table 1: UNDNAT on Distributed Routers"
.RS
.IP \(bu
For all the configured load balancing rules for a router with gateway port in \fBOVN_Northbound\fR database that includes an IPv4 address \fBVIP\fR, for every backend IPv4 address \fIB\fR defined for the \fBVIP\fR a priority\-120 flow is programmed on gateway chassis that matches \fBip && ip4\[char46]src == \fIB\fB &&
-outport == \fIGW\fB\fR, where \fIGW\fR is the logical router gateway port with an action \fBct_dnat_in_czone;\fR\[char46] If the backend IPv4 address \fIB\fR is also configured with L4 port \fIPORT\fR of protocol \fIP\fR, then the match also includes \fBP\[char46]src\fR == \fIPORT\fR\[char46] These flows are not added for load balancers with IPv6 \fIVIPs\fR\[char46]
+outport == \fIGW\fB\fR, where \fIGW\fR is the logical router gateway port with an action \fBct_dnat;\fR\[char46] If the backend IPv4 address \fIB\fR is also configured with L4 port \fIPORT\fR of protocol \fIP\fR, then the match also includes \fBP\[char46]src\fR == \fIPORT\fR\[char46] These flows are not added for load balancers with IPv6 \fIVIPs\fR\[char46]
.IP
If the router is configured to force SNAT any load-balanced packets, above action will be replaced by \fBflags\[char46]force_snat_for_lb = 1; ct_dnat;\fR\[char46]
.IP \(bu
For each configuration in the OVN Northbound database that asks to change the destination IP address of a packet from an IP address of \fIA\fR to \fIB\fR, a priority\-100 flow matches \fBip && ip4\[char46]src == \fIB\fB
-&& outport == \fIGW\fB\fR, where \fIGW\fR is the logical router gateway port, with an action \fBct_dnat_in_czone;\fR\[char46] If the NAT rule is of type dnat_and_snat and has \fBstateless=true\fR in the options, then the action would be \fBnext;\fR\[char46]
+&& outport == \fIGW\fB\fR, where \fIGW\fR is the logical router gateway port, with an action \fBct_dnat;\fR\[char46] If the NAT rule is of type dnat_and_snat and has \fBstateless=true\fR in the options, then the action would be \fBnext;\fR\[char46]
.IP
-If the NAT rule cannot be handled in a distributed manner, then the priority\-100 flow above is only programmed on the gateway chassis with the action \fBct_dnat_in_czone\fR\[char46]
+If the NAT rule cannot be handled in a distributed manner, then the priority\-100 flow above is only programmed on the gateway chassis with the action \fBct_dnat\fR\[char46]
.IP
If the NAT rule can be handled in a distributed manner, then there is an additional action \fBeth\[char46]src = \fIEA\fB;\fR, where \fIEA\fR is the ethernet address associated with the IP address \fIA\fR in the NAT rule\[char46] This allows upstream MAC learning to point to the correct chassis\[char46]
.RE
@@ -2627,11 +2709,7 @@ If the NAT rule cannot be handled in a distributed manner, then the below flows
.RS
.IP \(bu
The first flow is added with the calculated priority \fIP\fR and match \fBip && ip4\[char46]src == \fIA\fB &&
-outport == \fIGW\fB\fR, where \fIGW\fR is the logical router gateway port, with an action \fBct_snat_in_czone(\fIB\fB);\fR to SNATed in the common zone\[char46] If the NAT rule is of type dnat_and_snat and has \fBstateless=true\fR in the options, then the action would be \fBip4/6\[char46]src=(\fIB\fB)\fR\[char46]
-.IP \(bu
-The second flow is added with the calculated priority \fB\fIP\fB + 1 \fR and match \fBip && ip4\[char46]src == \fIA\fB &&
-outport == \fIGW\fB &&
-REGBIT_DST_NAT_IP_LOCAL == 0\fR, where \fIGW\fR is the logical router gateway port, with an action \fBct_snat(\fIB\fB);\fR to SNAT in the snat zone\[char46] If the NAT rule is of type dnat_and_snat and has \fBstateless=true\fR in the options, then the action would be \fBip4/6\[char46]src=(\fIB\fB)\fR\[char46]
+outport == \fIGW\fB\fR, where \fIGW\fR is the logical router gateway port, with an action \fBct_snat(\fIB\fB);\fR to SNATed in the common zone\[char46] If the NAT rule is of type dnat_and_snat and has \fBstateless=true\fR in the options, then the action would be \fBip4/6\[char46]src=(\fIB\fB)\fR\[char46]
.RE
.IP
If the NAT rule can be handled in a distributed manner, then there is an additional action (for both the flows) \fBeth\[char46]src = \fIEA\fB;\fR, where \fIEA\fR is the ethernet address associated with the IP address \fIA\fR in the NAT rule\[char46] This allows upstream MAC learning to point to the correct chassis\[char46]
@@ -2645,7 +2723,15 @@ If the NAT rule has \fBexempted_ext_ips\fR set, then there is an additional flow
.IP \(bu
A priority\-0 logical flow with match \fB1\fR has actions \fBnext;\fR\[char46]
.RE
-.ST "Egress Table 4: Egress Loopback"
+.ST "Egress Table 4: Post SNAT"
+.PP
+.PP
+Packets reaching this table are processed according to the flows below:
+.RS
+.IP \(bu
+A priority\-0 logical flow that matches all packets not already handled (match \fB1\fR) and action \fBnext;\fR\[char46]
+.RE
+.ST "Egress Table 5: Egress Loopback"
.PP
.PP
For distributed logical routers where one of the logical router ports specifies a gateway chassis\[char46]
@@ -2676,8 +2762,6 @@ is_chassis_resident(\fIP\fB)\fR, where \fIE\fR is the external IP address specif
.br
\fB flags\[char46]loopback = 1;
.br
-\fB flags\[char46]use_snat_zone = REGBIT_DST_NAT_IP_LOCAL;
-.br
\fB reg0 = 0;
.br
\fB reg1 = 0;
@@ -2699,7 +2783,7 @@ is_chassis_resident(\fIP\fB)\fR, where \fIE\fR is the external IP address specif
.IP \(bu
A priority\-0 logical flow with match \fB1\fR has actions \fBnext;\fR\[char46]
.RE
-.ST "Egress Table 5: Delivery"
+.ST "Egress Table 6: Delivery"
.PP
.PP
Packets that reach this table are ready for delivery\[char46] It contains:
diff --git a/src/static/support/dist-docs/ovn-northd.8.html b/src/static/support/dist-docs/ovn-northd.8.html
index 178f336c..db2e0ca3 100644
--- a/src/static/support/dist-docs/ovn-northd.8.html
+++ b/src/static/support/dist-docs/ovn-northd.8.html
@@ -1,60 +1,40 @@
-ovn-northd(8) OVN Manual ovn-northd(8)
-
-
+ovn-northd(8) OVN Manual ovn-northd(8)
NAME
- ovn-northd and ovn-northd-ddlog - Open Virtual Network central control
- daemon
+ ovn-northd - Open Virtual Network central control daemon
SYNOPSIS
ovn-northd [options]
DESCRIPTION
- ovn-northd is a centralized daemon responsible for translating the
- high-level OVN configuration into logical configuration consumable by
- daemons such as ovn-controller. It translates the logical network con‐
- figuration in terms of conventional network concepts, taken from the
+ ovn-northd is a centralized daemon responsible for translating the
+ high-level OVN configuration into logical configuration consumable by
+ daemons such as ovn-controller. It translates the logical network con‐
+ figuration in terms of conventional network concepts, taken from the
OVN Northbound Database (see ovn-nb(5)), into logical datapath flows in
the OVN Southbound Database (see ovn-sb(5)) below it.
- ovn-northd is implemented in C. ovn-northd-ddlog is a compatible imple‐
- mentation written in DDlog, a language for incremental database pro‐
- cessing. This documentation applies to both implementations, with dif‐
- ferences indicated where relevant.
-
OPTIONS
--ovnnb-db=database
- The OVSDB database containing the OVN Northbound Database. If
- the OVN_NB_DB environment variable is set, its value is used as
+ The OVSDB database containing the OVN Northbound Database. If
+ the OVN_NB_DB environment variable is set, its value is used as
the default. Otherwise, the default is unix:/ovnnb_db.sock.
--ovnsb-db=database
- The OVSDB database containing the OVN Southbound Database. If
- the OVN_SB_DB environment variable is set, its value is used as
+ The OVSDB database containing the OVN Southbound Database. If
+ the OVN_SB_DB environment variable is set, its value is used as
the default. Otherwise, the default is unix:/ovnsb_db.sock.
- --ddlog-record=file
- This option is for ovn-north-ddlog only. It causes the daemon to
- record the initial database state and later changes to file in
- the text-based DDlog command format. The ovn_northd_cli program
- can later replay these changes for debugging purposes. This
- option has a performance impact. See debugging-ddlog.rst in the
- OVN documentation for more details.
-
--dry-run
Causes ovn-northd to start paused. In the paused state,
ovn-northd does not apply any changes to the databases, although
- it continues to monitor them. For more information, see the
+ it continues to monitor them. For more information, see the
pause command, under Runtime Management Commands below.
- For ovn-northd-ddlog, one could use this option with
- --ddlog-record to generate a replay log without restarting a
- process or disturbing a running system.
-
n-threads N
- In certain situations, it may be desirable to enable paral‐
- lelization on a system to decrease latency (at the potential
+ In certain situations, it may be desirable to enable paral‐
+ lelization on a system to decrease latency (at the potential
cost of increasing CPU usage).
This option will cause ovn-northd to use N threads when building
@@ -65,15 +45,13 @@
lelization is enabled (with 256 threads) and a warning is
logged.
- ovn-northd-ddlog does not support this option.
-
database in the above options must be an OVSDB active or passive con‐
nection method, as described in ovsdb(7).
Daemon Options
--pidfile[=pidfile]
Causes a file (by default, program.pid) to be created indicating
- the PID of the running process. If the pidfile argument is not
+ the PID of the running process. If the pidfile argument is not
specified, or if it does not begin with /, then it is created in
.
@@ -91,13 +69,13 @@
Runs this program as a background process. The process forks,
and in the child it starts a new session, closes the standard
file descriptors (which has the side effect of disabling logging
- to the console), and changes its current directory to the root
- (unless --no-chdir is specified). After the child completes its
+ to the console), and changes its current directory to the root
+ (unless --no-chdir is specified). After the child completes its
initialization, the parent exits.
--monitor
- Creates an additional process to monitor this program. If it
- dies due to a signal that indicates a programming error (SIGA‐
+ Creates an additional process to monitor this program. If it
+ dies due to a signal that indicates a programming error (SIGA‐‐
BRT, SIGALRM, SIGBUS, SIGFPE, SIGILL, SIGPIPE, SIGSEGV, SIGXCPU,
or SIGXFSZ) then the monitor process starts a new copy of it. If
the daemon dies or exits for another reason, the monitor process
@@ -108,10 +86,10 @@
--no-chdir
By default, when --detach is specified, the daemon changes its
- current working directory to the root directory after it
- detaches. Otherwise, invoking the daemon from a carelessly cho‐
- sen directory would prevent the administrator from unmounting
- the file system that holds that directory.
+ current working directory to the root directory after it de‐
+ taches. Otherwise, invoking the daemon from a carelessly chosen
+ directory would prevent the administrator from unmounting the
+ file system that holds that directory.
Specifying --no-chdir suppresses this behavior, preventing the
daemon from changing its current working directory. This may be
@@ -130,21 +108,21 @@
implementations that are typically enforced from kernel-space
(e.g. DAC or MAC), self-confinement is imposed from the user-
space daemon itself and hence should not be considered as a full
- confinement strategy, but instead should be viewed as an addi‐
+ confinement strategy, but instead should be viewed as an addi‐
tional layer of security.
--user=user:group
- Causes this program to run as a different user specified in
- user:group, thus dropping most of the root privileges. Short
- forms user and :group are also allowed, with current user or
- group assumed, respectively. Only daemons started by the root
+ Causes this program to run as a different user specified in
+ user:group, thus dropping most of the root privileges. Short
+ forms user and :group are also allowed, with current user or
+ group assumed, respectively. Only daemons started by the root
user accepts this argument.
On Linux, daemons will be granted CAP_IPC_LOCK and
- CAP_NET_BIND_SERVICES before dropping root privileges. Daemons
- that interact with a datapath, such as ovs-vswitchd, will be
- granted three additional capabilities, namely CAP_NET_ADMIN,
- CAP_NET_BROADCAST and CAP_NET_RAW. The capability change will
+ CAP_NET_BIND_SERVICES before dropping root privileges. Daemons
+ that interact with a datapath, such as ovs-vswitchd, will be
+ granted three additional capabilities, namely CAP_NET_ADMIN,
+ CAP_NET_BROADCAST and CAP_NET_RAW. The capability change will
apply even if the new user is root.
On Windows, this option is not currently supported. For security
@@ -159,13 +137,13 @@
words separated by spaces or commas or colons, up to one from each
category below:
- · A valid module name, as displayed by the vlog/list command
+ • A valid module name, as displayed by the vlog/list command
on ovs-appctl(8), limits the log level change to the speci‐
fied module.
- · syslog, console, or file, to limit the log level change to
- only to the system log, to the console, or to a file,
- respectively. (If --detach is specified, the daemon closes
+ • syslog, console, or file, to limit the log level change to
+ only to the system log, to the console, or to a file, re‐
+ spectively. (If --detach is specified, the daemon closes
its standard file descriptors, so logging to the console
will have no effect.)
@@ -173,15 +151,15 @@
only useful along with the --syslog-target option (the word
has no effect otherwise).
- · off, emer, err, warn, info, or dbg, to control the log
- level. Messages of the given severity or higher will be
- logged, and messages of lower severity will be filtered
- out. off filters out all messages. See ovs-appctl(8) for a
+ • off, emer, err, warn, info, or dbg, to control the log
+ level. Messages of the given severity or higher will be
+ logged, and messages of lower severity will be filtered
+ out. off filters out all messages. See ovs-appctl(8) for a
definition of each log level.
Case is not significant within spec.
- Regardless of the log levels set for file, logging to a file will
+ Regardless of the log levels set for file, logging to a file will
not take place unless --log-file is also specified (see below).
For compatibility with older versions of OVS, any is accepted as a
@@ -189,22 +167,22 @@
-v
--verbose
- Sets the maximum logging verbosity level, equivalent to --ver‐
+ Sets the maximum logging verbosity level, equivalent to --ver‐‐
bose=dbg.
-vPATTERN:destination:pattern
--verbose=PATTERN:destination:pattern
- Sets the log pattern for destination to pattern. Refer to
- ovs-appctl(8) for a description of the valid syntax for pattern.
+ Sets the log pattern for destination to pattern. Refer to ovs-ap‐‐
+ pctl(8) for a description of the valid syntax for pattern.
-vFACILITY:facility
--verbose=FACILITY:facility
Sets the RFC5424 facility of the log message. facility can be one
of kern, user, mail, daemon, auth, syslog, lpr, news, uucp, clock,
- ftp, ntp, audit, alert, clock2, local0, local1, local2, local3,
+ ftp, ntp, audit, alert, clock2, local0, local1, local2, local3,
local4, local5, local6 or local7. If this option is not specified,
- daemon is used as the default for the local system syslog and
- local0 is used while sending a message to the target provided via
+ daemon is used as the default for the local system syslog and lo‐‐
+ cal0 is used while sending a message to the target provided via
the --syslog-target option.
--log-file[=file]
@@ -213,64 +191,64 @@
if file is omitted is /usr/local/var/log/ovn/program.log.
--syslog-target=host:port
- Send syslog messages to UDP port on host, in addition to the sys‐
- tem syslog. The host must be a numerical IP address, not a host‐
+ Send syslog messages to UDP port on host, in addition to the sys‐
+ tem syslog. The host must be a numerical IP address, not a host‐
name.
--syslog-method=method
- Specify method as how syslog messages should be sent to syslog
+ Specify method as how syslog messages should be sent to syslog
daemon. The following forms are supported:
- · libc, to use the libc syslog() function. Downside of using
- this options is that libc adds fixed prefix to every mes‐
- sage before it is actually sent to the syslog daemon over
+ • libc, to use the libc syslog() function. Downside of using
+ this options is that libc adds fixed prefix to every mes‐
+ sage before it is actually sent to the syslog daemon over
/dev/log UNIX domain socket.
- · unix:file, to use a UNIX domain socket directly. It is pos‐
+ • unix:file, to use a UNIX domain socket directly. It is pos‐
sible to specify arbitrary message format with this option.
- However, rsyslogd 8.9 and older versions use hard coded
- parser function anyway that limits UNIX domain socket use.
- If you want to use arbitrary message format with older
- rsyslogd versions, then use UDP socket to localhost IP
- address instead.
-
- · udp:ip:port, to use a UDP socket. With this method it is
- possible to use arbitrary message format also with older
- rsyslogd. When sending syslog messages over UDP socket
- extra precaution needs to be taken into account, for exam‐
- ple, syslog daemon needs to be configured to listen on the
- specified UDP port, accidental iptables rules could be
- interfering with local syslog traffic and there are some
- security considerations that apply to UDP sockets, but do
- not apply to UNIX domain sockets.
-
- · null, to discard all messages logged to syslog.
-
- The default is taken from the OVS_SYSLOG_METHOD environment vari‐
+ However, rsyslogd 8.9 and older versions use hard coded
+ parser function anyway that limits UNIX domain socket use.
+ If you want to use arbitrary message format with older
+ rsyslogd versions, then use UDP socket to localhost IP ad‐
+ dress instead.
+
+ • udp:ip:port, to use a UDP socket. With this method it is
+ possible to use arbitrary message format also with older
+ rsyslogd. When sending syslog messages over UDP socket ex‐
+ tra precaution needs to be taken into account, for example,
+ syslog daemon needs to be configured to listen on the spec‐
+ ified UDP port, accidental iptables rules could be inter‐
+ fering with local syslog traffic and there are some secu‐
+ rity considerations that apply to UDP sockets, but do not
+ apply to UNIX domain sockets.
+
+ • null, to discard all messages logged to syslog.
+
+ The default is taken from the OVS_SYSLOG_METHOD environment vari‐
able; if it is unset, the default is libc.
PKI Options
- PKI configuration is required in order to use SSL for the connections
+ PKI configuration is required in order to use SSL for the connections
to the Northbound and Southbound databases.
-p privkey.pem
--private-key=privkey.pem
- Specifies a PEM file containing the private key used as
+ Specifies a PEM file containing the private key used as
identity for outgoing SSL connections.
-c cert.pem
--certificate=cert.pem
- Specifies a PEM file containing a certificate that certi‐
+ Specifies a PEM file containing a certificate that certi‐
fies the private key specified on -p or --private-key to be
trustworthy. The certificate must be signed by the certifi‐
- cate authority (CA) that the peer in SSL connections will
+ cate authority (CA) that the peer in SSL connections will
use to verify it.
-C cacert.pem
--ca-cert=cacert.pem
Specifies a PEM file containing the CA certificate for ver‐
ifying certificates presented to this program by SSL peers.
- (This may be the same certificate that SSL peers use to
+ (This may be the same certificate that SSL peers use to
verify the certificate specified on -c or --certificate, or
it may be a different one, depending on the PKI design in
use.)
@@ -285,9 +263,9 @@
Other Options
--unixctl=socket
Sets the name of the control socket on which program listens for
- runtime management commands (see RUNTIME MANAGEMENT COMMANDS,
- below). If socket does not begin with /, it is interpreted as
- relative to . If --unixctl is not used at all, the default
+ runtime management commands (see RUNTIME MANAGEMENT COMMANDS,
+ below). If socket does not begin with /, it is interpreted as
+ relative to . If --unixctl is not used at all, the default
socket is /program.pid.ctl, where pid is program’s process ID.
On Windows a local named pipe is used to listen for runtime man‐
@@ -316,7 +294,7 @@
pause Pauses ovn-northd. When it is paused, ovn-northd receives
changes from the Northbound and Southbound database
- changes as usual, but it does not send any updates. A
+ changes as usual, but it does not send any updates. A
paused ovn-northd also drops database locks, which allows
any other non-paused instance of ovn-northd to take over.
@@ -329,7 +307,7 @@
Returns "true" if ovn-northd is currently paused, "false"
otherwise.
- status Prints this server’s status. Status will be "active" if
+ status Prints this server’s status. Status will be "active" if
ovn-northd has acquired OVSDB lock on SB DB, "standby" if
it has not or "paused" if this instance is paused.
@@ -339,100 +317,80 @@
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-northd 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-northd will reset
- its local index so that it can interact with the south‐
- bound database again.
+ will be reset to zero. This will cause ovn-northd to be
+ unable to read or write to the southbound database, be‐
+ cause it will always detect the data as stale. In such a
+ case, run this command so that ovn-northd will reset its
+ local index so that it can interact with the southbound
+ database again.
nb-cluster-state-reset
- Reset northbound database cluster status when databases
+ Reset northbound database cluster status when databases
are destroyed and rebuilt.
- This performs the same task as sb-cluster-state-reset
- except for the northbound database client.
+ This performs the same task as sb-cluster-state-reset ex‐
+ cept for the northbound database client.
set-n-threads N
Set the number of threads used for building logical
- flows. When N is within [2-256], parallelization is
- enabled. When N is 1 parallelization is disabled. When N
- is less than 1 or more than 256, an error is returned. If
- ovn-northd fails to start parallelization (e.g. fails to
- setup semaphores, parallelization is disabled and an
- error is returned.
+ flows. When N is within [2-256], parallelization is en‐
+ abled. When N is 1 parallelization is disabled. When N is
+ less than 1 or more than 256, an error is returned. If
+ ovn-northd fails to start parallelization (e.g. fails to
+ setup semaphores, parallelization is disabled and an er‐
+ ror is returned.
get-n-threads
- Return the number of threads used for building logical
+ Return the number of threads used for building logical
flows.
inc-engine/show-stats
- Display ovn-northd engine counters. For each engine node
+ Display ovn-northd engine counters. For each engine node
the following counters have been added:
- · recompute
+ • recompute
- · compute
+ • compute
- · abort
+ • abort
inc-engine/show-stats engine_node_name counter_name
- Display the ovn-northd engine counter(s) for the speci‐
- fied engine_node_name. counter_name is optional and can
+ Display the ovn-northd engine counter(s) for the speci‐
+ fied engine_node_name. counter_name is optional and can
be one of recompute, compute or abort.
inc-engine/clear-stats
Reset ovn-northd engine counters.
- Only ovn-northd-ddlog supports the following commands:
-
- enable-cpu-profiling
- disable-cpu-profiling
- Enables or disables profiling of CPU time used by the DDlog
- engine. When CPU profiling is enabled, the profile command
- (see below) will include DDlog CPU usage statistics in its
- output. Enabling CPU profiling will slow ovn-northd-ddlog.
- Disabling CPU profiling does not clear any previously
- recorded statistics.
-
- profile
- Outputs a profile of the current and peak sizes of arrange‐
- ments inside DDlog. This profiling data can be useful for
- optimizing DDlog code. If CPU profiling was previously
- enabled (even if it was later disabled), the output also
- includes a CPU time profile. See Profiling inside the tuto‐
- rial in the DDlog repository for an introduction to profil‐
- ing DDlog.
-
ACTIVE-STANDBY FOR HIGH AVAILABILITY
You may run ovn-northd more than once in an OVN deployment. When con‐
nected to a standalone or clustered DB setup, OVN will automatically
ensure that only one of them is active at a time. If multiple instances
- of ovn-northd are running and the active ovn-northd fails, one of the
+ of ovn-northd are running and the active ovn-northd fails, one of the
hot standby instances of ovn-northd will automatically take over.
Active-Standby with multiple OVN DB servers
You may run multiple OVN DB servers in an OVN deployment with:
- · OVN DB servers deployed in active/passive mode with one
+ • OVN DB servers deployed in active/passive mode with one
active and multiple passive ovsdb-servers.
- · ovn-northd also deployed on all these nodes, using unix
+ • ovn-northd also deployed on all these nodes, using unix
ctl sockets to connect to the local OVN DB servers.
- In such deployments, the ovn-northds on the passive nodes will process
- the DB changes and compute logical flows to be thrown out later,
- because write transactions are not allowed by the passive ovsdb-
- servers. It results in unnecessary CPU usage.
+ In such deployments, the ovn-northds on the passive nodes will process
+ the DB changes and compute logical flows to be thrown out later, be‐
+ cause write transactions are not allowed by the passive ovsdb-servers.
+ It results in unnecessary CPU usage.
- With the help of runtime management command pause, you can pause
- ovn-northd on these nodes. When a passive node becomes master, you can
- use the runtime management command resume to resume the ovn-northd to
+ With the help of runtime management command pause, you can pause
+ ovn-northd on these nodes. When a passive node becomes master, you can
+ use the runtime management command resume to resume the ovn-northd to
process the DB changes.
LOGICAL FLOW TABLE STRUCTURE
- One of the main purposes of ovn-northd is to populate the Logical_Flow
- table in the OVN_Southbound database. This section describes how
+ One of the main purposes of ovn-northd is to populate the Logical_Flow
+ table in the OVN_Southbound database. This section describes how
ovn-northd does this for switch and router logical datapaths.
Logical Switch Datapaths
@@ -440,83 +398,112 @@
Ingress table 0 contains these logical flows:
- · Priority 100 flows to drop packets with VLAN tags or mul‐
+ • Priority 100 flows to drop packets with VLAN tags or mul‐
ticast Ethernet source addresses.
- · For each disabled logical port, a priority 100 flow is
+ • For each disabled logical port, a priority 100 flow is
added which matches on all packets and applies the action
REGBIT_PORT_SEC_DROP" = 1; next;" so that the packets are
dropped in the next stage.
- · For each (enabled) vtep logical port, a priority 70 flow
- is added which matches on all packets and applies the
- action next(pipeline=ingress, table=S_SWITCH_IN_L2_LKUP)
- = 1; to skip most stages of ingress pipeline and go
- directly to ingress L2 lookup table to determine the out‐
- put port. Packets from VTEP (RAMP) switch should not be
- subjected to any ACL checks. Egress pipeline will do the
- ACL checks.
-
- · For each enabled logical port configured with qdisc queue
- id in the options:qdisc_queue_id column of Logi‐
+ • For each (enabled) vtep logical port, a priority 70 flow
+ is added which matches on all packets and applies the ac‐
+ tion next(pipeline=ingress, table=S_SWITCH_IN_L3_LKUP) =
+ 1; to skip most stages of ingress pipeline and go di‐
+ rectly to ingress L2 lookup table to determine the output
+ port. Packets from VTEP (RAMP) switch should not be sub‐
+ jected to any ACL checks. Egress pipeline will do the ACL
+ checks.
+
+ • For each enabled logical port configured with qdisc queue
+ id in the options:qdisc_queue_id column of Logi‐‐
cal_Switch_Port, a priority 70 flow is added which
matches on all packets and applies the action
set_queue(id); REGBIT_PORT_SEC_DROP" =
check_in_port_sec(); next;".
- · A priority 1 flow is added which matches on all packets
- for all the logical ports and applies the action REG‐
+ • A priority 1 flow is added which matches on all packets
+ for all the logical ports and applies the action REG‐‐
BIT_PORT_SEC_DROP" = check_in_port_sec(); next; to evalu‐
- ate the port security. The action check_in_port_sec
- applies the port security rules defined in the port_secu‐
+ ate the port security. The action check_in_port_sec ap‐
+ plies the port security rules defined in the port_secu‐‐
rity column of Logical_Switch_Port table.
Ingress Table 1: Ingress Port Security - Apply
+ For each logical switch port P of type router connected to a gw router
+ a priority-120 flow that matches ’recirculated’ icmp{4,6} error ’packet
+ too big’ and eth.src == D &&&& outport == P &&&& flags.tunnel_rx == 1 where
+ D is the peer logical router port RP mac address, swaps inport and out‐
+ port and applies the action next(pipeline=S_SWITCH_IN_L2_LKUP).
+
+ For each logical switch port P of type router connected to a distrib‐
+ uted router a priority-120 flow that matches ’recirculated’ icmp{4,6}
+ error ’packet too big’ and eth.dst == D &&&& flags.tunnel_rx == 1 where D
+ is the peer logical router port RP mac address, swaps inport and out‐
+ port and applies the action next(pipeline=S_SWITCH_IN_L2_LKUP).
+
+ This table adds a priority-110 flow that matches ’recirculated’
+ icmp{4,6} error ’packet too big’ to drop the packet.
+
This table drops the packets if the port security check failed in the
previous stage i.e the register bit REGBIT_PORT_SEC_DROP is set to 1.
Ingress table 1 contains these logical flows:
- · A priority-50 fallback flow that drops the packet if the
+ • A priority-50 fallback flow that drops the packet if the
register bit REGBIT_PORT_SEC_DROP is set to 1.
- · One priority-0 fallback flow that matches all packets and
+ • One priority-0 fallback flow that matches all packets and
advances to the next table.
Ingress Table 2: Lookup MAC address learning table
- This table looks up the MAC learning table of the logical switch data‐
- path to check if the port-mac pair is present or not. MAC is learnt
- only for logical switch VIF ports whose port security is disabled and
- ’unknown’ address set.
+ This table looks up the MAC learning table of the logical switch data‐
+ path to check if the port-mac pair is present or not. MAC is learnt for
+ logical switch VIF ports whose port security is disabled and ’unknown’
+ address setn as well as for localnet ports with option local‐
+ net_learn_fdb. A localnet port entry does not overwrite a VIF port en‐
+ try.
- · For each such logical port p whose port security is dis‐
- abled and ’unknown’ address set following flow is added.
+ • For each such VIF logical port p whose port security is
+ disabled and ’unknown’ address set following flow is
+ added.
- · Priority 100 flow with the match inport == p and
+ • Priority 100 flow with the match inport == p and
action reg0[11] = lookup_fdb(inport, eth.src);
next;
- · One priority-0 fallback flow that matches all packets and
+ • For each such localnet logical port p following flow is
+ added.
+
+ • Priority 100 flow with the match inport == p and
+ action flags.localnet = 1; reg0[11] =
+ lookup_fdb(inport, eth.src); next;
+
+ • One priority-0 fallback flow that matches all packets and
advances to the next table.
- Ingress Table 3: Learn MAC of ’unknown’ ports.
+ Ingress Table 3: Learn MAC of unknown ports.
- This table learns the MAC addresses seen on the logical ports whose
- port security is disabled and ’unknown’ address set if the lookup_fdb
- action returned false in the previous table.
+ This table learns the MAC addresses seen on the VIF logical ports whose
+ port security is disabled and ’unknown’ address set as well as on lo‐
+ calnet ports with localnet_learn_fdb option set if the lookup_fdb ac‐
+ tion returned false in the previous table. For localnet ports (with
+ flags.localnet = 1), lookup_fdb returns true if (port, mac) is found or
+ if a mac is found for a port of type vif.
- · For each such logical port p whose port security is dis‐
- abled and ’unknown’ address set following flow is added.
+ • For each such VIF logical port p whose port security is
+ disabled and ’unknown’ address set and localnet port fol‐
+ lowing flow is added.
- · Priority 100 flow with the match inport == p &&&&
+ • Priority 100 flow with the match inport == p &&&&
reg0[11] == 0 and action put_fdb(inport, eth.src);
- next; which stores the port-mac in the mac learn‐
- ing table of the logical switch datapath and
- advances the packet to the next table.
+ next; which stores the port-mac in the mac learn‐
+ ing table of the logical switch datapath and ad‐
+ vances the packet to the next table.
- · One priority-0 fallback flow that matches all packets and
+ • One priority-0 fallback flow that matches all packets and
advances to the next table.
Ingress Table 4: from-lport Pre-ACLs
@@ -525,18 +512,21 @@
ingress table ACLs. It contains a priority-0 flow that simply moves
traffic to the next table. If stateful ACLs are used in the logical
datapath, a priority-100 flow is added that sets a hint (with reg0[0] =
- 1; next;) for table Pre-stateful to send IP packets to the connection
- tracker before eventually advancing to ingress table ACLs. If special
- ports such as route ports or localnet ports can’t use ct(), a prior‐
- ity-110 flow is added to skip over stateful ACLs. Multicast, IPv6
- Neighbor Discovery and MLD traffic also skips stateful ACLs. For
- "allow-stateless" ACLs, a flow is added to bypass setting the hint for
- connection tracker processing when there are stateful ACLs or LB rules;
- REGBIT_ACL_STATELESS is set for traffic matching stateless ACL flows.
+ 1; next;) for table Pre-stateful to send IP packets to the connection
+ tracker before eventually advancing to ingress table ACLs. If special
+ ports such as route ports or localnet ports can’t use ct(), a prior‐
+ ity-110 flow is added to skip over stateful ACLs. This priority-110
+ flow is not addd for router ports if the option enable_router_port_acl
+ is set to true in options:enable_router_port_acl column of Logi‐‐
+ cal_Switch_Port. Multicast, IPv6 Neighbor Discovery and MLD traffic
+ also skips stateful ACLs. For "allow-stateless" ACLs, a flow is added
+ to bypass setting the hint for connection tracker processing when there
+ are stateful ACLs or LB rules; REGBIT_ACL_STATELESS is set for traffic
+ matching stateless ACL flows.
This table also has a priority-110 flow with the match eth.dst == E for
all logical switch datapaths to move traffic to the next table. Where E
- is the service monitor mac defined in the options:svc_monitor_mac col‐
+ is the service monitor mac defined in the options:svc_monitor_mac col‐
umn of NB_Global table.
Ingress Table 5: Pre-LB
@@ -547,19 +537,19 @@
priority-110 flows to move multicast, IPv6 Neighbor Discovery and MLD
traffic to the next table. It also contains two priority-110 flows to
move stateless traffic, i.e traffic for which REGBIT_ACL_STATELESS is
- set, to the next table. If load balancing rules with virtual IP
- addresses (and ports) are configured in OVN_Northbound database for a
+ set, to the next table. If load balancing rules with virtual IP ad‐
+ dresses (and ports) are configured in OVN_Northbound database for a
logical switch datapath, a priority-100 flow is added with the match ip
to match on IP packets and sets the action reg0[2] = 1; next; to act as
a hint for table Pre-stateful to send IP packets to the connection
- tracker for packet de-fragmentation (and to possibly do DNAT for
- already established load balanced traffic) before eventually advancing
- to ingress table Stateful. If controller_event has been enabled and
- load balancing rules with empty backends have been added in OVN_North‐
- bound, a 130 flow is added to trigger ovn-controller events whenever
- the chassis receives a packet for that particular VIP. If event-elb
- meter has been previously created, it will be associated to the
- empty_lb logical flow
+ tracker for packet de-fragmentation (and to possibly do DNAT for al‐
+ ready established load balanced traffic) before eventually advancing to
+ ingress table Stateful. If controller_event has been enabled and load
+ balancing rules with empty backends have been added in OVN_Northbound,
+ a 130 flow is added to trigger ovn-controller events whenever the chas‐
+ sis receives a packet for that particular VIP. If event-elb meter has
+ been previously created, it will be associated to the empty_lb logical
+ flow
Prior to OVN 20.09 we were setting the reg0[0] = 1 only if the IP des‐
tination matches the load balancer VIP. However this had few issues
@@ -567,7 +557,7 @@
action. To understand the issue lets a take a TCP load balancer -
10.0.0.10:80=10.0.0.3:80. If a logical port - p1 with IP - 10.0.0.5
opens a TCP connection with the VIP - 10.0.0.10, then the packet in the
- ingress pipeline of ’p1’ is sent to the p1’s conntrack zone id and the
+ ingress pipeline of ’p1’ is sent to the p1’s conntrack zone id and the
packet is load balanced to the backend - 10.0.0.3. For the reply packet
from the backend lport, it is not sent to the conntrack of backend
lport’s zone id. This is fine as long as the packet is valid. Suppose
@@ -593,7 +583,7 @@
This table also has a priority-110 flow with the match inport == I for
all logical switch datapaths to move traffic to the next table. Where I
- is the peer of a logical router port. This flow is added to skip the
+ is the peer of a logical router port. This flow is added to skip the
connection tracking of packets which enter from logical router datapath
to logical switch datapath.
@@ -603,9 +593,9 @@
tables. It contains a priority-0 flow that simply moves traffic to the
next table.
- · Priority-120 flows that send the packets to connection
- tracker using ct_lb_mark; as the action so that the
- already established traffic destined to the load balancer
+ • Priority-120 flows that send the packets to connection
+ tracker using ct_lb_mark; as the action so that the al‐
+ ready established traffic destined to the load balancer
VIP gets DNATted. These flows match each VIPs IP and
port. For IPv4 traffic the flows also load the original
destination IP and transport port in registers reg1 and
@@ -613,227 +603,279 @@
destination IP and transport port in registers xxreg1 and
reg2.
- · A priority-110 flow sends the packets that don’t match
- the above flows to connection tracker based on a hint
+ • A priority-110 flow sends the packets that don’t match
+ the above flows to connection tracker based on a hint
provided by the previous tables (with a match for reg0[2]
== 1) by using the ct_lb_mark; action.
- · A priority-100 flow sends the packets to connection
+ • A priority-100 flow sends the packets to connection
tracker based on a hint provided by the previous tables
- (with a match for reg0[0] == 1) by using the ct_next;
- action.
+ (with a match for reg0[0] == 1) by using the ct_next; ac‐
+ tion.
Ingress Table 7: from-lport ACL hints
- This table consists of logical flows that set hints (reg0 bits) to be
- used in the next stage, in the ACL processing table, if stateful ACLs
- or load balancers are configured. Multiple hints can be set for the
+ This table consists of logical flows that set hints (reg0 bits) to be
+ used in the next stage, in the ACL processing table, if stateful ACLs
+ or load balancers are configured. Multiple hints can be set for the
same packet. The possible hints are:
- · reg0[7]: the packet might match an allow-related ACL and
+ • reg0[7]: the packet might match an allow-related ACL and
might have to commit the connection to conntrack.
- · reg0[8]: the packet might match an allow-related ACL but
- there will be no need to commit the connection to con‐
+ • reg0[8]: the packet might match an allow-related ACL but
+ there will be no need to commit the connection to con‐
ntrack because it already exists.
- · reg0[9]: the packet might match a drop/reject.
+ • reg0[9]: the packet might match a drop/reject.
- · reg0[10]: the packet might match a drop/reject ACL but
+ • reg0[10]: the packet might match a drop/reject ACL but
the connection was previously allowed so it might have to
be committed again with ct_label=1/1.
The table contains the following flows:
- · A priority-65535 flow to advance to the next table if the
+ • A priority-65535 flow to advance to the next table if the
logical switch has no ACLs configured, otherwise a prior‐
ity-0 flow to advance to the next table.
- · A priority-7 flow that matches on packets that initiate a
- new session. This flow sets reg0[7] and reg0[9] and then
+ • A priority-7 flow that matches on packets that initiate a
+ new session. This flow sets reg0[7] and reg0[9] and then
advances to the next table.
- · A priority-6 flow that matches on packets that are in the
+ • A priority-6 flow that matches on packets that are in the
request direction of an already existing session that has
- been marked as blocked. This flow sets reg0[7] and
+ been marked as blocked. This flow sets reg0[7] and
reg0[9] and then advances to the next table.
- · A priority-5 flow that matches untracked packets. This
- flow sets reg0[8] and reg0[9] and then advances to the
+ • A priority-5 flow that matches untracked packets. This
+ flow sets reg0[8] and reg0[9] and then advances to the
next table.
- · A priority-4 flow that matches on packets that are in the
+ • A priority-4 flow that matches on packets that are in the
request direction of an already existing session that has
- not been marked as blocked. This flow sets reg0[8] and
+ not been marked as blocked. This flow sets reg0[8] and
reg0[10] and then advances to the next table.
- · A priority-3 flow that matches on packets that are in not
+ • A priority-3 flow that matches on packets that are in not
part of established sessions. This flow sets reg0[9] and
then advances to the next table.
- · A priority-2 flow that matches on packets that are part
+ • A priority-2 flow that matches on packets that are part
of an established session that has been marked as
blocked. This flow sets reg0[9] and then advances to the
next table.
- · A priority-1 flow that matches on packets that are part
+ • A priority-1 flow that matches on packets that are part
of an established session that has not been marked as
blocked. This flow sets reg0[10] and then advances to the
next table.
- Ingress table 8: from-lport ACLs before LB
+ Ingress table 8: from-lport ACL evaluation before LB
Logical flows in this table closely reproduce those in the ACL table in
the OVN_Northbound database for the from-lport direction without the
option apply-after-lb set or set to false. The priority values from the
- ACL table have a limited range and have 1000 added to them to leave
+ ACL table have a limited range and have 1000 added to them to leave
room for OVN default flows at both higher and lower priorities.
- · allow ACLs translate into logical flows with the next;
- action. If there are any stateful ACLs on this datapath,
- then allow ACLs translate to ct_commit; next; (which acts
- as a hint for the next tables to commit the connection to
- conntrack). In case the ACL has a label then reg3 is
- loaded with the label value and reg0[13] bit is set to 1
- (which acts as a hint for the next tables to commit the
- label to conntrack).
-
- · allow-related ACLs translate into logical flows with the
- ct_commit(ct_label=0/1); next; actions for new connec‐
- tions and reg0[1] = 1; next; for existing connections. In
- case the ACL has a label then reg3 is loaded with the
- label value and reg0[13] bit is set to 1 (which acts as a
- hint for the next tables to commit the label to con‐
- ntrack).
-
- · allow-stateless ACLs translate into logical flows with
- the next; action.
-
- · reject ACLs translate into logical flows with the
- tcp_reset { output ->gt;>gt; inport; next(pipeline=egress,ta‐
- ble=5);} action for TCP connections,icmp4/icmp6 action
- for UDP connections, and sctp_abort {output -%gt;
- inport; next(pipeline=egress,table=5);} action for SCTP
- associations.
-
- · Other ACLs translate to drop; for new or untracked con‐
- nections and ct_commit(ct_label=1/1); for known connec‐
- tions. Setting ct_label marks a connection as one that
- was previously allowed, but should no longer be allowed
- due to a policy change.
-
- This table contains a priority-65535 flow to advance to the next table
- if the logical switch has no ACLs configured, otherwise a priority-0
- flow to advance to the next table so that ACLs allow packets by default
- if options:default_acl_drop column of NB_Global is false or not set.
- Otherwise the flow action is set to drop; to implement a default drop
- behavior.
-
- If the logical datapath has a stateful ACL or a load balancer with VIP
- configured, the following flows will also be added:
-
- · If options:default_acl_drop column of NB_Global is false
- or not set, a priority-1 flow that sets the hint to com‐
- mit IP traffic that is not part of established sessions
- to the connection tracker (with action reg0[1] = 1;
- next;). This is needed for the default allow policy
- because, while the initiator’s direction may not have any
- stateful rules, the server’s may and then its return
- traffic would not be known and marked as invalid.
+ • This table is responsible for evaluating ACLs, and set‐
+ ting a register bit to indicate whether the ACL decided
+ to allow, drop, or reject the traffic. The allow bit is
+ reg8[16]. The drop bit is reg8[17]. All flows in this ta‐
+ ble will advance the packet to the next table, where the
+ bits from before are evaluated to determine what to do
+ with the packet. Any flows in this table that intend for
+ the packet to pass will set reg8[16] to 1, even if an ACL
+ with an allow-type action was not matched. This lets the
+ next table know to allow the traffic to pass. These bits
+ will be referred to as the "allow", "drop", and "reject"
+ bits in the upcoming paragraphs.
+
+ • If the tier column has been configured on the ACL, then
+ OVN will also match the current tier counter against the
+ configured ACL tier. OVN keeps count of the current tier
+ in reg8[30..31].
+
+ • allow ACLs translate into logical flows that set the al‐
+ low bit to 1 and advance the packet to the next table. If
+ there are any stateful ACLs on this datapath, then allow
+ ACLs set the allow bit to one and in addition perform
+ ct_commit; (which acts as a hint for future tables to
+ commit the connection to conntrack). In case the ACL has
+ a label then reg3 is loaded with the label value and
+ reg0[13] bit is set to 1 (which acts as a hint for the
+ next tables to commit the label to conntrack).
+
+ • allow-related ACLs translate into logical flows that set
+ the allow bit and additionally have ct_commit(ct_la‐‐
+ bel=0/1); next; actions for new connections and reg0[1] =
+ 1; next; for existing connections. In case the ACL has a
+ label then reg3 is loaded with the label value and
+ reg0[13] bit is set to 1 (which acts as a hint for the
+ next tables to commit the label to conntrack).
+
+ • allow-stateless ACLs translate into logical flows that
+ set the allow bit and advance to the next table.
+
+ • reject ACLs translate into logical flows with that set
+ the reject bit and advance to the next table.
+
+ • pass ACLs translate into logical flows that do not set
+ the allow, drop, or reject bit and advance to the next
+ table.
- · If options:default_acl_drop column of NB_Global is true,
- a priority-1 flow that drops IP traffic that is not part
- of established sessions.
+ • Other ACLs set the drop bit and advance to the next table
+ for new or untracked connections. For known connections,
+ they set the drop bit, as well as running the ct_com‐‐
+ mit(ct_label=1/1); action. Setting ct_label marks a con‐
+ nection as one that was previously allowed, but should no
+ longer be allowed due to a policy change.
+
+ This table contains a priority-65535 flow to set the allow bit and ad‐
+ vance to the next table if the logical switch has no ACLs configured,
+ otherwise a priority-0 flow to advance to the next table is added. This
+ flow does not set the allow bit, so that the next table can decide
+ whether to allow or drop the packet based on the value of the op‐‐
+ tions:default_acl_drop column of the NB_Global table.
+
+ A priority-65532 flow is added that sets the allow bit for IPv6 Neigh‐
+ bor solicitation, Neighbor discover, Router solicitation, Router adver‐
+ tisement and MLD packets regardless of other ACLs defined.
+
+ If the logical datapath has a stateful ACL or a load balancer with VIP
+ configured, the following flows will also be added:
- · A priority-1 flow that sets the hint to commit IP traffic
+ • If options:default_acl_drop column of NB_Global is false
+ or not set, a priority-1 flow that sets the hint to com‐
+ mit IP traffic that is not part of established sessions
to the connection tracker (with action reg0[1] = 1;
- next;). This is needed for the default allow policy
- because, while the initiator’s direction may not have any
+ next;). This is needed for the default allow policy be‐
+ cause, while the initiator’s direction may not have any
stateful rules, the server’s may and then its return
traffic would not be known and marked as invalid.
- · A priority-65532 flow that allows any traffic in the
- reply direction for a connection that has been committed
- to the connection tracker (i.e., established flows), as
- long as the committed flow does not have ct_mark.blocked
- set. We only handle traffic in the reply direction here
- because we want all packets going in the request direc‐
- tion to still go through the flows that implement the
- currently defined policy based on ACLs. If a connection
- is no longer allowed by policy, ct_mark.blocked will get
- set and packets in the reply direction will no longer be
- allowed, either. This flow also clears the register bits
- reg0[9] and reg0[10]. If ACL logging and logging of
- related packets is enabled, then a companion prior‐
- ity-65533 flow will be installed that accomplishes the
- same thing but also logs the traffic.
-
- · A priority-65532 flow that allows any traffic that is
- considered related to a committed flow in the connection
- tracker (e.g., an ICMP Port Unreachable from a non-lis‐
- tening UDP port), as long as the committed flow does not
- have ct_mark.blocked set. This flow also applies NAT to
- the related traffic so that ICMP headers and the inner
- packet have correct addresses. If ACL logging and logging
- of related packets is enabled, then a companion prior‐
- ity-65533 flow will be installed that accomplishes the
- same thing but also logs the traffic.
-
- · A priority-65532 flow that drops all traffic marked by
- the connection tracker as invalid.
-
- · A priority-65532 flow that drops all traffic in the reply
- direction with ct_mark.blocked set meaning that the con‐
- nection should no longer be allowed due to a policy
- change. Packets in the request direction are skipped here
- to let a newly created ACL re-allow this connection.
-
- · A priority-65532 flow that allows IPv6 Neighbor solicita‐
- tion, Neighbor discover, Router solicitation, Router
- advertisement and MLD packets.
+ • A priority-1 flow that sets the allow bit and sets the
+ hint to commit IP traffic to the connection tracker (with
+ action reg0[1] = 1; next;). This is needed for the de‐
+ fault allow policy because, while the initiator’s direc‐
+ tion may not have any stateful rules, the server’s may
+ and then its return traffic would not be known and marked
+ as invalid.
+
+ • A priority-65532 flow that sets the allow bit for any
+ traffic in the reply direction for a connection that has
+ been committed to the connection tracker (i.e., estab‐
+ lished flows), as long as the committed flow does not
+ have ct_mark.blocked set. We only handle traffic in the
+ reply direction here because we want all packets going in
+ the request direction to still go through the flows that
+ implement the currently defined policy based on ACLs. If
+ a connection is no longer allowed by policy,
+ ct_mark.blocked will get set and packets in the reply di‐
+ rection will no longer be allowed, either. This flow also
+ clears the register bits reg0[9] and reg0[10] and sets
+ register bit reg0[17]. If ACL logging and logging of re‐
+ lated packets is enabled, then a companion priority-65533
+ flow will be installed that accomplishes the same thing
+ but also logs the traffic.
+
+ • A priority-65532 flow that sets the allow bit for any
+ traffic that is considered related to a committed flow in
+ the connection tracker (e.g., an ICMP Port Unreachable
+ from a non-listening UDP port), as long as the committed
+ flow does not have ct_mark.blocked set. This flow also
+ applies NAT to the related traffic so that ICMP headers
+ and the inner packet have correct addresses. If ACL log‐
+ ging and logging of related packets is enabled, then a
+ companion priority-65533 flow will be installed that ac‐
+ complishes the same thing but also logs the traffic.
+
+ • A priority-65532 flow that sets the drop bit for all
+ traffic marked by the connection tracker as invalid.
+
+ • A priority-65532 flow that sets the drop bit for all
+ traffic in the reply direction with ct_mark.blocked set
+ meaning that the connection should no longer be allowed
+ due to a policy change. Packets in the request direction
+ are skipped here to let a newly created ACL re-allow this
+ connection.
If the logical datapath has any ACL or a load balancer with VIP config‐
ured, the following flow will also be added:
- · A priority 34000 logical flow is added for each logical
- switch datapath with the match eth.dst = E to allow the
- service monitor reply packet destined to ovn-controller
- with the action next, where E is the service monitor mac
- defined in the options:svc_monitor_mac column of
+ • A priority 34000 logical flow is added for each logical
+ switch datapath with the match eth.dst = E to allow the
+ service monitor reply packet destined to ovn-controller
+ that sets the allow bit, where E is the service monitor
+ mac defined in the options:svc_monitor_mac column of
NB_Global table.
- Ingress Table 9: from-lport QoS Marking
+ Ingress Table 9: from-lport ACL action
+
+ Logical flows in this table decide how to proceed based on the values
+ of the allow, drop, and reject bits that may have been set in the pre‐
+ vious table.
+
+ • If no ACLs are configured, then a priority 0 flow is in‐
+ stalled that matches everything and advances to the next
+ table.
+
+ • A priority 1000 flow is installed that will advance the
+ packet to the next table if the allow bit is set.
+
+ • A priority 1000 flow is installed that will run the drop;
+ action if the drop bit is set.
+
+ • A priority 1000 flow is installed that will run the
+ tcp_reset { output ->gt;>gt; inport; next(pipeline=egress,ta‐‐
+ ble=5);} action for TCP connections,icmp4/icmp6 action
+ for UDP connections, and sctp_abort {output -%gt; in‐‐
+ port; next(pipeline=egress,table=5);} action for SCTP as‐
+ sociations.
+
+ • If any ACLs have tiers configured on them, then three
+ priority 500 flows are installed. If the current tier
+ counter is 0, 1, or 2, then the current tier counter is
+ incremented by one and the packet is sent back to the
+ previous table for re-evaluation.
+
+ Ingress Table 10: from-lport QoS Marking
Logical flows in this table closely reproduce those in the QoS table
with the action column set in the OVN_Northbound database for the
from-lport direction.
- · For every qos_rules entry in a logical switch with DSCP
+ • For every qos_rules entry in a logical switch with DSCP
marking enabled, a flow will be added at the priority
mentioned in the QoS table.
- · One priority-0 fallback flow that matches all packets and
+ • For every qos_rules entry in a logical switch with packet
+ marking enabled, a flow will be added at the priority
+ mentioned in the QoS table.
+
+ • One priority-0 fallback flow that matches all packets and
advances to the next table.
- Ingress Table 10: from-lport QoS Meter
+ Ingress Table 11: from-lport QoS Meter
Logical flows in this table closely reproduce those in the QoS table
with the bandwidth column set in the OVN_Northbound database for the
from-lport direction.
- · For every qos_rules entry in a logical switch with meter‐
- ing enabled, a flow will be added at the priority men‐
+ • For every qos_rules entry in a logical switch with meter‐
+ ing enabled, a flow will be added at the priority men‐
tioned in the QoS table.
- · One priority-0 fallback flow that matches all packets and
+ • One priority-0 fallback flow that matches all packets and
advances to the next table.
- Ingress Table 11: Load balancing affinity check
+ Ingress Table 12: Load balancing affinity check
Load balancing affinity check table contains the following logical
flows:
- · For all the configured load balancing rules for a switch
+ • For all the configured load balancing rules for a switch
in OVN_Northbound database where a positive affinity
timeout is specified in options column, that includes a
L4 port PORT of protocol P and IP address VIP, a prior‐
@@ -843,26 +885,26 @@
&&&& P.dst == PORT. The flow’s action is reg9[6] =
chk_lb_aff(); next;.
- · A priority 0 flow is added which matches on all packets
+ • A priority 0 flow is added which matches on all packets
and applies the action next;.
- Ingress Table 12: LB
+ Ingress Table 13: LB
- · For all the configured load balancing rules for a switch
+ • For all the configured load balancing rules for a switch
in OVN_Northbound database where a positive affinity
timeout is specified in options column, that includes a
L4 port PORT of protocol P and IP address VIP, a prior‐
ity-150 flow is added. For IPv4 VIPs, the flow matches
reg9[6] == 1 &&&& ct.new &&&& ip &&&& ip4.dst == VIP &&&& P.dst
== PORT . For IPv6 VIPs, the flow matches reg9[6] == 1 &&&&
- ct.new &&&& ip &&&& ip6.dst == VIP &&&& P &&&& P.dst == PORT.
- The flow’s action is ct_lb_mark(args), where args con‐
- tains comma separated IP addresses (and optional port
+ ct.new &&&& ip &&&& ip6.dst == VIP &&&& P &&&& P.dst == PORT.
+ The flow’s action is ct_lb_mark(args), where args con‐
+ tains comma separated IP addresses (and optional port
numbers) to load balance to. The address family of the IP
addresses of args is the same as the address family of
VIP.
- · For all the configured load balancing rules for a switch
+ • For all the configured load balancing rules for a switch
in OVN_Northbound database that includes a L4 port PORT
of protocol P and IP address VIP, a priority-120 flow is
added. For IPv4 VIPs , the flow matches ct.new &&&& ip &&&&
@@ -871,7 +913,7 @@
PORT. The flow’s action is ct_lb_mark(args) , where args
contains comma separated IP addresses (and optional port
numbers) to load balance to. The address family of the IP
- addresses of args is the same as the address family of
+ addresses of args is the same as the address family of
VIP. If health check is enabled, then args will only con‐
tain those endpoints whose service monitor status entry
in OVN_Southbound db is either online or empty. For IPv4
@@ -879,43 +921,43 @@
and transport port in registers reg1 and reg2. For IPv6
traffic the flow also loads the original destination IP
and transport port in registers xxreg1 and reg2. The
- above flow is created even if the load balancer is
- attached to a logical router connected to the current
- logical switch and the install_ls_lb_from_router variable
- in options is set to true.
-
- · For all the configured load balancing rules for a switch
- in OVN_Northbound database that includes just an IP
- address VIP to match on, OVN adds a priority-110 flow.
- For IPv4 VIPs, the flow matches ct.new &&&& ip &&&& ip4.dst
- == VIP. For IPv6 VIPs, the flow matches ct.new &&&& ip &&&&
- ip6.dst == VIP. The action on this flow is
- ct_lb_mark(args), where args contains comma separated IP
- addresses of the same address family as VIP. For IPv4
- traffic the flow also loads the original destination IP
- and transport port in registers reg1 and reg2. For IPv6
- traffic the flow also loads the original destination IP
- and transport port in registers xxreg1 and reg2. The
- above flow is created even if the load balancer is
- attached to a logical router connected to the current
- logical switch and the install_ls_lb_from_router variable
- in options is set to true.
-
- · If the load balancer is created with --reject option and
+ above flow is created even if the load balancer is at‐
+ tached to a logical router connected to the current logi‐
+ cal switch and the install_ls_lb_from_router variable in
+ options is set to true.
+
+ • For all the configured load balancing rules for a switch
+ in OVN_Northbound database that includes just an IP ad‐
+ dress VIP to match on, OVN adds a priority-110 flow. For
+ IPv4 VIPs, the flow matches ct.new &&&& ip &&&& ip4.dst ==
+ VIP. For IPv6 VIPs, the flow matches ct.new &&&& ip &&&&
+ ip6.dst == VIP. The action on this flow is
+ ct_lb_mark(args), where args contains comma separated IP
+ addresses of the same address family as VIP. For IPv4
+ traffic the flow also loads the original destination IP
+ and transport port in registers reg1 and reg2. For IPv6
+ traffic the flow also loads the original destination IP
+ and transport port in registers xxreg1 and reg2. The
+ above flow is created even if the load balancer is at‐
+ tached to a logical router connected to the current logi‐
+ cal switch and the install_ls_lb_from_router variable in
+ options is set to true.
+
+ • If the load balancer is created with --reject option and
it has no active backends, a TCP reset segment (for tcp)
or an ICMP port unreachable packet (for all other kind of
- traffic) will be sent whenever an incoming packet is
- received for this load-balancer. Please note using
- --reject option will disable empty_lb SB controller event
- for this load balancer.
+ traffic) will be sent whenever an incoming packet is re‐
+ ceived for this load-balancer. Please note using --reject
+ option will disable empty_lb SB controller event for this
+ load balancer.
- Ingress Table 13: Load balancing affinity learn
+ Ingress Table 14: Load balancing affinity learn
- Load balancing affinity learn table contains the following logical
+ Load balancing affinity learn table contains the following logical
flows:
- · For all the configured load balancing rules for a switch
- in OVN_Northbound database where a positive affinity
+ • For all the configured load balancing rules for a switch
+ in OVN_Northbound database where a positive affinity
timeout T is specified in options column, that includes a
L4 port PORT of protocol P and IP address VIP, a prior‐
ity-100 flow is added. For IPv4 VIPs, the flow matches
@@ -925,74 +967,12 @@
is commit_lb_aff(vip = VIP:PORT, backend = backend ip:
backend port, proto = P, timeout = T); .
- · A priority 0 flow is added which matches on all packets
+ • A priority 0 flow is added which matches on all packets
and applies the action next;.
- Ingress table 14: from-lport ACLs after LB
-
- Logical flows in this table closely reproduce those in the ACL table in
- the OVN_Northbound database for the from-lport direction with the
- option apply-after-lb set to true. The priority values from the ACL ta‐
- ble have a limited range and have 1000 added to them to leave room for
- OVN default flows at both higher and lower priorities.
+ Ingress Table 15: Pre-Hairpin
- · allow apply-after-lb ACLs translate into logical flows
- with the next; action. If there are any stateful ACLs
- (including both before-lb and after-lb ACLs) on this
- datapath, then allow ACLs translate to ct_commit; next;
- (which acts as a hint for the next tables to commit the
- connection to conntrack). In case the ACL has a label
- then reg3 is loaded with the label value and reg0[13] bit
- is set to 1 (which acts as a hint for the next tables to
- commit the label to conntrack).
-
- · allow-related apply-after-lb ACLs translate into logical
- flows with the ct_commit(ct_label=0/1); next; actions for
- new connections and reg0[1] = 1; next; for existing con‐
- nections. In case the ACL has a label then reg3 is loaded
- with the label value and reg0[13] bit is set to 1 (which
- acts as a hint for the next tables to commit the label to
- conntrack).
-
- · allow-stateless apply-after-lb ACLs translate into logi‐
- cal flows with the next; action.
-
- · reject apply-after-lb ACLs translate into logical flows
- with the tcp_reset { output ->gt;>gt; inport; next(pipe‐
- line=egress,table=5);} action for TCP connec‐
- tions,icmp4/icmp6 action for UDP connections, and
- sctp_abort {output -%gt; inport; next(pipe‐
- line=egress,table=5);} action for SCTP associations.
-
- · Other apply-after-lb ACLs translate to drop; for new or
- untracked connections and ct_commit(ct_label=1/1); for
- known connections. Setting ct_label marks a connection as
- one that was previously allowed, but should no longer be
- allowed due to a policy change.
-
- · One priority-0 fallback flow that matches all packets and
- advances to the next table.
-
- Ingress Table 15: Stateful
-
- · A priority 100 flow is added which commits the packet to
- the conntrack and sets the most significant 32-bits of
- ct_label with the reg3 value based on the hint provided
- by previous tables (with a match for reg0[1] == 1 &&&&
- reg0[13] == 1). This is used by the ACLs with label to
- commit the label value to conntrack.
-
- · For ACLs without label, a second priority-100 flow com‐
- mits packets to connection tracker using ct_commit; next;
- action based on a hint provided by the previous tables
- (with a match for reg0[1] == 1 &&&& reg0[13] == 0).
-
- · A priority-0 flow that simply moves traffic to the next
- table.
-
- Ingress Table 16: Pre-Hairpin
-
- · If the logical switch has load balancer(s) configured,
+ • If the logical switch has load balancer(s) configured,
then a priority-100 flow is added with the match ip &&&&
ct.trk to check if the packet needs to be hairpinned (if
after load balancing the destination IP matches the
@@ -1000,61 +980,173 @@
chk_lb_hairpin(); and reg0[12] = chk_lb_hairpin_reply();
and advances the packet to the next table.
- · A priority-0 flow that simply moves traffic to the next
+ • A priority-0 flow that simply moves traffic to the next
table.
- Ingress Table 17: Nat-Hairpin
+ Ingress Table 16: Nat-Hairpin
- · If the logical switch has load balancer(s) configured,
+ • If the logical switch has load balancer(s) configured,
then a priority-100 flow is added with the match ip &&&&
ct.new &&&& ct.trk &&&& reg0[6] == 1 which hairpins the traf‐
fic by NATting source IP to the load balancer VIP by exe‐
cuting the action ct_snat_to_vip and advances the packet
to the next table.
- · If the logical switch has load balancer(s) configured,
+ • If the logical switch has load balancer(s) configured,
then a priority-100 flow is added with the match ip &&&&
ct.est &&&& ct.trk &&&& reg0[6] == 1 which hairpins the traf‐
fic by NATting source IP to the load balancer VIP by exe‐
cuting the action ct_snat and advances the packet to the
next table.
- · If the logical switch has load balancer(s) configured,
+ • If the logical switch has load balancer(s) configured,
then a priority-90 flow is added with the match ip &&&&
reg0[12] == 1 which matches on the replies of hairpinned
traffic (i.e., destination IP is VIP, source IP is the
backend IP and source L4 port is backend port for L4 load
- balancers) and executes ct_snat and advances the packet
+ balancers) and executes ct_snat and advances the packet
to the next table.
- · A priority-0 flow that simply moves traffic to the next
+ • A priority-0 flow that simply moves traffic to the next
table.
- Ingress Table 18: Hairpin
+ Ingress Table 17: Hairpin
+
+ • If logical switch has attached logical switch port of
+ vtep type, then for each distributed gateway router port
+ RP attached to this logical switch and has chassis redi‐
+ rect port cr-RP, a priority-2000 flow is added with the
+ match .IP
+ reg0[14] == 1 &&&& is_chassis_resident(cr-RP)
- · For each distributed gateway router port RP attached to
- the logical switch, a priority-2000 flow is added with
- the match reg0[14] == 1 &&&& is_chassis_resident(RP)
- and action next; to pass the traffic to the next table
- to respond to the ARP requests for the router port IPs.
+ and action next;.
reg0[14] register bit is set in the ingress L2 port secu‐
rity check table for traffic received from HW VTEP (ramp)
ports.
- · A priority-1000 flow that matches on reg0[14] register
- bit for the traffic received from HW VTEP (ramp) ports.
- This traffic is passed to ingress table ls_in_l2_lkup.
+ • If logical switch has attached logical switch port of
+ vtep type, then a priority-1000 flow that matches on
+ reg0[14] register bit for the traffic received from HW
+ VTEP (ramp) ports. This traffic is passed to ingress ta‐
+ ble ls_in_l2_lkup.
- · A priority-1 flow that hairpins traffic matched by non-
+ • A priority-1 flow that hairpins traffic matched by non-
default flows in the Pre-Hairpin table. Hairpinning is
done at L2, Ethernet addresses are swapped and the pack‐
ets are looped back on the input port.
- · A priority-0 flow that simply moves traffic to the next
+ • A priority-0 flow that simply moves traffic to the next
+ table.
+
+ Ingress table 18: from-lport ACL evaluation after LB
+
+ Logical flows in this table closely reproduce those in the ACL eval ta‐
+ ble in the OVN_Northbound database for the from-lport direction with
+ the option apply-after-lb set to true. The priority values from the ACL
+ table have a limited range and have 1000 added to them to leave room
+ for OVN default flows at both higher and lower priorities. The flows in
+ this table indicate the ACL verdict by setting reg8[16] for allow-type
+ ACLs, reg8[17] for drop ACLs, and reg8[17] for reject ACLs, and then
+ advancing the packet to the next table. These will be reffered to as
+ the allow bit, drop bit, and reject bit throughout the documentation
+ for this table and the next one.
+
+ Like with ACLs that are evaluated before load balancers, if the ACL is
+ configured with a tier value, then the current tier counter, supplied
+ in reg8[30..31] is matched against the ACL’s configured tier in addi‐
+ tion to the ACL’s match.
+
+ • allow apply-after-lb ACLs translate into logical flows
+ that set the allow bit. If there are any stateful ACLs
+ (including both before-lb and after-lb ACLs) on this
+ datapath, then allow ACLs also run ct_commit; next;
+ (which acts as a hint for an upcoming table to commit the
+ connection to conntrack). In case the ACL has a label
+ then reg3 is loaded with the label value and reg0[13] bit
+ is set to 1 (which acts as a hint for the next tables to
+ commit the label to conntrack).
+
+ • allow-related apply-after-lb ACLs translate into logical
+ flows that set the allow bit and run the ct_commit(ct_la‐‐
+ bel=0/1); next; actions for new connections and reg0[1] =
+ 1; next; for existing connections. In case the ACL has a
+ label then reg3 is loaded with the label value and
+ reg0[13] bit is set to 1 (which acts as a hint for the
+ next tables to commit the label to conntrack).
+
+ • allow-stateless apply-after-lb ACLs translate into logi‐
+ cal flows that set the allow bit and advance to the next
+ table.
+
+ • reject apply-after-lb ACLs translate into logical flows
+ that set the reject bit and advance to the next table.
+
+ • pass apply-after-lb ACLs translate into logical flows
+ that do not set the allow, drop, or reject bit and ad‐
+ vance to the next table.
+
+ • Other apply-after-lb ACLs set the drop bit for new or un‐
+ tracked connections and ct_commit(ct_label=1/1); for
+ known connections. Setting ct_label marks a connection as
+ one that was previously allowed, but should no longer be
+ allowed due to a policy change.
+
+ • One priority-65532 flow matching packets with reg0[17]
+ set (either replies to existing sessions or traffic re‐
+ lated to existing sessions) and allows these by setting
+ the allow bit and advancing to the next table.
+
+ • One priority-0 fallback flow that matches all packets and
+ advances to the next table.
+
+ Ingress Table 19: from-lport ACL action after LB
+
+ Logical flows in this table decide how to proceed based on the values
+ of the allow, drop, and reject bits that may have been set in the pre‐
+ vious table.
+
+ • If no ACLs are configured, then a priority 0 flow is in‐
+ stalled that matches everything and advances to the next
+ table.
+
+ • A priority 1000 flow is installed that will advance the
+ packet to the next table if the allow bit is set.
+
+ • A priority 1000 flow is installed that will run the drop;
+ action if the drop bit is set.
+
+ • A priority 1000 flow is installed that will run the
+ tcp_reset { output ->gt;>gt; inport; next(pipeline=egress,ta‐‐
+ ble=5);} action for TCP connections,icmp4/icmp6 action
+ for UDP connections, and sctp_abort {output -%gt; in‐‐
+ port; next(pipeline=egress,table=5);} action for SCTP as‐
+ sociations.
+
+ • If any ACLs have tiers configured on them, then three
+ priority 500 flows are installed. If the current tier
+ counter is 0, 1, or 2, then the current tier counter is
+ incremented by one and the packet is sent back to the
+ previous table for re-evaluation.
+
+ Ingress Table 20: Stateful
+
+ • A priority 100 flow is added which commits the packet to
+ the conntrack and sets the most significant 32-bits of
+ ct_label with the reg3 value based on the hint provided
+ by previous tables (with a match for reg0[1] == 1 &&&&
+ reg0[13] == 1). This is used by the ACLs with label to
+ commit the label value to conntrack.
+
+ • For ACLs without label, a second priority-100 flow com‐
+ mits packets to connection tracker using ct_commit; next;
+ action based on a hint provided by the previous tables
+ (with a match for reg0[1] == 1 &&&& reg0[13] == 0).
+
+ • A priority-0 flow that simply moves traffic to the next
table.
- Ingress Table 19: ARP/ND responder
+ Ingress Table 21: ARP/ND responder
This table implements ARP/ND responder in a logical switch for known
IPs. The advantage of the ARP responder flow is to limit ARP broadcasts
@@ -1064,54 +1156,61 @@
visor rather than broadcast across the whole network and responded to
by the destination VM. This behavior is proxy ARP.
- ARP requests arrive from VMs from a logical switch inport of type
- default. For this case, the logical switch proxy ARP rules can be for
+ ARP requests arrive from VMs from a logical switch inport of type de‐
+ fault. For this case, the logical switch proxy ARP rules can be for
other VMs or logical router ports. Logical switch proxy ARP rules may
be programmed both for mac binding of IP addresses on other logical
switch VIF ports (which are of the default logical switch port type,
representing connectivity to VMs or containers), and for mac binding of
- IP addresses on logical switch router type ports, representing their
- logical router port peers. In order to support proxy ARP for logical
- router ports, an IP address must be configured on the logical switch
- router type port, with the same value as the peer logical router port.
+ IP addresses on logical switch router type ports, representing their
+ logical router port peers. In order to support proxy ARP for logical
+ router ports, an IP address must be configured on the logical switch
+ router type port, with the same value as the peer logical router port.
The configured MAC addresses must match as well. When a VM sends an ARP
request for a distributed logical router port and if the peer router
type port of the attached logical switch does not have an IP address
configured, the ARP request will be broadcast on the logical switch.
One of the copies of the ARP request will go through the logical switch
- router type port to the logical router datapath, where the logical
- router ARP responder will generate a reply. The MAC binding of a dis‐
- tributed logical router, once learned by an associated VM, is used for
- all that VM’s communication needing routing. Hence, the action of a VM
- re-arping for the mac binding of the logical router port should be
+ router type port to the logical router datapath, where the logical
+ router ARP responder will generate a reply. The MAC binding of a dis‐
+ tributed logical router, once learned by an associated VM, is used for
+ all that VM’s communication needing routing. Hence, the action of a VM
+ re-arping for the mac binding of the logical router port should be
rare.
- Logical switch ARP responder proxy ARP rules can also be hit when
- receiving ARP requests externally on a L2 gateway port. In this case,
- the hypervisor acting as an L2 gateway, responds to the ARP request on
- behalf of a destination VM.
+ Logical switch ARP responder proxy ARP rules can also be hit when re‐
+ ceiving ARP requests externally on a L2 gateway port. In this case, the
+ hypervisor acting as an L2 gateway, responds to the ARP request on be‐
+ half of a destination VM.
- Note that ARP requests received from localnet logical inports can
- either go directly to VMs, in which case the VM responds or can hit an
- ARP responder for a logical router port if the packet is used to
- resolve a logical router port next hop address. In either case, logical
+ Note that ARP requests received from localnet logical inports can ei‐
+ ther go directly to VMs, in which case the VM responds or can hit an
+ ARP responder for a logical router port if the packet is used to re‐
+ solve a logical router port next hop address. In either case, logical
switch ARP responder rules will not be hit. It contains these logical
flows:
- · Priority-100 flows to skip the ARP responder if inport is
- of type localnet advances directly to the next table. ARP
- requests sent to localnet ports can be received by multi‐
- ple hypervisors. Now, because the same mac binding rules
- are downloaded to all hypervisors, each of the multiple
- hypervisors will respond. This will confuse L2 learning
- on the source of the ARP requests. ARP requests received
- on an inport of type router are not expected to hit any
- logical switch ARP responder flows. However, no skip
- flows are installed for these packets, as there would be
- some additional flow cost for this and the value appears
- limited.
-
- · If inport V is of type virtual adds a priority-100 logi‐
+ • If packet was received from HW VTEP (ramp switch), and
+ this packet is ARP or Neighbor Solicitation, such packet
+ is passed to next table with max proirity. ARP/ND re‐
+ quests from HW VTEP must be handled in logical router
+ ingress pipeline.
+
+ • If the logical switch has no router ports with op‐
+ tions:arp_proxy configured add a priority-100 flows to
+ skip the ARP responder if inport is of type localnet ad‐
+ vances directly to the next table. ARP requests sent to
+ localnet ports can be received by multiple hypervisors.
+ Now, because the same mac binding rules are downloaded to
+ all hypervisors, each of the multiple hypervisors will
+ respond. This will confuse L2 learning on the source of
+ the ARP requests. ARP requests received on an inport of
+ type router are not expected to hit any logical switch
+ ARP responder flows. However, no skip flows are installed
+ for these packets, as there would be some additional flow
+ cost for this and the value appears limited.
+
+ • If inport V is of type virtual adds a priority-100 logi‐
cal flows for each P configured in the options:virtual-
parents column with the match
@@ -1126,14 +1225,14 @@
and advances the packet to the next table.
- Where VIP is the virtual ip configured in the column
- options:virtual-ip and NS_MULTICAST_ADDR is solicited-
- node multicast address corresponding to the VIP.
+ Where VIP is the virtual ip configured in the column op‐‐
+ tions:virtual-ip and NS_MULTICAST_ADDR is solicited-node
+ multicast address corresponding to the VIP.
- · Priority-50 flows that match ARP requests to each known
+ • Priority-50 flows that match ARP requests to each known
IP address A of every logical switch port, and respond
- with ARP replies directly with corresponding Ethernet
- address E:
+ with ARP replies directly with corresponding Ethernet ad‐
+ dress E:
eth.dst = eth.src;
eth.src = E;
@@ -1147,12 +1246,12 @@
output;
- These flows are omitted for logical ports (other than
- router ports or localport ports) that are down (unless
- ignore_lsp_down is configured as true in options column
+ These flows are omitted for logical ports (other than
+ router ports or localport ports) that are down (unless
+ ignore_lsp_down is configured as true in options column
of NB_Global table of the Northbound database), for logi‐
- cal ports of type virtual, for logical ports with
- ’unknown’ address set and for logical ports of a logical
+ cal ports of type virtual, for logical ports with ’un‐
+ known’ address set and for logical ports of a logical
switch configured with other_config:vlan-passthru=true.
The above ARP responder flows are added for the list of
@@ -1160,7 +1259,7 @@
Logical_Switch_Port table for logical switch ports of
type router.
- · Priority-50 flows that match IPv6 ND neighbor solicita‐
+ • Priority-50 flows that match IPv6 ND neighbor solicita‐
tions to each known IP address A (and A’s solicited node
address) of every logical switch port except of type
router, and respond with neighbor advertisements directly
@@ -1177,10 +1276,10 @@
};
- Priority-50 flows that match IPv6 ND neighbor solicita‐
- tions to each known IP address A (and A’s solicited node
- address) of logical switch port of type router, and
- respond with neighbor advertisements directly with corre‐
+ Priority-50 flows that match IPv6 ND neighbor solicita‐
+ tions to each known IP address A (and A’s solicited node
+ address) of logical switch port of type router, and re‐
+ spond with neighbor advertisements directly with corre‐
sponding Ethernet address E:
nd_na_router {
@@ -1194,35 +1293,40 @@
};
- These flows are omitted for logical ports (other than
- router ports or localport ports) that are down (unless
- ignore_lsp_down is configured as true in options column
+ These flows are omitted for logical ports (other than
+ router ports or localport ports) that are down (unless
+ ignore_lsp_down is configured as true in options column
of NB_Global table of the Northbound database), for logi‐
- cal ports of type virtual and for logical ports with
- ’unknown’ address set.
+ cal ports of type virtual and for logical ports with ’un‐
+ known’ address set.
+
+ The above NDP responder flows are added for the list of
+ IPv6 addresses if defined in options:arp_proxy column of
+ Logical_Switch_Port table for logical switch ports of
+ type router.
- · Priority-100 flows with match criteria like the ARP and
+ • Priority-100 flows with match criteria like the ARP and
ND flows above, except that they only match packets from
the inport that owns the IP addresses in question, with
action next;. These flows prevent OVN from replying to,
for example, an ARP request emitted by a VM for its own
- IP address. A VM only makes this kind of request to
- attempt to detect a duplicate IP address assignment, so
+ IP address. A VM only makes this kind of request to at‐
+ tempt to detect a duplicate IP address assignment, so
sending a reply will prevent the VM from accepting the IP
address that it owns.
- In place of next;, it would be reasonable to use drop;
+ In place of next;, it would be reasonable to use drop;
for the flows’ actions. If everything is working as it is
configured, then this would produce equivalent results,
since no host should reply to the request. But ARPing for
- one’s own IP address is intended to detect situations
- where the network is not working as configured, so drop‐
+ one’s own IP address is intended to detect situations
+ where the network is not working as configured, so drop‐
ping the request would frustrate that intent.
- · For each SVC_MON_SRC_IP defined in the value of the
- ip_port_mappings:ENDPOINT_IP column of Load_Balancer ta‐
- ble, priority-110 logical flow is added with the match
- arp.tpa == SVC_MON_SRC_IP &&&& &&&& arp.op == 1 and applies
+ • For each SVC_MON_SRC_IP defined in the value of the
+ ip_port_mappings:ENDPOINT_IP column of Load_Balancer ta‐
+ ble, priority-110 logical flow is added with the match
+ arp.tpa == SVC_MON_SRC_IP &&&& &&&& arp.op == 1 and applies
the action
eth.dst = eth.src;
@@ -1237,8 +1341,8 @@
output;
- where E is the service monitor source mac defined in the
- options:svc_monitor_mac column in the NB_Global table.
+ where E is the service monitor source mac defined in the
+ options:svc_monitor_mac column in the NB_Global table.
This mac is used as the source mac in the service monitor
packets for the load balancer endpoint IP health checks.
@@ -1249,7 +1353,22 @@
These flows are required if an ARP request is sent for
the IP SVC_MON_SRC_IP.
- · For each VIP configured in the table Forwarding_Group a
+ For IPv6 the similar flow is added with the following ac‐
+ tion
+
+ nd_na {
+ eth.dst = eth.src;
+ eth.src = E;
+ ip6.src = A;
+ nd.target = A;
+ nd.tll = E;
+ outport = inport;
+ flags.loopback = 1;
+ output;
+ };
+
+
+ • For each VIP configured in the table Forwarding_Group a
priority-50 logical flow is added with the match arp.tpa
== vip &&&& &&&& arp.op == 1
and applies the action
@@ -1270,26 +1389,26 @@
vmac.
A is used as either the destination ip for load balancing
- traffic to child ports or as nexthop to hosts behind the
+ traffic to child ports or as nexthop to hosts behind the
child ports.
- These flows are required to respond to an ARP request if
+ These flows are required to respond to an ARP request if
an ARP request is sent for the IP vip.
- · One priority-0 fallback flow that matches all packets and
+ • One priority-0 fallback flow that matches all packets and
advances to the next table.
- Ingress Table 20: DHCP option processing
+ Ingress Table 22: DHCP option processing
This table adds the DHCPv4 options to a DHCPv4 packet from the logical
ports configured with IPv4 address(es) and DHCPv4 options, and simi‐
larly for DHCPv6 options. This table also adds flows for the logical
ports of type external.
- · A priority-100 logical flow is added for these logical
+ • A priority-100 logical flow is added for these logical
ports which matches the IPv4 packet with udp.src = 68 and
- udp.dst = 67 and applies the action put_dhcp_opts and
- advances the packet to the next table.
+ udp.dst = 67 and applies the action put_dhcp_opts and ad‐
+ vances the packet to the next table.
reg0[3] = put_dhcp_opts(offer_ip = ip, options...);
next;
@@ -1301,7 +1420,7 @@
other kinds of packets, it just stores 0 into reg0[3].
Either way, it continues to the next table.
- · A priority-100 logical flow is added for these logical
+ • A priority-100 logical flow is added for these logical
ports which matches the IPv6 packet with udp.src = 546
and udp.dst = 547 and applies the action put_dhcpv6_opts
and advances the packet to the next table.
@@ -1317,16 +1436,16 @@
stores 0 into reg0[3]. Either way, it continues to the
next table.
- · A priority-0 flow that matches all packets to advances to
+ • A priority-0 flow that matches all packets to advances to
table 16.
- Ingress Table 21: DHCP responses
+ Ingress Table 23: DHCP responses
- This table implements DHCP responder for the DHCP replies generated by
+ This table implements DHCP responder for the DHCP replies generated by
the previous table.
- · A priority 100 logical flow is added for the logical
- ports configured with DHCPv4 options which matches IPv4
+ • A priority 100 logical flow is added for the logical
+ ports configured with DHCPv4 options which matches IPv4
packets with udp.src == 68 &&&& udp.dst == 67 &&&& reg0[3] ==
1 and responds back to the inport after applying these
actions. If reg0[3] is set to 1, it means that the action
@@ -1342,16 +1461,16 @@
output;
- where E is the server MAC address and S is the server
- IPv4 address defined in the DHCPv4 options. Note that
+ where E is the server MAC address and S is the server
+ IPv4 address defined in the DHCPv4 options. Note that
ip4.dst field is handled by put_dhcp_opts.
- (This terminates ingress packet processing; the packet
+ (This terminates ingress packet processing; the packet
does not go to the next ingress table.)
- · A priority 100 logical flow is added for the logical
- ports configured with DHCPv6 options which matches IPv6
- packets with udp.src == 546 &&&& udp.dst == 547 &&&& reg0[3]
+ • A priority 100 logical flow is added for the logical
+ ports configured with DHCPv6 options which matches IPv6
+ packets with udp.src == 546 &&&& udp.dst == 547 &&&& reg0[3]
== 1 and responds back to the inport after applying these
actions. If reg0[3] is set to 1, it means that the action
put_dhcpv6_opts was successful.
@@ -1367,25 +1486,25 @@
output;
- where E is the server MAC address and S is the server
- IPv6 LLA address generated from the server_id defined in
- the DHCPv6 options and A is the IPv6 address defined in
+ where E is the server MAC address and S is the server
+ IPv6 LLA address generated from the server_id defined in
+ the DHCPv6 options and A is the IPv6 address defined in
the logical port’s addresses column.
- (This terminates packet processing; the packet does not
+ (This terminates packet processing; the packet does not
go on the next ingress table.)
- · A priority-0 flow that matches all packets to advances to
+ • A priority-0 flow that matches all packets to advances to
table 17.
- Ingress Table 22 DNS Lookup
+ Ingress Table 24 DNS Lookup
This table looks up and resolves the DNS names to the corresponding
configured IP address(es).
- · A priority-100 logical flow for each logical switch data‐
- path if it is configured with DNS records, which matches
- the IPv4 and IPv6 packets with udp.dst = 53 and applies
+ • A priority-100 logical flow for each logical switch data‐
+ path if it is configured with DNS records, which matches
+ the IPv4 and IPv6 packets with udp.dst = 53 and applies
the action dns_lookup and advances the packet to the next
table.
@@ -1395,18 +1514,18 @@
For valid DNS packets, this transforms the packet into a
DNS reply if the DNS name can be resolved, and stores 1
into reg0[4]. For failed DNS resolution or other kinds of
- packets, it just stores 0 into reg0[4]. Either way, it
+ packets, it just stores 0 into reg0[4]. Either way, it
continues to the next table.
- Ingress Table 23 DNS Responses
+ Ingress Table 25 DNS Responses
- This table implements DNS responder for the DNS replies generated by
+ This table implements DNS responder for the DNS replies generated by
the previous table.
- · A priority-100 logical flow for each logical switch data‐
+ • A priority-100 logical flow for each logical switch data‐
path if it is configured with DNS records, which matches
the IPv4 and IPv6 packets with udp.dst = 53 &&&& reg0[4] ==
- 1 and responds back to the inport after applying these
+ 1 and responds back to the inport after applying these
actions. If reg0[4] is set to 1, it means that the action
dns_lookup was successful.
@@ -1422,50 +1541,50 @@
(This terminates ingress packet processing; the packet
does not go to the next ingress table.)
- Ingress table 24 External ports
+ Ingress table 26 External ports
Traffic from the external logical ports enter the ingress datapath
pipeline via the localnet port. This table adds the below logical flows
to handle the traffic from these ports.
- · A priority-100 flow is added for each external logical
- port which doesn’t reside on a chassis to drop the
- ARP/IPv6 NS request to the router IP(s) (of the logical
+ • A priority-100 flow is added for each external logical
+ port which doesn’t reside on a chassis to drop the
+ ARP/IPv6 NS request to the router IP(s) (of the logical
switch) which matches on the inport of the external logi‐
- cal port and the valid eth.src address(es) of the exter‐
+ cal port and the valid eth.src address(es) of the exter‐‐
nal logical port.
This flow guarantees that the ARP/NS request to the
router IP address from the external ports is responded by
- only the chassis which has claimed these external ports.
+ only the chassis which has claimed these external ports.
All the other chassis, drops these packets.
- A priority-100 flow is added for each external logical
+ A priority-100 flow is added for each external logical
port which doesn’t reside on a chassis to drop any packet
- destined to the router mac - with the match inport ==
- external &&&& eth.src == E &&&& eth.dst == R &&&& !is_chas‐
+ destined to the router mac - with the match inport == ex
+ ternal &&&& eth.src == E &&&& eth.dst == R &&&& !is_chas‐‐
sis_resident("external") where E is the external port mac
and R is the router port mac.
- · A priority-0 flow that matches all packets to advances to
+ • A priority-0 flow that matches all packets to advances to
table 20.
- Ingress Table 25 Destination Lookup
+ Ingress Table 27 Destination Lookup
- This table implements switching behavior. It contains these logical
+ This table implements switching behavior. It contains these logical
flows:
- · A priority-110 flow with the match eth.src == E for all
- logical switch datapaths and applies the action han‐
+ • A priority-110 flow with the match eth.src == E for all
+ logical switch datapaths and applies the action han‐‐
dle_svc_check(inport). Where E is the service monitor mac
defined in the options:svc_monitor_mac column of
NB_Global table.
- · A priority-100 flow that punts all IGMP/MLD packets to
+ • A priority-100 flow that punts all IGMP/MLD packets to
ovn-controller if multicast snooping is enabled on the
logical switch.
- · Priority-90 flows that forward registered IP multicast
+ • Priority-90 flows that forward registered IP multicast
traffic to their corresponding multicast group, which
ovn-northd creates based on learnt IGMP_Group entries.
The flows also forward packets to the MC_MROUTER_FLOOD
@@ -1473,34 +1592,34 @@
logical ports that are connected to logical routers with
options:mcast_relay=’true’.
- · A priority-85 flow that forwards all IP multicast traffic
+ • A priority-85 flow that forwards all IP multicast traffic
destined to 224.0.0.X to the MC_FLOOD_L2 multicast group,
which ovn-northd populates with all non-router logical
ports.
- · A priority-85 flow that forwards all IP multicast traffic
- destined to reserved multicast IPv6 addresses (RFC 4291,
- 2.7.1, e.g., Solicited-Node multicast) to the MC_FLOOD
- multicast group, which ovn-northd populates with all
- enabled logical ports.
+ • A priority-85 flow that forwards all IP multicast traffic
+ destined to reserved multicast IPv6 addresses (RFC 4291,
+ 2.7.1, e.g., Solicited-Node multicast) to the MC_FLOOD
+ multicast group, which ovn-northd populates with all en‐
+ abled logical ports.
- · A priority-80 flow that forwards all unregistered IP mul‐
+ • A priority-80 flow that forwards all unregistered IP mul‐
ticast traffic to the MC_STATIC multicast group, which
ovn-northd populates with all the logical ports that have
- options :mcast_flood=’true’. The flow also forwards
- unregistered IP multicast traffic to the MC_MROUTER_FLOOD
- multicast group, which ovn-northd populates with all the
- logical ports connected to logical routers that have
- options :mcast_relay=’true’.
-
- · A priority-80 flow that drops all unregistered IP multi‐
- cast traffic if other_config :mcast_snoop=’true’ and
- other_config :mcast_flood_unregistered=’false’ and the
- switch is not connected to a logical router that has
- options :mcast_relay=’true’ and the switch doesn’t have
- any logical port with options :mcast_flood=’true’.
-
- · Priority-80 flows for each IP address/VIP/NAT address
+ options :mcast_flood=’’true’’. The flow also forwards un‐
+ registered IP multicast traffic to the MC_MROUTER_FLOOD
+ multicast group, which ovn-northd populates with all the
+ logical ports connected to logical routers that have op‐‐
+ tions :mcast_relay=’’true’’.
+
+ • A priority-80 flow that drops all unregistered IP multi‐
+ cast traffic if other_config :mcast_snoop=’’true’’ and
+ other_config :mcast_flood_unregistered=’’false’’ and the
+ switch is not connected to a logical router that has op‐‐
+ tions :mcast_relay=’’true’’ and the switch doesn’t have any
+ logical port with options :mcast_flood=’’true’’.
+
+ • Priority-80 flows for each IP address/VIP/NAT address
owned by a router port connected to the switch. These
flows match ARP requests and ND packets for the specific
IP addresses. Matched packets are forwarded only to the
@@ -1508,75 +1627,80 @@
multicast group which contains all non-router logical
ports.
- · Priority-75 flows for each port connected to a logical
- router matching self originated ARP request/RARP
- request/ND packets. These packets are flooded to the
+ • Priority-75 flows for each port connected to a logical
+ router matching self originated ARP request/RARP re‐
+ quest/ND packets. These packets are flooded to the
MC_FLOOD_L2 which contains all non-router logical ports.
- · A priority-70 flow that outputs all packets with an Eth‐
+ • A priority-72 flow that outputs all ARP requests and ND
+ packets with an Ethernet broadcast or multicast eth.dst
+ to the MC_FLOOD_L2 multicast group if other_config:broad‐‐
+ cast-arps-to-all-routers=true.
+
+ • A priority-70 flow that outputs all packets with an Eth‐
ernet broadcast or multicast eth.dst to the MC_FLOOD mul‐
ticast group.
- · One priority-50 flow that matches each known Ethernet
- address against eth.dst. Action of this flow outputs the
- packet to the single associated output port if it is
- enabled. drop; action is applied if LSP is disabled.
+ • One priority-50 flow that matches each known Ethernet ad‐
+ dress against eth.dst. Action of this flow outputs the
+ packet to the single associated output port if it is en‐
+ abled. drop; action is applied if LSP is disabled.
For the Ethernet address on a logical switch port of type
- router, when that logical switch port’s addresses column
- is set to router and the connected logical router port
+ router, when that logical switch port’s addresses column
+ is set to router and the connected logical router port
has a gateway chassis:
- · The flow for the connected logical router port’s
+ • The flow for the connected logical router port’s
Ethernet address is only programmed on the gateway
chassis.
- · If the logical router has rules specified in nat
+ • If the logical router has rules specified in nat
with external_mac, then those addresses are also
used to populate the switch’s destination lookup
on the chassis where logical_port is resident.
For the Ethernet address on a logical switch port of type
- router, when that logical switch port’s addresses column
- is set to router and the connected logical router port
- specifies a reside-on-redirect-chassis and the logical
+ router, when that logical switch port’s addresses column
+ is set to router and the connected logical router port
+ specifies a reside-on-redirect-chassis and the logical
router to which the connected logical router port belongs
to has a distributed gateway LRP:
- · The flow for the connected logical router port’s
+ • The flow for the connected logical router port’s
Ethernet address is only programmed on the gateway
chassis.
- For each forwarding group configured on the logical
- switch datapath, a priority-50 flow that matches on
+ For each forwarding group configured on the logical
+ switch datapath, a priority-50 flow that matches on
eth.dst == VIP
- with an action of fwd_group(childports=args ), where
- args contains comma separated logical switch child ports
- to load balance to. If liveness is enabled, then action
+ with an action of fwd_group(childports=args ), where
+ args contains comma separated logical switch child ports
+ to load balance to. If liveness is enabled, then action
also includes liveness=true.
- · One priority-0 fallback flow that matches all packets
- with the action outport = get_fdb(eth.dst); next;. The
- action get_fdb gets the port for the eth.dst in the MAC
- learning table of the logical switch datapath. If there
- is no entry for eth.dst in the MAC learning table, then
+ • One priority-0 fallback flow that matches all packets
+ with the action outport = get_fdb(eth.dst); next;. The
+ action get_fdb gets the port for the eth.dst in the MAC
+ learning table of the logical switch datapath. If there
+ is no entry for eth.dst in the MAC learning table, then
it stores none in the outport.
- Ingress Table 26 Destination unknown
+ Ingress Table 28 Destination unknown
- This table handles the packets whose destination was not found or and
- looked up in the MAC learning table of the logical switch datapath. It
+ This table handles the packets whose destination was not found or and
+ looked up in the MAC learning table of the logical switch datapath. It
contains the following flows.
- · Priority 50 flow with the match outport == P is added for
+ • Priority 50 flow with the match outport == P is added for
each disabled Logical Switch Port P. This flow has action
drop;.
- · If the logical switch has logical ports with ’unknown’
+ • If the logical switch has logical ports with ’unknown’
addresses set, then the below logical flow is added
- · Priority 50 flow with the match outport == "none"
- then outputs them to the MC_UNKNOWN multicast
+ • Priority 50 flow with the match outport == "none"
+ then outputs them to the MC_UNKNOWN multicast
group, which ovn-northd populates with all enabled
logical ports that accept unknown destination
packets. As a small optimization, if no logical
@@ -1587,12 +1711,12 @@
If the logical switch has no logical ports with ’unknown’
address set, then the below logical flow is added
- · Priority 50 flow with the match outport == none
+ • Priority 50 flow with the match outport == none
and drops the packets.
- · One priority-0 fallback flow that outputs the packet to
- the egress stage with the outport learnt from get_fdb
- action.
+ • One priority-0 fallback flow that outputs the packet to
+ the egress stage with the outport learnt from get_fdb ac‐
+ tion.
Egress Table 0: to-lport Pre-ACLs
@@ -1612,95 +1736,121 @@
Egress Table 1: Pre-LB
This table is similar to ingress table Pre-LB. It contains a priority-0
- flow that simply moves traffic to the next table. Moreover it contains
- two priority-110 flows to move multicast, IPv6 Neighbor Discovery and
- MLD traffic to the next table. If any load balancing rules exist for
- the datapath, a priority-100 flow is added with a match of ip and
- action of reg0[2] = 1; next; to act as a hint for table Pre-stateful to
- send IP packets to the connection tracker for packet de-fragmentation
- and possibly DNAT the destination VIP to one of the selected backend
+ flow that simply moves traffic to the next table. Moreover it contains
+ two priority-110 flows to move multicast, IPv6 Neighbor Discovery and
+ MLD traffic to the next table. If any load balancing rules exist for
+ the datapath, a priority-100 flow is added with a match of ip and ac‐
+ tion of reg0[2] = 1; next; to act as a hint for table Pre-stateful to
+ send IP packets to the connection tracker for packet de-fragmentation
+ and possibly DNAT the destination VIP to one of the selected backend
for already committed load balanced traffic.
This table also has a priority-110 flow with the match eth.src == E for
all logical switch datapaths to move traffic to the next table. Where E
- is the service monitor mac defined in the options:svc_monitor_mac col‐
+ is the service monitor mac defined in the options:svc_monitor_mac col‐
umn of NB_Global table.
+ This table also has a priority-110 flow with the match outport == I for
+ all logical switch datapaths to move traffic to the next table, and, if
+ there are no stateful_acl, clear the ct_state. Where I is the peer of a
+ logical router port. This flow is added to skip the connection tracking
+ of packets which will be entering logical router datapath from logical
+ switch datapath for routing.
+
Egress Table 2: Pre-stateful
- This is similar to ingress table Pre-stateful. This table adds the
- below 3 logical flows.
+ This is similar to ingress table Pre-stateful. This table adds the be‐
+ low 3 logical flows.
- · A Priority-120 flow that send the packets to connection
- tracker using ct_lb_mark; as the action so that the
- already established traffic gets unDNATted from the back‐
- end IP to the load balancer VIP based on a hint provided
- by the previous tables with a match for reg0[2] == 1. If
- the packet was not DNATted earlier, then ct_lb_mark func‐
- tions like ct_next.
+ • A Priority-120 flow that send the packets to connection
+ tracker using ct_lb_mark; as the action so that the al‐
+ ready established traffic gets unDNATted from the backend
+ IP to the load balancer VIP based on a hint provided by
+ the previous tables with a match for reg0[2] == 1. If the
+ packet was not DNATted earlier, then ct_lb_mark functions
+ like ct_next.
- · A priority-100 flow sends the packets to connection
- tracker based on a hint provided by the previous tables
- (with a match for reg0[0] == 1) by using the ct_next;
- action.
+ • A priority-100 flow sends the packets to connection
+ tracker based on a hint provided by the previous tables
+ (with a match for reg0[0] == 1) by using the ct_next; ac‐
+ tion.
- · A priority-0 flow that matches all packets to advance to
+ • A priority-0 flow that matches all packets to advance to
the next table.
Egress Table 3: from-lport ACL hints
This is similar to ingress table ACL hints.
- Egress Table 4: to-lport ACLs
+ Egress Table 4: to-lport ACL evaluation
+
+ This is similar to ingress table ACL eval except for to-lport ACLs. As
+ a reminder, these flows use the following register bits to indicate
+ their verdicts. Allow-type ACLs set reg8[16], drop ACLs set reg8[17],
+ and reject ACLs set reg8[18].
+
+ Also like with ingress ACLs, egress ACLs can have a configured tier. If
+ a tier is configured, then the current tier counter is evaluated
+ against the ACL’s configured tier in addition to the ACL’s match. The
+ current tier counter is stored in reg8[30..31].
- This is similar to ingress table ACLs except for to-lport ACLs.
+ Similar to ingress table, a priority-65532 flow is added to allow IPv6
+ Neighbor solicitation, Neighbor discover, Router solicitation, Router
+ advertisement and MLD packets regardless of other ACLs defined.
In addition, the following flows are added.
- · A priority 34000 logical flow is added for each logical
+ • A priority 34000 logical flow is added for each logical
port which has DHCPv4 options defined to allow the DHCPv4
- reply packet and which has DHCPv6 options defined to
- allow the DHCPv6 reply packet from the Ingress Table 18:
- DHCP responses.
+ reply packet and which has DHCPv6 options defined to al‐
+ low the DHCPv6 reply packet from the Ingress Table 18:
+ DHCP responses. This is indicated by setting the allow
+ bit.
- · A priority 34000 logical flow is added for each logical
- switch datapath configured with DNS records with the
+ • A priority 34000 logical flow is added for each logical
+ switch datapath configured with DNS records with the
match udp.dst = 53 to allow the DNS reply packet from the
- Ingress Table 20: DNS responses.
+ Ingress Table 20: DNS responses. This is indicated by
+ setting the allow bit.
- · A priority 34000 logical flow is added for each logical
- switch datapath with the match eth.src = E to allow the
- service monitor request packet generated by ovn-con‐
+ • A priority 34000 logical flow is added for each logical
+ switch datapath with the match eth.src = E to allow the
+ service monitor request packet generated by ovn-con‐‐
troller with the action next, where E is the service mon‐
itor mac defined in the options:svc_monitor_mac column of
- NB_Global table.
+ NB_Global table. This is indicated by setting the allow
+ bit.
+
+ Egress Table 5: to-lport ACL action
- Egress Table 5: to-lport QoS Marking
+ This is similar to ingress table ACL action.
+
+ Egress Table 6: to-lport QoS Marking
This is similar to ingress table QoS marking except they apply to
to-lport QoS rules.
- Egress Table 6: to-lport QoS Meter
+ Egress Table 7: to-lport QoS Meter
This is similar to ingress table QoS meter except they apply to
to-lport QoS rules.
- Egress Table 7: Stateful
+ Egress Table 8: Stateful
This is similar to ingress table Stateful except that there are no
rules added for load balancing new connections.
- Egress Table 8: Egress Port Security - check
+ Egress Table 9: Egress Port Security - check
- This is similar to the port security logic in table Ingress Port Secu‐
+ This is similar to the port security logic in table Ingress Port Secu‐‐
rity check except that action check_out_port_sec is used to check the
port security rules. This table adds the below logical flows.
- · A priority 100 flow which matches on the multicast traf‐
+ • A priority 100 flow which matches on the multicast traf‐
fic and applies the action REGBIT_PORT_SEC_DROP" = 0;
next;" to skip the out port security checks.
- · A priority 0 logical flow is added which matches on all
+ • A priority 0 logical flow is added which matches on all
the packets and applies the action REGBIT_PORT_SEC_DROP"
= check_out_port_sec(); next;". The action
check_out_port_sec applies the port security rules based
@@ -1708,16 +1858,23 @@
Logical_Switch_Port table before delivering the packet to
the outport.
- Egress Table 9: Egress Port Security - Apply
+ Egress Table 10: Egress Port Security - Apply
- This is similar to the ingress port security logic in ingress table A
+ This is similar to the ingress port security logic in ingress table A
Ingress Port Security - Apply. This table drops the packets if the port
- security check failed in the previous stage i.e the register bit REG‐
+ security check failed in the previous stage i.e the register bit REG‐‐
BIT_PORT_SEC_DROP is set to 1.
The following flows are added.
- · For each localnet port configured with egress qos in the
+ • For each port configured with egress qos in the op‐‐
+ tions:qdisc_queue_id column of Logical_Switch_Port, run‐
+ ning a localnet port on the same logical switch, a prior‐
+ ity 110 flow is added which matches on the localnet out‐‐
+ port and on the port inport and applies the action
+ set_queue(id); output;".
+
+ • For each localnet port configured with egress qos in the
options:qdisc_queue_id column of Logical_Switch_Port, a
priority 100 flow is added which matches on the localnet
outport and applies the action set_queue(id); output;".
@@ -1725,10 +1882,10 @@
Please remember to mark the corresponding physical inter‐
face with ovn-egress-iface set to true in external_ids.
- · A priority-50 flow that drops the packet if the register
+ • A priority-50 flow that drops the packet if the register
bit REGBIT_PORT_SEC_DROP is set to 1.
- · A priority-0 flow that outputs the packet to the outport.
+ • A priority-0 flow that outputs the packet to the outport.
Logical Router Datapaths
Logical router datapaths will only exist for Logical_Router rows in the
@@ -1739,49 +1896,59 @@
This table drops packets that the router shouldn’t see at all based on
their Ethernet headers. It contains the following flows:
- · Priority-100 flows to drop packets with VLAN tags or mul‐
+ • Priority-100 flows to drop packets with VLAN tags or mul‐
ticast Ethernet source addresses.
- · For each enabled router port P with Ethernet address E, a
+ • For each enabled router port P with Ethernet address E, a
priority-50 flow that matches inport == P &&&& (eth.mcast
|| eth.dst == E), stores the router port ethernet address
- and advances to next table, with action xreg0[0..47]=E;
+ and advances to next table, with action xreg0[0..47]=E;
next;.
- For the gateway port on a distributed logical router
- (where one of the logical router ports specifies a gate‐
- way chassis), the above flow matching eth.dst == E is
+ For the gateway port on a distributed logical router
+ (where one of the logical router ports specifies a gate‐
+ way chassis), the above flow matching eth.dst == E is
only programmed on the gateway port instance on the gate‐
way chassis. If LRP’s logical switch has attached LSP of
vtep type, the is_chassis_resident() part is not added to
- lflow to allow traffic originated from logical switch to
+ lflow to allow traffic originated from logical switch to
reach LR services (LBs, NAT).
- For a distributed logical router or for gateway router
+ For each gateway port GW on a distributed logical router
+ a priority-120 flow that matches ’recirculated’ icmp{4,6}
+ error ’packet too big’ and eth.dst == D &&&& !is_chas‐‐
+ sis_resident( cr-GW) where D is the gateway port mac ad‐
+ dress and cr-GW is the chassis resident port of GW, swap
+ inport and outport and stores GW as inport.
+
+ This table adds a priority-110 flow that matches ’recir‐
+ culated’ icmp{4,6} error ’packet too big’ to drop the
+ packet.
+
+ For a distributed logical router or for gateway router
where the port is configured with options:gateway_mtu the
action of the above flow is modified adding
- check_pkt_larger in order to mark the packet setting REG‐
- BIT_PKT_LARGER if the size is greater than the MTU. If
- the port is also configured with options:gate‐
- way_mtu_bypass then another flow is added, with prior‐
- ity-55, to bypass the check_pkt_larger flow. This is use‐
- ful for traffic that normally doesn’t need to be frag‐
- mented and for which check_pkt_larger, which might not be
- offloadable, is not really needed. One such example is
- TCP traffic.
-
- · For each dnat_and_snat NAT rule on a distributed router
- that specifies an external Ethernet address E, a prior‐
- ity-50 flow that matches inport == GW &&&& eth.dst == E,
- where GW is the logical router distributed gateway port
- corresponding to the NAT rule (specified or inferred),
+ check_pkt_larger in order to mark the packet setting REG‐‐
+ BIT_PKT_LARGER if the size is greater than the MTU. If
+ the port is also configured with options:gateway_mtu_by‐‐
+ pass then another flow is added, with priority-55, to by‐
+ pass the check_pkt_larger flow. This is useful for traf‐
+ fic that normally doesn’t need to be fragmented and for
+ which check_pkt_larger, which might not be offloadable,
+ is not really needed. One such example is TCP traffic.
+
+ • For each dnat_and_snat NAT rule on a distributed router
+ that specifies an external Ethernet address E, a prior‐
+ ity-50 flow that matches inport == GW &&&& eth.dst == E,
+ where GW is the logical router distributed gateway port
+ corresponding to the NAT rule (specified or inferred),
with action xreg0[0..47]=E; next;.
This flow is only programmed on the gateway port instance
on the chassis where the logical_port specified in the
NAT rule resides.
- · A priority-0 logical flow that matches all packets not
+ • A priority-0 logical flow that matches all packets not
already handled (match 1) and drops them (action drop;).
Other packets are implicitly dropped.
@@ -1792,10 +1959,10 @@
MAC_Binding records to determine if OVN needs to learn the mac bind‐
ings. Following flows are added:
- · For each router port P that owns IP address A, which
- belongs to subnet S with prefix length L, if the option
- always_learn_from_arp_request is true for this router, a
- priority-100 flow is added which matches inport == P &&&&
+ • For each router port P that owns IP address A, which be‐
+ longs to subnet S with prefix length L, if the option al‐‐
+ ways_learn_from_arp_request is true for this router, a
+ priority-100 flow is added which matches inport == P &&&&
arp.spa == S/L &&&& arp.op == 1 (ARP request) with the fol‐
lowing actions:
@@ -1807,8 +1974,8 @@
following two flows are added.
A priority-110 flow is added which matches inport == P &&&&
- arp.spa == S/L &&&& arp.tpa == A &&&& arp.op == 1 (ARP
- request) with the following actions:
+ arp.spa == S/L &&&& arp.tpa == A &&&& arp.op == 1 (ARP re‐
+ quest) with the following actions:
reg9[2] = lookup_arp(inport, arp.spa, arp.sha);
reg9[3] = 1;
@@ -1828,9 +1995,9 @@
router port, additional match is_chassis_resident(cr-P)
is added for all these flows.
- · A priority-100 flow which matches on ARP reply packets
- and applies the actions if the option
- always_learn_from_arp_request is true:
+ • A priority-100 flow which matches on ARP reply packets
+ and applies the actions if the option al‐‐
+ ways_learn_from_arp_request is true:
reg9[2] = lookup_arp(inport, arp.spa, arp.sha);
next;
@@ -1844,8 +2011,8 @@
next;
- · A priority-100 flow which matches on IPv6 Neighbor Dis‐
- covery advertisement packet and applies the actions if
+ • A priority-100 flow which matches on IPv6 Neighbor Dis‐
+ covery advertisement packet and applies the actions if
the option always_learn_from_arp_request is true:
reg9[2] = lookup_nd(inport, nd.target, nd.tll);
@@ -1860,7 +2027,7 @@
next;
- · A priority-100 flow which matches on IPv6 Neighbor Dis‐
+ • A priority-100 flow which matches on IPv6 Neighbor Dis‐
covery solicitation packet and applies the actions if the
option always_learn_from_arp_request is true:
@@ -1876,7 +2043,7 @@
next;
- · A priority-0 fallback flow that matches all packets and
+ • A priority-0 fallback flow that matches all packets and
applies the action reg9[2] = 1; next; advancing the
packet to the next table.
@@ -1887,49 +2054,49 @@
to the lookup results from the previous stage.
reg9[2] will be 1 if the lookup_arp/lookup_nd in the previous table was
- successful or skipped, meaning no need to learn mac binding from the
+ successful or skipped, meaning no need to learn mac binding from the
packet.
reg9[3] will be 1 if the lookup_arp_ip/lookup_nd_ip in the previous ta‐
ble was successful or skipped, meaning it is ok to learn mac binding
from the packet (if reg9[2] is 0).
- · A priority-100 flow with the match reg9[2] == 1 ||
+ • A priority-100 flow with the match reg9[2] == 1 ||
reg9[3] == 0 and advances the packet to the next table as
there is no need to learn the neighbor.
- · A priority-95 flow with the match nd_ns &&&& (ip6.src == 0
+ • A priority-95 flow with the match nd_ns &&&& (ip6.src == 0
|| nd.sll == 0) and applies the action next;
- · A priority-90 flow with the match arp and applies the
- action put_arp(inport, arp.spa, arp.sha); next;
+ • A priority-90 flow with the match arp and applies the ac‐
+ tion put_arp(inport, arp.spa, arp.sha); next;
- · A priority-95 flow with the match nd_na &&&& nd.tll == 0
+ • A priority-95 flow with the match nd_na &&&& nd.tll == 0
and applies the action put_nd(inport, nd.target,
eth.src); next;
- · A priority-90 flow with the match nd_na and applies the
+ • A priority-90 flow with the match nd_na and applies the
action put_nd(inport, nd.target, nd.tll); next;
- · A priority-90 flow with the match nd_ns and applies the
+ • A priority-90 flow with the match nd_ns and applies the
action put_nd(inport, ip6.src, nd.sll); next;
- · A priority-0 logical flow that matches all packets not
+ • A priority-0 logical flow that matches all packets not
already handled (match 1) and drops them (action drop;).
Ingress Table 3: IP Input
This table is the core of the logical router datapath functionality. It
- contains the following flows to implement very basic IP host function‐
+ contains the following flows to implement very basic IP host function‐
ality.
- · For each dnat_and_snat NAT rule on a distributed logical
- routers or gateway routers with gateway port configured
- with options:gateway_mtu to a valid integer value M, a
- priority-160 flow with the match inport == LRP &&&& REG‐
- BIT_PKT_LARGER &&&& REGBIT_EGRESS_LOOPBACK == 0, where LRP
- is the logical router port and applies the following
- action for ipv4 and ipv6 respectively:
+ • For each dnat_and_snat NAT rule on a distributed logical
+ routers or gateway routers with gateway port configured
+ with options:gateway_mtu to a valid integer value M, a
+ priority-160 flow with the match inport == LRP &&&& REG‐‐
+ BIT_PKT_LARGER &&&& REGBIT_EGRESS_LOOPBACK == 0, where LRP
+ is the logical router port and applies the following ac‐
+ tion for ipv4 and ipv6 respectively:
icmp4_error {
icmp4.type = 3; /* Destination Unreachable. */
@@ -1963,15 +2130,15 @@
};
- where E and I are the NAT rule external mac and IP
- respectively.
+ where E and I are the NAT rule external mac and IP re‐
+ spectively.
- · For distributed logical routers or gateway routers with
- gateway port configured with options:gateway_mtu to a
- valid integer value, a priority-150 flow with the match
- inport == LRP &&&& REGBIT_PKT_LARGER &&&& REGBIT_EGRESS_LOOP‐
- BACK == 0, where LRP is the logical router port and
- applies the following action for ipv4 and ipv6 respec‐
+ • For distributed logical routers or gateway routers with
+ gateway port configured with options:gateway_mtu to a
+ valid integer value, a priority-150 flow with the match
+ inport == LRP &&&& REGBIT_PKT_LARGER &&&& REGBIT_EGRESS_LOOP‐‐
+ BACK == 0, where LRP is the logical router port and ap‐
+ plies the following action for ipv4 and ipv6 respec‐
tively:
icmp4_error {
@@ -2000,70 +2167,70 @@
};
- · For each NAT entry of a distributed logical router (with
+ • For each NAT entry of a distributed logical router (with
distributed gateway router port(s)) of type snat, a pri‐
ority-120 flow with the match inport == P &&&& ip4.src == A
- advances the packet to the next pipeline, where P is the
- distributed logical router port corresponding to the NAT
- entry (specified or inferred) and A is the external_ip
- set in the NAT entry. If A is an IPv6 address, then
+ advances the packet to the next pipeline, where P is the
+ distributed logical router port corresponding to the NAT
+ entry (specified or inferred) and A is the external_ip
+ set in the NAT entry. If A is an IPv6 address, then
ip6.src is used for the match.
- The above flow is required to handle the routing of the
+ The above flow is required to handle the routing of the
East/west NAT traffic.
- · For each BFD port the two following priority-110 flows
+ • For each BFD port the two following priority-110 flows
are added to manage BFD traffic:
- · if ip4.src or ip6.src is any IP address owned by
- the router port and udp.dst == 3784 , the packet
+ • if ip4.src or ip6.src is any IP address owned by
+ the router port and udp.dst == 3784 , the packet
is advanced to the next pipeline stage.
- · if ip4.dst or ip6.dst is any IP address owned by
- the router port and udp.dst == 3784 , the han‐
+ • if ip4.dst or ip6.dst is any IP address owned by
+ the router port and udp.dst == 3784 , the han‐‐
dle_bfd_msg action is executed.
- · L3 admission control: Priority-120 flows allows IGMP and
- MLD packets if the router has logical ports that have
- options :mcast_flood=’true’.
+ • L3 admission control: Priority-120 flows allows IGMP and
+ MLD packets if the router has logical ports that have op‐‐
+ tions :mcast_flood=’’true’’.
- · L3 admission control: A priority-100 flow drops packets
+ • L3 admission control: A priority-100 flow drops packets
that match any of the following:
- · ip4.src[28..31] == 0xe (multicast source)
+ • ip4.src[28..31] == 0xe (multicast source)
- · ip4.src == 255.255.255.255 (broadcast source)
+ • ip4.src == 255.255.255.255 (broadcast source)
- · ip4.src == 127.0.0.0/8 || ip4.dst == 127.0.0.0/8
+ • ip4.src == 127.0.0.0/8 || ip4.dst == 127.0.0.0/8
(localhost source or destination)
- · ip4.src == 0.0.0.0/8 || ip4.dst == 0.0.0.0/8 (zero
+ • ip4.src == 0.0.0.0/8 || ip4.dst == 0.0.0.0/8 (zero
network source or destination)
- · ip4.src or ip6.src is any IP address owned by the
- router, unless the packet was recirculated due to
- egress loopback as indicated by REG‐
+ • ip4.src or ip6.src is any IP address owned by the
+ router, unless the packet was recirculated due to
+ egress loopback as indicated by REG‐‐
BIT_EGRESS_LOOPBACK.
- · ip4.src is the broadcast address of any IP network
+ • ip4.src is the broadcast address of any IP network
known to the router.
- · A priority-100 flow parses DHCPv6 replies from IPv6 pre‐
+ • A priority-100 flow parses DHCPv6 replies from IPv6 pre‐
fix delegation routers (udp.src == 547 &&&& udp.dst ==
546). The handle_dhcpv6_reply is used to send IPv6 prefix
delegation messages to the delegation router.
- · ICMP echo reply. These flows reply to ICMP echo requests
- received for the router’s IP address. Let A be an IP
- address owned by a router port. Then, for each A that is
- an IPv4 address, a priority-90 flow matches on ip4.dst ==
- A and icmp4.type == 8 &&&& icmp4.code == 0 (ICMP echo
- request). For each A that is an IPv6 address, a prior‐
- ity-90 flow matches on ip6.dst == A and icmp6.type == 128
- &&&& icmp6.code == 0 (ICMPv6 echo request). The port of the
- router that receives the echo request does not matter.
- Also, the ip.ttl of the echo request packet is not
- checked, so it complies with RFC 1812, section 4.2.2.9.
+ • ICMP echo reply. These flows reply to ICMP echo requests
+ received for the router’s IP address. Let A be an IP ad‐
+ dress owned by a router port. Then, for each A that is an
+ IPv4 address, a priority-90 flow matches on ip4.dst == A
+ and icmp4.type == 8 &&&& icmp4.code == 0 (ICMP echo re‐
+ quest). For each A that is an IPv6 address, a priority-90
+ flow matches on ip6.dst == A and icmp6.type == 128 &&&&
+ icmp6.code == 0 (ICMPv6 echo request). The port of the
+ router that receives the echo request does not matter.
+ Also, the ip.ttl of the echo request packet is not
+ checked, so it complies with RFC 1812, section 4.2.2.9.
Flows for ICMPv4 echo requests use the following actions:
ip4.dst ->gt;>gt; ip4.src;
@@ -2082,11 +2249,11 @@
next;
- · Reply to ARP requests.
+ • Reply to ARP requests.
These flows reply to ARP requests for the router’s own IP
- address. The ARP requests are handled only if the
- requestor’s IP belongs to the same subnets of the logical
+ address. The ARP requests are handled only if the re‐
+ questor’s IP belongs to the same subnets of the logical
router port. For each router port P that owns IP address
A, which belongs to subnet S with prefix length L, and
Ethernet address E, a priority-90 flow matches inport ==
@@ -2113,22 +2280,23 @@
ferent chassis, and allows upstream MAC learning to point
to the gateway chassis.
- For the logical router port with the option reside-on-re‐
- direct-chassis set (which is centralized), the above
- flows are only programmed on the gateway port instance on
- the gateway chassis (if the logical router has a distrib‐
- uted gateway port). This behavior avoids generation of
- multiple ARP responses from different chassis, and allows
- upstream MAC learning to point to the gateway chassis.
-
- · Reply to IPv6 Neighbor Solicitations. These flows reply
- to Neighbor Solicitation requests for the router’s own
- IPv6 address and populate the logical router’s mac bind‐
+ For the logical router port with the option re‐‐
+ side-on-redirect-chassis set (which is centralized), the
+ above flows are only programmed on the gateway port in‐
+ stance on the gateway chassis (if the logical router has
+ a distributed gateway port). This behavior avoids genera‐
+ tion of multiple ARP responses from different chassis,
+ and allows upstream MAC learning to point to the gateway
+ chassis.
+
+ • Reply to IPv6 Neighbor Solicitations. These flows reply
+ to Neighbor Solicitation requests for the router’s own
+ IPv6 address and populate the logical router’s mac bind‐
ing table.
- For each router port P that owns IPv6 address A,
- solicited node address S, and Ethernet address E, a pri‐
- ority-90 flow matches inport == P &&&& nd_ns &&&& ip6.dst ==
+ For each router port P that owns IPv6 address A, so‐
+ licited node address S, and Ethernet address E, a prior‐
+ ity-90 flow matches inport == P &&&& nd_ns &&&& ip6.dst ==
{A, E} &&&& nd.target == A with the following actions:
nd_na_router {
@@ -2142,24 +2310,24 @@
};
- For the gateway port on a distributed logical router
- (where one of the logical router ports specifies a gate‐
- way chassis), the above flows replying to IPv6 Neighbor
- Solicitations are only programmed on the gateway port
- instance on the gateway chassis. This behavior avoids
- generation of multiple replies from different chassis,
- and allows upstream MAC learning to point to the gateway
+ For the gateway port on a distributed logical router
+ (where one of the logical router ports specifies a gate‐
+ way chassis), the above flows replying to IPv6 Neighbor
+ Solicitations are only programmed on the gateway port in‐
+ stance on the gateway chassis. This behavior avoids gen‐
+ eration of multiple replies from different chassis, and
+ allows upstream MAC learning to point to the gateway
chassis.
- · These flows reply to ARP requests or IPv6 neighbor solic‐
- itation for the virtual IP addresses configured in the
+ • These flows reply to ARP requests or IPv6 neighbor solic‐
+ itation for the virtual IP addresses configured in the
router for NAT (both DNAT and SNAT) or load balancing.
- IPv4: For a configured NAT (both DNAT and SNAT) IP
- address or a load balancer IPv4 VIP A, for each router
- port P with Ethernet address E, a priority-90 flow
- matches arp.op == 1 &&&& arp.tpa == A (ARP request) with
- the following actions:
+ IPv4: For a configured NAT (both DNAT and SNAT) IP ad‐
+ dress or a load balancer IPv4 VIP A, for each router port
+ P with Ethernet address E, a priority-90 flow matches
+ arp.op == 1 &&&& arp.tpa == A (ARP request) with the fol‐
+ lowing actions:
eth.dst = eth.src;
eth.src = xreg0[0..47];
@@ -2181,13 +2349,13 @@
port, then the is_chassis_resident(P) is also added in
the match condition for the load balancer IPv4 VIP A.
- IPv6: For a configured NAT (both DNAT and SNAT) IP
- address or a load balancer IPv6 VIP A (if the VIP is
- reachable from any logical router port of the logical
- router), solicited node address S, for each router port P
- with Ethernet address E, a priority-90 flow matches
- inport == P &&&& nd_ns &&&& ip6.dst == {A, S} &&&& nd.target ==
- A with the following actions:
+ IPv6: For a configured NAT (both DNAT and SNAT) IP ad‐
+ dress or a load balancer IPv6 VIP A (if the VIP is reach‐
+ able from any logical router port of the logical router),
+ solicited node address S, for each router port P with
+ Ethernet address E, a priority-90 flow matches inport ==
+ P &&&& nd_ns &&&& ip6.dst == {A, S} &&&& nd.target == A with
+ the following actions:
eth.dst = eth.src;
nd_na {
@@ -2206,27 +2374,26 @@
the match condition for the load balancer IPv6 VIP A.
For the gateway port on a distributed logical router with
- NAT (where one of the logical router ports specifies a
+ NAT (where one of the logical router ports specifies a
gateway chassis):
- · If the corresponding NAT rule cannot be handled in
+ • If the corresponding NAT rule cannot be handled in
a distributed manner, then a priority-92 flow is
programmed on the gateway port instance on the
gateway chassis. A priority-91 drop flow is pro‐
grammed on the other chassis when ARP requests/NS
- packets are received on the gateway port. This
- behavior avoids generation of multiple ARP
- responses from different chassis, and allows
- upstream MAC learning to point to the gateway
- chassis.
-
- · If the corresponding NAT rule can be handled in a
- distributed manner, then this flow is only pro‐
- grammed on the gateway port instance where the
+ packets are received on the gateway port. This be‐
+ havior avoids generation of multiple ARP responses
+ from different chassis, and allows upstream MAC
+ learning to point to the gateway chassis.
+
+ • If the corresponding NAT rule can be handled in a
+ distributed manner, then this flow is only pro‐
+ grammed on the gateway port instance where the
logical_port specified in the NAT rule resides.
- Some of the actions are different for this case,
- using the external_mac specified in the NAT rule
+ Some of the actions are different for this case,
+ using the external_mac specified in the NAT rule
rather than the gateway port’s Ethernet address E:
eth.src = external_mac;
@@ -2239,43 +2406,43 @@
nd.tll = external_mac;
- This behavior avoids generation of multiple ARP
- responses from different chassis, and allows
- upstream MAC learning to point to the correct
- chassis.
+ This behavior avoids generation of multiple ARP
+ responses from different chassis, and allows up‐
+ stream MAC learning to point to the correct chas‐
+ sis.
- · Priority-85 flows which drops the ARP and IPv6 Neighbor
+ • Priority-85 flows which drops the ARP and IPv6 Neighbor
Discovery packets.
- · A priority-84 flow explicitly allows IPv6 multicast traf‐
+ • A priority-84 flow explicitly allows IPv6 multicast traf‐
fic that is supposed to reach the router pipeline (i.e.,
router solicitation and router advertisement packets).
- · A priority-83 flow explicitly drops IPv6 multicast traf‐
+ • A priority-83 flow explicitly drops IPv6 multicast traf‐
fic that is destined to reserved multicast groups.
- · A priority-82 flow allows IP multicast traffic if
- options:mcast_relay=’true’, otherwise drops it.
+ • A priority-82 flow allows IP multicast traffic if op‐‐
+ tions:mcast_relay=’true’, otherwise drops it.
- · UDP port unreachable. Priority-80 flows generate ICMP
- port unreachable messages in reply to UDP datagrams
- directed to the router’s IP address, except in the spe‐
- cial case of gateways, which accept traffic directed to a
+ • UDP port unreachable. Priority-80 flows generate ICMP
+ port unreachable messages in reply to UDP datagrams di‐
+ rected to the router’s IP address, except in the special
+ case of gateways, which accept traffic directed to a
router IP for load balancing and NAT purposes.
These flows should not match IP fragments with nonzero
offset.
- · TCP reset. Priority-80 flows generate TCP reset messages
- in reply to TCP datagrams directed to the router’s IP
- address, except in the special case of gateways, which
- accept traffic directed to a router IP for load balancing
+ • TCP reset. Priority-80 flows generate TCP reset messages
+ in reply to TCP datagrams directed to the router’s IP ad‐
+ dress, except in the special case of gateways, which ac‐
+ cept traffic directed to a router IP for load balancing
and NAT purposes.
- These flows should not match IP fragments with nonzero
+ These flows should not match IP fragments with nonzero
offset.
- · Protocol or address unreachable. Priority-70 flows gener‐
+ • Protocol or address unreachable. Priority-70 flows gener‐
ate ICMP protocol or address unreachable messages for
IPv4 and IPv6 respectively in reply to packets directed
to the router’s IP address on IP protocols other than
@@ -2286,33 +2453,38 @@
These flows should not match IP fragments with nonzero
offset.
- · Drop other IP traffic to this router. These flows drop
+ • Drop other IP traffic to this router. These flows drop
any other traffic destined to an IP address of this
router that is not already handled by one of the flows
above, which amounts to ICMP (other than echo requests)
and fragments with nonzero offsets. For each IP address A
- owned by the router, a priority-60 flow matches ip4.dst
- == A or ip6.dst == A and drops the traffic. An exception
- is made and the above flow is not added if the router
- port’s own IP address is used to SNAT packets passing
- through that router or if it is used as a load balancer
+ owned by the router, a priority-60 flow matches ip4.dst
+ == A or ip6.dst == A and drops the traffic. An exception
+ is made and the above flow is not added if the router
+ port’s own IP address is used to SNAT packets passing
+ through that router or if it is used as a load balancer
VIP.
The flows above handle all of the traffic that might be directed to the
router itself. The following flows (with lower priorities) handle the
remaining traffic, potentially for forwarding:
- · Drop Ethernet local broadcast. A priority-50 flow with
+ • Drop Ethernet local broadcast. A priority-50 flow with
match eth.bcast drops traffic destined to the local Eth‐
ernet broadcast address. By definition this traffic
should not be forwarded.
- · ICMP time exceeded. For each router port P, whose IP
- address is A, a priority-100 flow with match inport == P
- &&&& ip.ttl == {0, 1} &&&& !ip.later_frag matches packets
- whose TTL has expired, with the following actions to send
- an ICMP time exceeded reply for IPv4 and IPv6 respec‐
- tively:
+ • Avoid ICMP time exceeded for multicast. A priority-32
+ flow with match ip.ttl == {0, 1} &&&& !ip.later_frag &&&&
+ (ip4.mcast || ip6.mcast) and actions drop; drops multi‐
+ cast packets whose TTL has expired without sending ICMP
+ time exceeded.
+
+ • ICMP time exceeded. For each router port P, whose IP ad‐
+ dress is A, a priority-31 flow with match inport == P &&&&
+ ip.ttl == {0, 1} &&&& !ip.later_frag matches packets whose
+ TTL has expired, with the following actions to send an
+ ICMP time exceeded reply for IPv4 and IPv6 respectively:
icmp4 {
icmp4.type = 11; /* Time exceeded. */
@@ -2332,12 +2504,12 @@
};
- · TTL discard. A priority-30 flow with match ip.ttl == {0,
- 1} and actions drop; drops other packets whose TTL has
+ • TTL discard. A priority-30 flow with match ip.ttl == {0,
+ 1} and actions drop; drops other packets whose TTL has
expired, that should not receive a ICMP error reply (i.e.
fragments with nonzero offset).
- · Next table. A priority-0 flows match all packets that
+ • Next table. A priority-0 flows match all packets that
aren’t already handled and uses actions next; to feed
them to the next table.
@@ -2349,14 +2521,14 @@
Ingress Table 4: UNSNAT on Gateway and Distributed Routers
- · If the Router (Gateway or Distributed) is configured with
+ • If the Router (Gateway or Distributed) is configured with
load balancers, then below lflows are added:
For each IPv4 address A defined as load balancer VIP with
the protocol P (and the protocol port T if defined) is
also present as an external_ip in the NAT table, a prior‐
- ity-120 logical flow is added with the match ip4 &&&&
- ip4.dst == A &&&& P with the action next; to advance the
+ ity-120 logical flow is added with the match ip4 &&&&
+ ip4.dst == A &&&& P with the action next; to advance the
packet to the next table. If the load balancer has proto‐
col port B defined, then the match also has P.dst == B.
@@ -2364,7 +2536,7 @@
Ingress Table 4: UNSNAT on Gateway Routers
- · If the Gateway router has been configured to force SNAT
+ • If the Gateway router has been configured to force SNAT
any previously DNATted packets to B, a priority-110 flow
matches ip &&&& ip4.dst == B or ip &&&& ip6.dst == B with an
action ct_snat; .
@@ -2378,53 +2550,38 @@
If the Gateway router has been configured to force SNAT
any previously load-balanced packets to B, a priority-100
- flow matches ip &&&& ip4.dst == B or ip &&&& ip6.dst == B
+ flow matches ip &&&& ip4.dst == B or ip &&&& ip6.dst == B
with an action ct_snat; .
- For each NAT configuration in the OVN Northbound data‐
- base, that asks to change the source IP address of a
- packet from A to B, a priority-90 flow matches ip &&&&
- ip4.dst == B or ip &&&& ip6.dst == B with an action
- ct_snat; . If the NAT rule is of type dnat_and_snat and
- has stateless=true in the options, then the action would
+ For each NAT configuration in the OVN Northbound data‐
+ base, that asks to change the source IP address of a
+ packet from A to B, a priority-90 flow matches ip &&&&
+ ip4.dst == B or ip &&&& ip6.dst == B with an action
+ ct_snat; . If the NAT rule is of type dnat_and_snat and
+ has stateless=true in the options, then the action would
be next;.
A priority-0 logical flow with match 1 has actions next;.
Ingress Table 4: UNSNAT on Distributed Routers
- · For each configuration in the OVN Northbound database,
- that asks to change the source IP address of a packet
+ • For each configuration in the OVN Northbound database,
+ that asks to change the source IP address of a packet
from A to B, two priority-100 flows are added.
- If the NAT rule cannot be handled in a distributed man‐
- ner, then the below priority-100 flows are only pro‐
+ If the NAT rule cannot be handled in a distributed man‐
+ ner, then the below priority-100 flows are only pro‐
grammed on the gateway chassis.
- · The first flow matches ip &&&& ip4.dst == B &&&&
- inport == GW &&&& flags.loopback == 0 or ip &&&&
- ip6.dst == B &&&& inport == GW &&&& flags.loopback ==
- 0 where GW is the distributed gateway port corre‐
- sponding to the NAT rule (specified or inferred),
- with an action ct_snat_in_czone; to unSNAT in the
- common zone. If the NAT rule is of type
- dnat_and_snat and has stateless=true in the
- options, then the action would be next;.
-
- If the NAT entry is of type snat, then there is an
- additional match is_chassis_resident(cr-GW)
- where cr-GW is the chassis resident port of GW.
-
- · The second flow matches ip &&&& ip4.dst == B &&&&
- inport == GW &&&& flags.loopback == 1 &&&&
- flags.use_snat_zone == 1 or ip &&&& ip6.dst == B &&&&
- inport == GW &&&& flags.loopback == 0 &&&&
- flags.use_snat_zone == 1 where GW is the distrib‐
- uted gateway port corresponding to the NAT rule
- (specified or inferred), with an action ct_snat;
- to unSNAT in the snat zone. If the NAT rule is of
- type dnat_and_snat and has stateless=true in the
- options, then the action would be ip4/6.dst=(B).
+ • The first flow matches ip &&&& ip4.dst == B &&&& in‐‐
+ port == GW
+ or ip &&&& ip6.dst == B &&&& inport == GW where GW is
+ the distributed gateway port corresponding to the
+ NAT rule (specified or inferred), with an action
+ ct_snat; to unSNAT in the common zone. If the NAT
+ rule is of type dnat_and_snat and has state‐‐
+ less=true in the options, then the action would be
+ next;.
If the NAT entry is of type snat, then there is an
additional match is_chassis_resident(cr-GW)
@@ -2434,31 +2591,19 @@
Ingress Table 5: DEFRAG
- This is to send packets to connection tracker for tracking and defrag‐
- mentation. It contains a priority-0 flow that simply moves traffic to
+ This is to send packets to connection tracker for tracking and defrag‐
+ mentation. It contains a priority-0 flow that simply moves traffic to
the next table.
- If load balancing rules with only virtual IP addresses are configured
- in OVN_Northbound database for a Gateway router, a priority-100 flow is
- added for each configured virtual IP address VIP. For IPv4 VIPs the
- flow matches ip &&&& ip4.dst == VIP. For IPv6 VIPs, the flow matches ip
- &&&& ip6.dst == VIP. The flow applies the action reg0 = VIP; ct_dnat; (or
- xxreg0 for IPv6) to send IP packets to the connection tracker for
- packet de-fragmentation and to dnat the destination IP for the commit‐
- ted connection before sending it to the next table.
-
- If load balancing rules with virtual IP addresses and ports are config‐
- ured in OVN_Northbound database for a Gateway router, a priority-110
- flow is added for each configured virtual IP address VIP, protocol
- PROTO and port PORT. For IPv4 VIPs the flow matches ip &&&& ip4.dst ==
- VIP &&&& PROTO &&&& PROTO.dst == PORT. For IPv6 VIPs, the flow matches ip
- &&&& ip6.dst == VIP &&&& PROTO &&&& PROTO.dst == PORT. The flow applies the
- action reg0 = VIP; reg9[16..31] = PROTO.dst; ct_dnat; (or xxreg0 for
- IPv6) to send IP packets to the connection tracker for packet de-frag‐
- mentation and to dnat the destination IP for the committed connection
- before sending it to the next table.
-
- If ECMP routes with symmetric reply are configured in the OVN_North‐
+ For all load balancing rules that are configured in OVN_Northbound
+ database for a Gateway router, a priority-100 flow is added for each
+ configured virtual IP address VIP. For IPv4 VIPs the flow matches ip &&&&
+ ip4.dst == VIP. For IPv6 VIPs, the flow matches ip &&&& ip6.dst == VIP.
+ The flow applies the action ct_dnat; to send IP packets to the connec‐
+ tion tracker for packet de-fragmentation and to dnat the destination IP
+ for the committed connection before sending it to the next table.
+
+ If ECMP routes with symmetric reply are configured in the OVN_North‐‐
bound database for a gateway router, a priority-100 flow is added for
each router port on which symmetric replies are configured. The match‐
ing logic for these ports essentially reverses the configured logic of
@@ -2467,7 +2612,7 @@
route’s prefix. The flow uses the actions chk_ecmp_nh_mac(); ct_next or
chk_ecmp_nh(); ct_next to send IP packets to table 76 or to table 77 in
order to check if source info are already stored by OVN and then to the
- connection tracker for packet de-fragmentation and tracking before
+ connection tracker for packet de-fragmentation and tracking before
sending it to the next table.
If load balancing rules are configured in OVN_Northbound database for a
@@ -2480,16 +2625,17 @@
Load balancing affinity check table contains the following logical
flows:
- · For all the configured load balancing rules for a logical
- router where a positive affinity timeout is specified in
- options column, that includes a L4 port PORT of protocol
- P and IPv4 or IPv6 address VIP, a priority-100 flow that
- matches on ct.new &&&& ip &&&& reg0 == VIP &&&& P &&&&
- reg9[16..31] == PORT (xxreg0 == VIP
- in the IPv6 case) with an action of reg9[6] =
- chk_lb_aff(); next;
-
- · A priority 0 flow is added which matches on all packets
+ • For all the configured load balancing rules for a logical
+ router where a positive affinity timeout is specified in
+ options column, that includes a L4 port PORT of protocol
+ P and IPv4 or IPv6 address VIP, a priority-100 flow that
+ matches on ct.new &&&& ip &&&& ip.dst == VIP &&&& P &&&& P.dst ==
+ PORT (xxreg0 == VIP
+ in the IPv6 case) with an action of reg0 = ip.dst;
+ reg9[16..31] = P.dst; reg9[6] = chk_lb_aff(); next;
+ (xxreg0 == ip6.dst in the IPv6 case)
+
+ • A priority 0 flow is added which matches on all packets
and applies the action next;.
Ingress Table 7: DNAT
@@ -2505,136 +2651,103 @@
way chassis. These flows do not get programmed for load balancers with
IPv6 VIPs.
- · For all the configured load balancing rules for a logical
- router where a positive affinity timeout is specified in
- options column, that includes a L4 port PORT of protocol
- P and IPv4 or IPv6 address VIP, a priority-150 flow that
- matches on reg9[6] == 1 &&&& ct.new &&&& ip &&&& reg0 == VIP &&&&
- P &&&& reg9[16..31] == PORT (xxreg0 == VIP in the IPv6
- case) with an action of ct_lb_mark(args) , where args
- contains comma separated IP addresses (and optional port
- numbers) to load balance to. The address family of the IP
- addresses of args is the same as the address family of
- VIP.
-
- · If controller_event has been enabled for all the config‐
+ • For all the configured load balancing rules for a logical
+ router where a positive affinity timeout is specified in
+ options column, that includes a L4 port PORT of protocol
+ P and IPv4 or IPv6 address VIP, a priority-150 flow that
+ matches on reg9[6] == 1 &&&& ct.new &&&& ip &&&& ip.dst == VIP
+ &&&& P &&&& P.dst == PORT with an action of ct_lb_mark(args)
+ , where args contains comma separated IP addresses (and
+ optional port numbers) to load balance to. The address
+ family of the IP addresses of args is the same as the ad‐
+ dress family of VIP.
+
+ • If controller_event has been enabled for all the config‐
ured load balancing rules for a Gateway router or Router
with gateway port in OVN_Northbound database that does
not have configured backends, a priority-130 flow is
added to trigger ovn-controller events whenever the chas‐
sis receives a packet for that particular VIP. If
- event-elb meter has been previously created, it will be
+ event-elb meter has been previously created, it will be
associated to the empty_lb logical flow
- · For all the configured load balancing rules for a Gateway
+ • For all the configured load balancing rules for a Gateway
router or Router with gateway port in OVN_Northbound
database that includes a L4 port PORT of protocol P and
IPv4 or IPv6 address VIP, a priority-120 flow that
- matches on ct.new &&&& !ct.rel &&&& ip &&&& reg0 == VIP &&&& P &&&&
- reg9[16..31] ==
- PORT (xxreg0 == VIP
- in the IPv6 case) with an action of ct_lb_mark(args),
- where args contains comma separated IPv4 or IPv6
- addresses (and optional port numbers) to load balance to.
- If the router is configured to force SNAT any load-bal‐
- anced packets, the above action will be replaced by
- flags.force_snat_for_lb = 1; ct_lb_mark(args);. If the
- load balancing rule is configured with skip_snat set to
- true, the above action will be replaced by
- flags.skip_snat_for_lb = 1; ct_lb_mark(args);. If health
- check is enabled, then args will only contain those end‐
- points whose service monitor status entry in OVN_South‐
- bound db is either online or empty.
-
- The previous table lr_in_defrag sets the register reg0
- (or xxreg0 for IPv6) and does ct_dnat. Hence for estab‐
- lished traffic, this table just advances the packet to
- the next stage.
-
- · For all the configured load balancing rules for a router
- in OVN_Northbound database that includes a L4 port PORT
- of protocol P and IPv4 or IPv6 address VIP, a prior‐
- ity-120 flow that matches on ct.est &&&& !ct.rel &&&& ip4 &&&&
- reg0 == VIP &&&& P &&&& reg9[16..31] ==
- PORT (ip6 and xxreg0 == VIP in the IPv6 case) with an
- action of next;. If the router is configured to force
- SNAT any load-balanced packets, the above action will be
- replaced by flags.force_snat_for_lb = 1; next;. If the
- load balancing rule is configured with skip_snat set to
- true, the above action will be replaced by
- flags.skip_snat_for_lb = 1; next;.
-
- The previous table lr_in_defrag sets the register reg0
- (or xxreg0 for IPv6) and does ct_dnat. Hence for estab‐
- lished traffic, this table just advances the packet to
- the next stage.
-
- · For all the configured load balancing rules for a router
- in OVN_Northbound database that includes just an IP
- address VIP to match on, a priority-110 flow that matches
- on ct.new &&&& !ct.rel &&&& ip4 &&&& reg0 == VIP (ip6 and
- xxreg0 == VIP in the IPv6 case) with an action of
- ct_lb_mark(args), where args contains comma separated
- IPv4 or IPv6 addresses. If the router is configured to
- force SNAT any load-balanced packets, the above action
- will be replaced by flags.force_snat_for_lb = 1;
- ct_lb_mark(args);. If the load balancing rule is config‐
- ured with skip_snat set to true, the above action will be
- replaced by flags.skip_snat_for_lb = 1;
- ct_lb_mark(args);.
-
- The previous table lr_in_defrag sets the register reg0
- (or xxreg0 for IPv6) and does ct_dnat. Hence for estab‐
- lished traffic, this table just advances the packet to
- the next stage.
-
- · For all the configured load balancing rules for a router
- in OVN_Northbound database that includes just an IP
- address VIP to match on, a priority-110 flow that matches
- on ct.est &&&& !ct.rel &&&& ip4 &&&& reg0 == VIP (or ip6 and
- xxreg0 == VIP) with an action of next;. If the router is
+ matches on ct.new &&&& !ct.rel &&&& ip &&&& ip.dst == VIP &&&& P
+ &&&& P.dst ==
+ PORT with an action of ct_lb_mark(args), where args con‐
+ tains comma separated IPv4 or IPv6 addresses (and op‐
+ tional port numbers) to load balance to. If the router is
configured to force SNAT any load-balanced packets, the
above action will be replaced by flags.force_snat_for_lb
- = 1; next;. If the load balancing rule is configured with
- skip_snat set to true, the above action will be replaced
- by flags.skip_snat_for_lb = 1; next;.
+ = 1; ct_lb_mark(args; force_snat);. If the load balancing
+ rule is configured with skip_snat set to true, the above
+ action will be replaced by flags.skip_snat_for_lb = 1;
+ ct_lb_mark(args; skip_snat);. If health check is enabled,
+ then args will only contain those endpoints whose service
+ monitor status entry in OVN_Southbound db is either on‐‐
+ line or empty.
+
+ • For all the configured load balancing rules for a router
+ in OVN_Northbound database that includes just an IP ad‐
+ dress VIP to match on, a priority-110 flow that matches
+ on ct.new &&&& !ct.rel &&&& ip4 &&&& ip.dst == VIP with an ac‐
+ tion of ct_lb_mark(args), where args contains comma sepa‐
+ rated IPv4 or IPv6 addresses. If the router is configured
+ to force SNAT any load-balanced packets, the above action
+ will be replaced by flags.force_snat_for_lb = 1;
+ ct_lb_mark(args; force_snat);. If the load balancing rule
+ is configured with skip_snat set to true, the above ac‐
+ tion will be replaced by flags.skip_snat_for_lb = 1;
+ ct_lb_mark(args; skip_snat);.
The previous table lr_in_defrag sets the register reg0
(or xxreg0 for IPv6) and does ct_dnat. Hence for estab‐
lished traffic, this table just advances the packet to
the next stage.
- · If the load balancer is created with --reject option and
+ • If the load balancer is created with --reject option and
it has no active backends, a TCP reset segment (for tcp)
or an ICMP port unreachable packet (for all other kind of
- traffic) will be sent whenever an incoming packet is
- received for this load-balancer. Please note using
- --reject option will disable empty_lb SB controller event
- for this load balancer.
+ traffic) will be sent whenever an incoming packet is re‐
+ ceived for this load-balancer. Please note using --reject
+ option will disable empty_lb SB controller event for this
+ load balancer.
- · For the related traffic, a priority 50 flow that matches
- ct.rel &&&& !ct.est &&&& !ct.new with an action of ct_com‐
+ • For the related traffic, a priority 50 flow that matches
+ ct.rel &&&& !ct.est &&&& !ct.new with an action of ct_com‐‐
mit_nat;, if the router has load balancer assigned to it.
Along with two priority 70 flows that match skip_snat and
- force_snat flags.
+ force_snat flags, setting the flags.force_snat_for_lb = 1
+ or flags.skip_snat_for_lb = 1 accordingly.
+
+ • For the established traffic, a priority 50 flow that
+ matches ct.est &&&& !ct.rel &&&& !ct.new &&&& ct_mark.natted
+ with an action of next;, if the router has load balancer
+ assigned to it. Along with two priority 70 flows that
+ match skip_snat and force_snat flags, setting the
+ flags.force_snat_for_lb = 1 or flags.skip_snat_for_lb = 1
+ accordingly.
Ingress Table 7: DNAT on Gateway Routers
- · For each configuration in the OVN Northbound database,
+ • For each configuration in the OVN Northbound database,
that asks to change the destination IP address of a
packet from A to B, a priority-100 flow matches ip &&&&
ip4.dst == A or ip &&&& ip6.dst == A with an action
flags.loopback = 1; ct_dnat(B);. If the Gateway router is
- configured to force SNAT any DNATed packet, the above
- action will be replaced by flags.force_snat_for_dnat = 1;
+ configured to force SNAT any DNATed packet, the above ac‐
+ tion will be replaced by flags.force_snat_for_dnat = 1;
flags.loopback = 1; ct_dnat(B);. If the NAT rule is of
type dnat_and_snat and has stateless=true in the options,
then the action would be ip4/6.dst= (B).
- If the NAT rule has allowed_ext_ips configured, then
+ If the NAT rule has allowed_ext_ips configured, then
there is an additional match ip4.src == allowed_ext_ips .
- Similarly, for IPV6, match would be ip6.src ==
- allowed_ext_ips.
+ Similarly, for IPV6, match would be ip6.src == al
+ lowed_ext_ips.
If the NAT rule has exempted_ext_ips set, then there is
an additional flow configured at priority 101. The flow
@@ -2642,7 +2755,7 @@
is next; . This flow is used to bypass the ct_dnat action
for a packet originating from exempted_ext_ips.
- · A priority-0 logical flow with match 1 has actions next;.
+ • A priority-0 logical flow with match 1 has actions next;.
Ingress Table 7: DNAT on Distributed Routers
@@ -2651,24 +2764,24 @@
a real IP address. The unDNAT processing in the reverse direction is
handled in a separate table in the egress pipeline.
- · For each configuration in the OVN Northbound database,
+ • For each configuration in the OVN Northbound database,
that asks to change the destination IP address of a
packet from A to B, a priority-100 flow matches ip &&&&
ip4.dst == B &&&& inport == GW, where GW is the logical
router gateway port corresponding to the NAT rule (speci‐
- fied or inferred), with an action ct_dnat(B);. The match
- will include ip6.dst == B in the IPv6 case. If the NAT
- rule is of type dnat_and_snat and has stateless=true in
+ fied or inferred), with an action ct_dnat(B);. The match
+ will include ip6.dst == B in the IPv6 case. If the NAT
+ rule is of type dnat_and_snat and has stateless=true in
the options, then the action would be ip4/6.dst=(B).
- If the NAT rule cannot be handled in a distributed man‐
- ner, then the priority-100 flow above is only programmed
+ If the NAT rule cannot be handled in a distributed man‐
+ ner, then the priority-100 flow above is only programmed
on the gateway chassis.
- If the NAT rule has allowed_ext_ips configured, then
+ If the NAT rule has allowed_ext_ips configured, then
there is an additional match ip4.src == allowed_ext_ips .
- Similarly, for IPV6, match would be ip6.src ==
- allowed_ext_ips.
+ Similarly, for IPV6, match would be ip6.src == al
+ lowed_ext_ips.
If the NAT rule has exempted_ext_ips set, then there is
an additional flow configured at priority 101. The flow
@@ -2683,43 +2796,43 @@
Load balancing affinity learn table contains the following logical
flows:
- · For all the configured load balancing rules for a logical
- router where a positive affinity timeout T is specified
+ • For all the configured load balancing rules for a logical
+ router where a positive affinity timeout T is specified
in options
- column, that includes a L4 port PORT of protocol P and
- IPv4 or IPv6 address VIP, a priority-100 flow that
+ column, that includes a L4 port PORT of protocol P and
+ IPv4 or IPv6 address VIP, a priority-100 flow that
matches on reg9[6] == 0 &&&& ct.new &&&& ip &&&& reg0 == VIP &&&&
P &&&& reg9[16..31] == PORT (xxreg0 == VIP in the IPv6
case) with an action of commit_lb_aff(vip = VIP:PORT,
backend = backend ip: backend port, proto = P, timeout =
T);.
- · A priority 0 flow is added which matches on all packets
+ • A priority 0 flow is added which matches on all packets
and applies the action next;.
Ingress Table 9: ECMP symmetric reply processing
- · If ECMP routes with symmetric reply are configured in the
- OVN_Northbound database for a gateway router, a prior‐
- ity-100 flow is added for each router port on which sym‐
- metric replies are configured. The matching logic for
- these ports essentially reverses the configured logic of
- the ECMP route. So for instance, a route with a destina‐
- tion routing policy will instead match if the source IP
- address matches the static route’s prefix. The flow uses
- the action ct_commit { ct_label.ecmp_reply_eth =
- eth.src;" " ct_mark.ecmp_reply_port = K;}; com‐
+ • If ECMP routes with symmetric reply are configured in the
+ OVN_Northbound database for a gateway router, a prior‐
+ ity-100 flow is added for each router port on which sym‐
+ metric replies are configured. The matching logic for
+ these ports essentially reverses the configured logic of
+ the ECMP route. So for instance, a route with a destina‐
+ tion routing policy will instead match if the source IP
+ address matches the static route’s prefix. The flow uses
+ the action ct_commit { ct_label.ecmp_reply_eth =
+ eth.src;" " ct_mark.ecmp_reply_port = K;}; com‐‐
mit_ecmp_nh(); next;
- to commit the connection and storing eth.src and the
- ECMP reply port binding tunnel key K in the ct_label and
+ to commit the connection and storing eth.src and the
+ ECMP reply port binding tunnel key K in the ct_label and
the traffic pattern to table 76 or 77.
Ingress Table 10: IPv6 ND RA option processing
- · A priority-50 logical flow is added for each logical
- router port configured with IPv6 ND RA options which
- matches IPv6 ND Router Solicitation packet and applies
- the action put_nd_ra_opts and advances the packet to the
+ • A priority-50 logical flow is added for each logical
+ router port configured with IPv6 ND RA options which
+ matches IPv6 ND Router Solicitation packet and applies
+ the action put_nd_ra_opts and advances the packet to the
next table.
reg0[5] = put_nd_ra_opts(options);next;
@@ -2731,14 +2844,14 @@
packets, it just stores 0 into reg0[5]. Either way, it
continues to the next table.
- · A priority-0 logical flow with match 1 has actions next;.
+ • A priority-0 logical flow with match 1 has actions next;.
Ingress Table 11: IPv6 ND RA responder
This table implements IPv6 ND RA responder for the IPv6 ND RA replies
generated by the previous table.
- · A priority-50 logical flow is added for each logical
+ • A priority-50 logical flow is added for each logical
router port configured with IPv6 ND RA options which
matches IPv6 ND RA packets and reg0[5] == 1 and responds
back to the inport after applying these actions. If
@@ -2760,7 +2873,7 @@
(This terminates packet processing in ingress pipeline;
the packet does not go to the next ingress table.)
- · A priority-0 logical flow with match 1 has actions next;.
+ • A priority-0 logical flow with match 1 has actions next;.
Ingress Table 12: IP Routing Pre
@@ -2773,7 +2886,7 @@
This table contains the following logical flows:
- · Priority-100 flow with match inport == "LRP_NAME" value
+ • Priority-100 flow with match inport == "LRP_NAME" value
and action, which set route table identifier in reg7.
A priority-0 logical flow with match 1 has actions reg7 =
@@ -2781,9 +2894,9 @@
Ingress Table 13: IP Routing
- A packet that arrives at this table is an IP packet that should be
- routed to the address in ip4.dst or ip6.dst. This table implements IP
- routing, setting reg0 (or xxreg0 for IPv6) to the next-hop IP address
+ A packet that arrives at this table is an IP packet that should be
+ routed to the address in ip4.dst or ip6.dst. This table implements IP
+ routing, setting reg0 (or xxreg0 for IPv6) to the next-hop IP address
(leaving ip4.dst or ip6.dst, the packet’s final destination, unchanged)
and advances to the next table for ARP resolution. It also sets reg1
(or xxreg1) to the IP address owned by the selected router port
@@ -2797,12 +2910,12 @@
id and select a member id within the group based on 5-tuple hashing. It
stores group id in reg8[0..15] and member id in reg8[16..31]. This step
is skipped with a priority-10300 rule if the traffic going out the ECMP
- route is reply traffic, and the ECMP route was configured to use sym‐
- metric replies. Instead, the stored values in conntrack is used to
- choose the destination. The ct_label.ecmp_reply_eth tells the destina‐
- tion MAC address to which the packet should be sent. The
- ct_mark.ecmp_reply_port tells the logical router port on which the
- packet should be sent. These values saved to the conntrack fields when
+ route is reply traffic, and the ECMP route was configured to use sym‐
+ metric replies. Instead, the stored values in conntrack is used to
+ choose the destination. The ct_label.ecmp_reply_eth tells the destina‐
+ tion MAC address to which the packet should be sent. The
+ ct_mark.ecmp_reply_port tells the logical router port on which the
+ packet should be sent. These values saved to the conntrack fields when
the initial ingress traffic is received over the ECMP route and commit‐
ted to conntrack. If REGBIT_KNOWN_ECMP_NH is set, the priority-10300
flows in this stage set the outport, while the eth.dst is set by flows
@@ -2810,37 +2923,37 @@
This table contains the following logical flows:
- · Priority-10550 flow that drops IPv6 Router Solicita‐
+ • Priority-10550 flow that drops IPv6 Router Solicita‐
tion/Advertisement packets that were not processed in
previous tables.
- · Priority-10550 flows that drop IGMP and MLD packets with
+ • Priority-10550 flows that drop IGMP and MLD packets with
source MAC address owned by the router. These are used to
prevent looping statically forwarded IGMP and MLD packets
for which TTL is not decremented (it is always 1).
- · Priority-10500 flows that match IP multicast traffic des‐
+ • Priority-10500 flows that match IP multicast traffic des‐
tined to groups registered on any of the attached
- switches and sets outport to the associated multicast
- group that will eventually flood the traffic to all
- interested attached logical switches. The flows also
- decrement TTL.
+ switches and sets outport to the associated multicast
+ group that will eventually flood the traffic to all in‐
+ terested attached logical switches. The flows also decre‐
+ ment TTL.
- · Priority-10460 flows that match IGMP and MLD control
+ • Priority-10460 flows that match IGMP and MLD control
packets, set outport to the MC_STATIC multicast group,
which ovn-northd populates with the logical ports that
- have options :mcast_flood=’true’. If no router ports are
+ have options :mcast_flood=’’true’’. If no router ports are
configured to flood multicast traffic the packets are
dropped.
- · Priority-10450 flow that matches unregistered IP multi‐
+ • Priority-10450 flow that matches unregistered IP multi‐
cast traffic decrements TTL and sets outport to the
MC_STATIC multicast group, which ovn-northd populates
with the logical ports that have options
- :mcast_flood=’true’. If no router ports are configured to
+ :mcast_flood=’’true’’. If no router ports are configured to
flood multicast traffic the packets are dropped.
- · IPv4 routing table. For each route to IPv4 network N with
+ • IPv4 routing table. For each route to IPv4 network N with
netmask M, on router port P with IP address A and Ether‐
net address E, a logical flow with match ip4.dst == N/M,
whose priority is the number of 1-bits in M, has the fol‐
@@ -2863,8 +2976,8 @@
Instead, if the route is from a configured static route,
G is the next hop IP address. Else it is ip4.dst.
- · IPv6 routing table. For each route to IPv6 network N with
- netmask M, on router port P with IP address A and Ether‐
+ • IPv6 routing table. For each route to IPv6 network N with
+ netmask M, on router port P with IP address A and Ether‐
net address E, a logical flow with match in CIDR notation
ip6.dst == N/M, whose priority is the integer value of M,
has the following actions:
@@ -2896,19 +3009,19 @@
0.
For each connected route (route to the LRP’s subnet CIDR)
- the logical flow match portion has no reg7 == id &&&& pre‐
+ the logical flow match portion has no reg7 == id &&&& pre‐
fix to have route to LRP’s subnets in all routing tables.
- · For ECMP routes, they are grouped by policy and prefix.
- An unique id (non-zero) is assigned to each group, and
- each member is also assigned an unique id (non-zero)
+ • For ECMP routes, they are grouped by policy and prefix.
+ An unique id (non-zero) is assigned to each group, and
+ each member is also assigned an unique id (non-zero)
within each group.
- For each IPv4/IPv6 ECMP group with group id GID and mem‐
- ber ids MID1, MID2, ..., a logical flow with match in
- CIDR notation ip4.dst == N/M, or ip6.dst == N/M, whose
- priority is the integer value of M, has the following
- actions:
+ For each IPv4/IPv6 ECMP group with group id GID and mem‐
+ ber ids MID1, MID2, ..., a logical flow with match in
+ CIDR notation ip4.dst == N/M, or ip6.dst == N/M, whose
+ priority is the integer value of M, has the following ac‐
+ tions:
ip.ttl--;
flags.loopback = 1;
@@ -2916,7 +3029,7 @@
select(reg8[16..31], MID1, MID2, ...);
- · A priority-0 logical flow that matches all packets not
+ • A priority-0 logical flow that matches all packets not
already handled (match 1) and drops them (action drop;).
Ingress Table 14: IP_ROUTING_ECMP
@@ -2937,11 +3050,11 @@
This table contains the following logical flows:
- · A priority-150 flow that matches reg8[0..15] == 0 with
+ • A priority-150 flow that matches reg8[0..15] == 0 with
action next; directly bypasses packets of non-ECMP
routes.
- · For each member with ID MID in each ECMP group with ID
+ • For each member with ID MID in each ECMP group with ID
GID, a priority-100 flow with match reg8[0..15] == GID &&&&
reg8[16..31] == MID has following actions:
@@ -2951,20 +3064,20 @@
outport = P;
- · A priority-0 logical flow that matches all packets not
+ • A priority-0 logical flow that matches all packets not
already handled (match 1) and drops them (action drop;).
Ingress Table 15: Router policies
This table adds flows for the logical router policies configured on the
- logical router. Please see the OVN_Northbound database Logi‐
+ logical router. Please see the OVN_Northbound database Logi‐‐
cal_Router_Policy table documentation in ovn-nb for supported actions.
- · For each router policy configured on the logical router,
+ • For each router policy configured on the logical router,
a logical flow is added with specified priority, match
and actions.
- · If the policy action is reroute with 2 or more nexthops
+ • If the policy action is reroute with 2 or more nexthops
defined, then the logical flow is added with the follow‐
ing actions:
@@ -2975,12 +3088,12 @@
where GID is the ECMP group id generated by ovn-northd
for this policy and n is the number of nexthops. select
action selects one of the nexthop member id, stores it in
- the register reg8[16..31] and advances the packet to the
+ the register reg8[16..31] and advances the packet to the
next stage.
- · If the policy action is reroute with just one nexhop,
- then the logical flow is added with the following
- actions:
+ • If the policy action is reroute with just one nexhop,
+ then the logical flow is added with the following ac‐
+ tions:
[xx]reg0 = H;
eth.src = E;
@@ -2990,30 +3103,30 @@
next;
- where H is the nexthop defined in the router policy, E
- is the ethernet address of the logical router port from
- which the nexthop is reachable and P is the logical
+ where H is the nexthop defined in the router policy, E
+ is the ethernet address of the logical router port from
+ which the nexthop is reachable and P is the logical
router port from which the nexthop is reachable.
- · If a router policy has the option pkt_mark=m set and if
- the action is not drop, then the action also includes
+ • If a router policy has the option pkt_mark=m set and if
+ the action is not drop, then the action also includes
pkt.mark = m to mark the packet with the marker m.
Ingress Table 16: ECMP handling for router policies
- This table handles the ECMP for the router policies configured with
+ This table handles the ECMP for the router policies configured with
multiple nexthops.
- · A priority-150 flow is added to advance the packet to the
+ • A priority-150 flow is added to advance the packet to the
next stage if the ECMP group id register reg8[0..15] is
0.
- · For each ECMP reroute router policy with multiple nex‐
+ • For each ECMP reroute router policy with multiple nex‐
thops, a priority-100 flow is added for each nexthop H
with the match reg8[0..15] == GID &&&& reg8[16..31] == M
where GID is the router policy group id generated by
ovn-northd and M is the member id of the nexthop H gener‐
- ated by ovn-northd. The following actions are added to
+ ated by ovn-northd. The following actions are added to
the flow:
[xx]reg0 = H;
@@ -3023,151 +3136,144 @@
"next;"
- where H is the nexthop defined in the router policy, E
- is the ethernet address of the logical router port from
- which the nexthop is reachable and P is the logical
+ where H is the nexthop defined in the router policy, E
+ is the ethernet address of the logical router port from
+ which the nexthop is reachable and P is the logical
router port from which the nexthop is reachable.
- · A priority-0 logical flow that matches all packets not
+ • A priority-0 logical flow that matches all packets not
already handled (match 1) and drops them (action drop;).
Ingress Table 17: ARP/ND Resolution
- Any packet that reaches this table is an IP packet whose next-hop IPv4
- address is in reg0 or IPv6 address is in xxreg0. (ip4.dst or ip6.dst
- contains the final destination.) This table resolves the IP address in
+ Any packet that reaches this table is an IP packet whose next-hop IPv4
+ address is in reg0 or IPv6 address is in xxreg0. (ip4.dst or ip6.dst
+ contains the final destination.) This table resolves the IP address in
reg0 (or xxreg0) into an output port in outport and an Ethernet address
in eth.dst, using the following flows:
- · A priority-500 flow that matches IP multicast traffic
+ • A priority-500 flow that matches IP multicast traffic
that was allowed in the routing pipeline. For this kind
of traffic the outport was already set so the flow just
advances to the next table.
- · Priority-200 flows that match ECMP reply traffic for the
+ • Priority-200 flows that match ECMP reply traffic for the
routes configured to use symmetric replies, with actions
push(xxreg1); xxreg1 = ct_label; eth.dst =
xxreg1[32..79]; pop(xxreg1); next;. xxreg1 is used here
to avoid masked access to ct_label, to make the flow HW-
offloading friendly.
- · Static MAC bindings. MAC bindings can be known statically
- based on data in the OVN_Northbound database. For router
- ports connected to logical switches, MAC bindings can be
- known statically from the addresses column in the Logi‐
- cal_Switch_Port table. For router ports connected to
- other logical routers, MAC bindings can be known stati‐
- cally from the mac and networks column in the Logi‐
- cal_Router_Port table. (Note: the flow is NOT installed
- for the IP addresses that belong to a neighbor logical
- router port if the current router has the
- options:dynamic_neigh_routers set to true)
+ • Static MAC bindings. MAC bindings can be known statically
+ based on data in the OVN_Northbound database. For router
+ ports connected to logical switches, MAC bindings can be
+ known statically from the addresses column in the Logi‐‐
+ cal_Switch_Port table. (Note: the flow is not installed
+ for IPs of logical switch ports of type virtual, and dy‐
+ namic MAC binding is used for those IPs instead, so that
+ virtual parent failover does not depend on ovn-northd, to
+ achieve better failover performance.) For router ports
+ connected to other logical routers, MAC bindings can be
+ known statically from the mac and networks column in the
+ Logical_Router_Port table. (Note: the flow is NOT in‐
+ stalled for the IP addresses that belong to a neighbor
+ logical router port if the current router has the op‐‐
+ tions:dynamic_neigh_routers set to true)
For each IPv4 address A whose host is known to have Eth‐
ernet address E on router port P, a priority-100 flow
with match outport === P &&&& reg0 == A has actions eth.dst
= E; next;.
- For each virtual ip A configured on a logical port of
- type virtual and its virtual parent set in its corre‐
- sponding Port_Binding record and the virtual parent with
- the Ethernet address E and the virtual ip is reachable
- via the router port P, a priority-100 flow with match
- outport === P &&&& xxreg0/reg0 == A has actions eth.dst =
- E; next;.
-
- For each virtual ip A configured on a logical port of
- type virtual and its virtual parent not set in its corre‐
- sponding Port_Binding record and the virtual ip A is
- reachable via the router port P, a priority-100 flow with
- match outport === P &&&& xxreg0/reg0 == A has actions
- eth.dst = 00:00:00:00:00:00; next;. This flow is added so
- that the ARP is always resolved for the virtual ip A by
- generating ARP request and not consulting the MAC_Binding
- table as it can have incorrect value for the virtual ip
- A.
-
For each IPv6 address A whose host is known to have Eth‐
ernet address E on router port P, a priority-100 flow
with match outport === P &&&& xxreg0 == A has actions
eth.dst = E; next;.
For each logical router port with an IPv4 address A and a
- mac address of E that is reachable via a different logi‐
+ mac address of E that is reachable via a different logi‐
cal router port P, a priority-100 flow with match outport
=== P &&&& reg0 == A has actions eth.dst = E; next;.
For each logical router port with an IPv6 address A and a
- mac address of E that is reachable via a different logi‐
+ mac address of E that is reachable via a different logi‐
cal router port P, a priority-100 flow with match outport
=== P &&&& xxreg0 == A has actions eth.dst = E; next;.
- · Static MAC bindings from NAT entries. MAC bindings can
+ • Static MAC bindings from NAT entries. MAC bindings can
also be known for the entries in the NAT table. Below
flows are programmed for distributed logical routers i.e
with a distributed router port.
For each row in the NAT table with IPv4 address A in the
- external_ip column of NAT table, a priority-100 flow with
- the match outport === P &&&& reg0 == A has actions eth.dst
- = E; next;, where P is the distributed logical router
- port, E is the Ethernet address if set in the exter‐
- nal_mac column of NAT table for of type dnat_and_snat,
- otherwise the Ethernet address of the distributed logical
- router port. Note that if the external_ip is not within a
- subnet on the owning logical router, then OVN will only
- create ARP resolution flows if the options:add_route is
- set to true. Otherwise, no ARP resolution flows will be
- added.
+ external_ip column of NAT table, below two flows are pro‐
+ grammed:
+
+ A priority-100 flow with the match outport == P &&&& reg0
+ == A has actions eth.dst = E; next;, where P is the dis‐
+ tributed logical router port, E is the Ethernet address
+ if set in the external_mac column of NAT table for of
+ type dnat_and_snat, otherwise the Ethernet address of the
+ distributed logical router port. Note that if the exter‐‐
+ nal_ip is not within a subnet on the owning logical
+ router, then OVN will only create ARP resolution flows if
+ the options:add_route is set to true. Otherwise, no ARP
+ resolution flows will be added.
+
+ Corresponding to the above flow, a priority-150 flow with
+ the match inport == P &&&& outport == P &&&& ip4.dst == A has
+ actions drop; to exclude packets that have gone through
+ DNAT/unSNAT stage but failed to convert the destination,
+ to avoid loop.
For IPv6 NAT entries, same flows are added, but using the
- register xxreg0 for the match.
+ register xxreg0 and field ip6 for the match.
- · If the router datapath runs a port with redirect-type set
- to bridged, for each distributed NAT rule with IP A in
- the logical_ip column and logical port P in the logi‐
+ • If the router datapath runs a port with redirect-type set
+ to bridged, for each distributed NAT rule with IP A in
+ the logical_ip column and logical port P in the logi‐‐
cal_port column of NAT table, a priority-90 flow with the
- match outport == Q &&&& ip.src === A &&&& is_chassis_resi‐
+ match outport == Q &&&& ip.src === A &&&& is_chassis_resi‐‐
dent(P), where Q is the distributed logical router port
and action get_arp(outport, reg0); next; for IPv4 and
get_nd(outport, xxreg0); next; for IPv6.
- · Traffic with IP destination an address owned by the
+ • Traffic with IP destination an address owned by the
router should be dropped. Such traffic is normally
dropped in ingress table IP Input except for IPs that are
- also shared with SNAT rules. However, if there was no
- unSNAT operation that happened successfully until this
+ also shared with SNAT rules. However, if there was no un‐
+ SNAT operation that happened successfully until this
point in the pipeline and the destination IP of the
packet is still a router owned IP, the packets can be
safely dropped.
A priority-2 logical flow with match ip4.dst = {..}
- matches on traffic destined to router owned IPv4
- addresses which are also SNAT IPs. This flow has action
+ matches on traffic destined to router owned IPv4 ad‐
+ dresses which are also SNAT IPs. This flow has action
drop;.
A priority-2 logical flow with match ip6.dst = {..}
- matches on traffic destined to router owned IPv6
- addresses which are also SNAT IPs. This flow has action
+ matches on traffic destined to router owned IPv6 ad‐
+ dresses which are also SNAT IPs. This flow has action
drop;.
A priority-0 logical that flow matches all packets not
already handled (match 1) and drops them (action drop;).
- · Dynamic MAC bindings. These flows resolve MAC-to-IP bind‐
- ings that have become known dynamically through ARP or
- neighbor discovery. (The ingress table ARP Request will
- issue an ARP or neighbor solicitation request for cases
+ • Dynamic MAC bindings. These flows resolve MAC-to-IP bind‐
+ ings that have become known dynamically through ARP or
+ neighbor discovery. (The ingress table ARP Request will
+ issue an ARP or neighbor solicitation request for cases
where the binding is not yet known.)
- A priority-0 logical flow with match ip4 has actions
+ A priority-0 logical flow with match ip4 has actions
get_arp(outport, reg0); next;.
- A priority-0 logical flow with match ip6 has actions
+ A priority-0 logical flow with match ip6 has actions
get_nd(outport, xxreg0); next;.
- · For a distributed gateway LRP with redirect-type set to
- bridged, a priority-50 flow will match outport ==
+ • For a distributed gateway LRP with redirect-type set to
+ bridged, a priority-50 flow will match outport ==
"ROUTER_PORT" and !is_chassis_resident ("cr-ROUTER_PORT")
has actions eth.dst = E; next;, where E is the ethernet
address of the logical router port.
@@ -3187,21 +3293,21 @@
L, it stores 1 in the register bit REGBIT_PKT_LARGER. The value of L is
taken from options:gateway_mtu column of Logical_Router_Port row.
- If the port is also configured with options:gateway_mtu_bypass then
- another flow is added, with priority-55, to bypass the check_pkt_larger
+ If the port is also configured with options:gateway_mtu_bypass then an‐
+ other flow is added, with priority-55, to bypass the check_pkt_larger
flow.
- This table adds one priority-0 fallback flow that matches all packets
+ This table adds one priority-0 fallback flow that matches all packets
and advances to the next table.
Ingress Table 19: Handle larger packets
- For distributed logical routers or gateway routers with gateway port
- configured with options:gateway_mtu to a valid integer value, this ta‐
- ble adds the following priority-150 logical flow for each logical
- router port with the match inport == LRP &&&& outport == GW_PORT &&&& REG‐
- BIT_PKT_LARGER &&&& !REGBIT_EGRESS_LOOPBACK, where LRP is the logical
- router port and GW_PORT is the gateway port and applies the following
+ For distributed logical routers or gateway routers with gateway port
+ configured with options:gateway_mtu to a valid integer value, this ta‐
+ ble adds the following priority-150 logical flow for each logical
+ router port with the match inport == LRP &&&& outport == GW_PORT &&&& REG‐‐
+ BIT_PKT_LARGER &&&& !REGBIT_EGRESS_LOOPBACK, where LRP is the logical
+ router port and GW_PORT is the gateway port and applies the following
action for ipv4 and ipv6 respectively:
icmp4 {
@@ -3230,34 +3336,46 @@
};
- · Where M is the (fragment MTU - 58) whose value is taken
- from options:gateway_mtu column of Logical_Router_Port
+ • Where M is the (fragment MTU - 58) whose value is taken
+ from options:gateway_mtu column of Logical_Router_Port
row.
- · E is the Ethernet address of the logical router port.
+ • E is the Ethernet address of the logical router port.
- · I is the IPv4/IPv6 address of the logical router port.
+ • I is the IPv4/IPv6 address of the logical router port.
- This table adds one priority-0 fallback flow that matches all packets
+ This table adds one priority-0 fallback flow that matches all packets
and advances to the next table.
Ingress Table 20: Gateway Redirect
For distributed logical routers where one or more of the logical router
ports specifies a gateway chassis, this table redirects certain packets
- to the distributed gateway port instances on the gateway chassises.
+ to the distributed gateway port instances on the gateway chassises.
This table has the following flows:
- · For each NAT rule in the OVN Northbound database that can
- be handled in a distributed manner, a priority-100 logi‐
- cal flow with match ip4.src == B &&&& outport == GW &&
+ • For all the configured load balancing rules that include
+ an IPv4 address VIP, and a list of IPv4 backend addresses
+ B0, B1 .. Bn defined for the VIP a priority-200 flow is
+ added that matches ip4 &&&& (ip4.src == B0 || ip4.src == B1
+ || ... || ip4.src == Bn) with an action outport = CR;
+ next; where CR is the chassisredirect port representing
+ the instance of the logical router distributed gateway
+ port on the gateway chassis. If the backend IPv4 address
+ Bx is also configured with L4 port PORT of protocol P,
+ then the match also includes P.src == PORT. Similar flows
+ are added for IPv6.
+
+ • For each NAT rule in the OVN Northbound database that can
+ be handled in a distributed manner, a priority-100 logi‐
+ cal flow with match ip4.src == B &&&& outport == GW &&
is_chassis_resident(P), where GW is the distributed gate‐
way port specified in the NAT rule and P is the NAT logi‐
cal port. IP traffic matching the above rule will be man‐
aged locally setting reg1 to C and eth.src to D, where C
is NAT external ip and D is NAT external mac.
- · For each dnat_and_snat NAT rule with stateless=true and
+ • For each dnat_and_snat NAT rule with stateless=true and
allowed_ext_ips configured, a priority-75 flow is pro‐
grammed with match ip4.dst == B and action outport = CR;
next; where B is the NAT rule external IP and CR is the
@@ -3266,22 +3384,22 @@
chassis. Moreover a priority-70 flow is programmed with
same match and action drop;. For each dnat_and_snat NAT
rule with stateless=true and exempted_ext_ips configured,
- a priority-75 flow is programmed with match ip4.dst == B
- and action drop; where B is the NAT rule external IP. A
+ a priority-75 flow is programmed with match ip4.dst == B
+ and action drop; where B is the NAT rule external IP. A
similar flow is added for IPv6 traffic.
- · For each NAT rule in the OVN Northbound database that can
+ • For each NAT rule in the OVN Northbound database that can
be handled in a distributed manner, a priority-80 logical
- flow with drop action if the NAT logical port is a vir‐
+ flow with drop action if the NAT logical port is a vir‐
tual port not claimed by any chassis yet.
- · A priority-50 logical flow with match outport == GW has
- actions outport = CR; next;, where GW is the logical
- router distributed gateway port and CR is the chas‐
+ • A priority-50 logical flow with match outport == GW has
+ actions outport = CR; next;, where GW is the logical
+ router distributed gateway port and CR is the chas‐‐
sisredirect port representing the instance of the logical
router distributed gateway port on the gateway chassis.
- · A priority-0 logical flow with match 1 has actions next;.
+ • A priority-0 logical flow with match 1 has actions next;.
Ingress Table 21: ARP Request
@@ -3289,7 +3407,7 @@
this table outputs the packet. Otherwise, it composes and sends an ARP
or IPv6 Neighbor Solicitation request. It holds the following flows:
- · Unknown MAC address. A priority-100 flow for IPv4 packets
+ • Unknown MAC address. A priority-100 flow for IPv4 packets
with match eth.dst == 00:00:00:00:00:00 has the following
actions:
@@ -3305,8 +3423,8 @@
Unknown MAC address. For each IPv6 static route associ‐
ated with the router with the nexthop IP: G, a prior‐
ity-200 flow for IPv6 packets with match eth.dst ==
- 00:00:00:00:00:00 &&&& xxreg0 == G with the following
- actions is added:
+ 00:00:00:00:00:00 &&&& xxreg0 == G with the following ac‐
+ tions is added:
nd_ns {
eth.dst = E;
@@ -3317,7 +3435,7 @@
Where E is the multicast mac derived from the Gateway IP,
- I is the solicited-node multicast address corresponding
+ I is the solicited-node multicast address corresponding
to the target address G.
Unknown MAC address. A priority-100 flow for IPv6 packets
@@ -3330,15 +3448,15 @@
};
- (Ingress table IP Routing initialized reg1 with the IP
- address owned by outport and (xx)reg0 with the next-hop
+ (Ingress table IP Routing initialized reg1 with the IP
+ address owned by outport and (xx)reg0 with the next-hop
IP address)
- The IP packet that triggers the ARP/IPv6 NS request is
+ The IP packet that triggers the ARP/IPv6 NS request is
dropped.
- · Known MAC address. A priority-0 flow with match 1 has
- actions output;.
+ • Known MAC address. A priority-0 flow with match 1 has ac‐
+ tions output;.
Egress Table 0: Check DNAT local
@@ -3348,98 +3466,76 @@
distributed gateway ports and NAT entries. This check is done so that
SNAT and DNAT is done in different zones instead of a common zone.
- · For each NAT rule in the OVN Northbound database on a
- distributed router, a priority-50 logical flow with match
- ip4.dst == E &&&& is_chassis_resident(P), where E is the
- external IP address specified in the NAT rule, GW is the
- logical router distributed gateway port. For
- dnat_and_snat NAT rule, P is the logical port specified
- in the NAT rule. If logical_port column of NAT table is
- NOT set, then P is the chassisredirect port of GW with
- the actions: REGBIT_DST_NAT_IP_LOCAL = 1; next;
-
- · A priority-0 logical flow with match 1 has actions REG‐
+ • A priority-0 logical flow with match 1 has actions REG‐‐
BIT_DST_NAT_IP_LOCAL = 0; next;.
- This table also installs a priority-50 logical flow for each logical
- router that has NATs configured on it. The flow has match ip &&&&
- ct_label.natted == 1 and action REGBIT_DST_NAT_IP_LOCAL = 1; next;.
- This is intended to ensure that traffic that was DNATted locally will
- use a separate conntrack zone for SNAT if SNAT is required later in the
- egress pipeline. Note that this flow checks the value of ct_label.nat‐
- ted, which is set in the ingress pipeline. This means that ovn-northd
- assumes that this value is carried over from the ingress pipeline to
- the egress pipeline and is not altered or cleared. If conntrack label
- values are ever changed to be cleared between the ingress and egress
- pipelines, then the match conditions of this flow will be updated
- accordingly.
-
Egress Table 1: UNDNAT
- This is for already established connections’ reverse traffic. i.e.,
- DNAT has already been done in ingress pipeline and now the packet has
- entered the egress pipeline as part of a reply. This traffic is unD‐
+ This is for already established connections’ reverse traffic. i.e.,
+ DNAT has already been done in ingress pipeline and now the packet has
+ entered the egress pipeline as part of a reply. This traffic is unD‐
NATed here.
- · A priority-0 logical flow with match 1 has actions next;.
+ • A priority-0 logical flow with match 1 has actions next;.
Egress Table 1: UNDNAT on Gateway Routers
- · For all IP packets, a priority-50 flow with an action
+ • For IPv6 Neighbor Discovery or Router Solicitation/Adver‐
+ tisement traffic, a priority-100 flow with action next;.
+
+ • For all IP packets, a priority-50 flow with an action
flags.loopback = 1; ct_dnat;.
Egress Table 1: UNDNAT on Distributed Routers
- · For all the configured load balancing rules for a router
- with gateway port in OVN_Northbound database that
- includes an IPv4 address VIP, for every backend IPv4
- address B defined for the VIP a priority-120 flow is pro‐
- grammed on gateway chassis that matches ip &&&& ip4.src ==
- B &&&& outport == GW, where GW is the logical router gate‐
- way port with an action ct_dnat_in_czone;. If the backend
- IPv4 address B is also configured with L4 port PORT of
- protocol P, then the match also includes P.src == PORT.
- These flows are not added for load balancers with IPv6
- VIPs.
-
- If the router is configured to force SNAT any load-bal‐
- anced packets, above action will be replaced by
+ • For all the configured load balancing rules for a router
+ with gateway port in OVN_Northbound database that in‐
+ cludes an IPv4 address VIP, for every backend IPv4 ad‐
+ dress B defined for the VIP a priority-120 flow is pro‐
+ grammed on gateway chassis that matches ip &&&& ip4.src ==
+ B &&&& outport == GW, where GW is the logical router gate‐
+ way port with an action ct_dnat;. If the backend IPv4 ad‐
+ dress B is also configured with L4 port PORT of protocol
+ P, then the match also includes P.src == PORT. These
+ flows are not added for load balancers with IPv6 VIPs.
+
+ If the router is configured to force SNAT any load-bal‐
+ anced packets, above action will be replaced by
flags.force_snat_for_lb = 1; ct_dnat;.
- · For each configuration in the OVN Northbound database
- that asks to change the destination IP address of a
- packet from an IP address of A to B, a priority-100 flow
- matches ip &&&& ip4.src == B &&&& outport == GW, where GW is
- the logical router gateway port, with an action
- ct_dnat_in_czone;. If the NAT rule is of type
- dnat_and_snat and has stateless=true in the options, then
- the action would be next;.
+ • For each configuration in the OVN Northbound database
+ that asks to change the destination IP address of a
+ packet from an IP address of A to B, a priority-100 flow
+ matches ip &&&& ip4.src == B &&&& outport == GW, where GW is
+ the logical router gateway port, with an action ct_dnat;.
+ If the NAT rule is of type dnat_and_snat and has state‐‐
+ less=true in the options, then the action would be next;.
- If the NAT rule cannot be handled in a distributed man‐
- ner, then the priority-100 flow above is only programmed
- on the gateway chassis with the action ct_dnat_in_czone.
+ If the NAT rule cannot be handled in a distributed man‐
+ ner, then the priority-100 flow above is only programmed
+ on the gateway chassis with the action ct_dnat.
- If the NAT rule can be handled in a distributed manner,
- then there is an additional action eth.src = EA;, where
+ If the NAT rule can be handled in a distributed manner,
+ then there is an additional action eth.src = EA;, where
EA is the ethernet address associated with the IP address
A in the NAT rule. This allows upstream MAC learning to
point to the correct chassis.
Egress Table 2: Post UNDNAT
- · A priority-50 logical flow is added that commits any
- untracked flows from the previous table lr_out_undnat for
+ • A priority-50 logical flow is added that commits any un‐
+ tracked flows from the previous table lr_out_undnat for
Gateway routers. This flow matches on ct.new &&&& ip with
action ct_commit { } ; next; .
- · A priority-0 logical flow with match 1 has actions next;.
+ • A priority-0 logical flow with match 1 has actions next;.
Egress Table 3: SNAT
Packets that are configured to be SNATed get their source IP address
changed based on the configuration in the OVN Northbound database.
- · A priority-120 flow to advance the IPv6 Neighbor solici‐
+ • A priority-120 flow to advance the IPv6 Neighbor solici‐
tation packet to next table to skip SNAT. In the case
where ovn-controller injects an IPv6 Neighbor Solicita‐
tion packet (for nd_ns action) we don’t want the packet
@@ -3447,94 +3543,85 @@
Egress Table 3: SNAT on Gateway Routers
- · If the Gateway router in the OVN Northbound database has
+ • If the Gateway router in the OVN Northbound database has
been configured to force SNAT a packet (that has been
previously DNATted) to B, a priority-100 flow matches
flags.force_snat_for_dnat == 1 &&&& ip with an action
ct_snat(B);.
- · If a load balancer configured to skip snat has been
- applied to the Gateway router pipeline, a priority-120
- flow matches flags.skip_snat_for_lb == 1 &&&& ip with an
- action next;.
-
- · If the Gateway router in the OVN Northbound database has
- been configured to force SNAT a packet (that has been
- previously load-balanced) using router IP (i.e
- options:lb_force_snat_ip=router_ip), then for each logi‐
- cal router port P attached to the Gateway router, a pri‐
- ority-110 flow matches flags.force_snat_for_lb == 1 &&&&
- outport == P
+ • If a load balancer configured to skip snat has been ap‐
+ plied to the Gateway router pipeline, a priority-120 flow
+ matches flags.skip_snat_for_lb == 1 &&&& ip with an action
+ next;.
+
+ • If the Gateway router in the OVN Northbound database has
+ been configured to force SNAT a packet (that has been
+ previously load-balanced) using router IP (i.e op‐‐
+ tions:lb_force_snat_ip=router_ip), then for each logical
+ router port P attached to the Gateway router, a prior‐
+ ity-110 flow matches flags.force_snat_for_lb == 1 &&&& out‐‐
+ port == P
with an action ct_snat(R); where R is the IP configured
on the router port. If R is an IPv4 address then the
match will also include ip4 and if it is an IPv6 address,
then the match will also include ip6.
- If the logical router port P is configured with multiple
+ If the logical router port P is configured with multiple
IPv4 and multiple IPv6 addresses, only the first IPv4 and
first IPv6 address is considered.
- · If the Gateway router in the OVN Northbound database has
+ • If the Gateway router in the OVN Northbound database has
been configured to force SNAT a packet (that has been
previously load-balanced) to B, a priority-100 flow
matches flags.force_snat_for_lb == 1 &&&& ip with an action
ct_snat(B);.
- · For each configuration in the OVN Northbound database,
- that asks to change the source IP address of a packet
- from an IP address of A or to change the source IP
- address of a packet that belongs to network A to B, a
- flow matches ip &&&& ip4.src == A &&&& (!ct.trk || !ct.rpl)
- with an action ct_snat(B);. The priority of the flow is
- calculated based on the mask of A, with matches having
- larger masks getting higher priorities. If the NAT rule
- is of type dnat_and_snat and has stateless=true in the
- options, then the action would be ip4/6.src= (B).
-
- · If the NAT rule has allowed_ext_ips configured, then
+ • For each configuration in the OVN Northbound database,
+ that asks to change the source IP address of a packet
+ from an IP address of A or to change the source IP ad‐
+ dress of a packet that belongs to network A to B, a flow
+ matches ip &&&& ip4.src == A &&&& (!ct.trk || !ct.rpl) with
+ an action ct_snat(B);. The priority of the flow is calcu‐
+ lated based on the mask of A, with matches having larger
+ masks getting higher priorities. If the NAT rule is of
+ type dnat_and_snat and has stateless=true in the options,
+ then the action would be ip4/6.src= (B).
+
+ • If the NAT rule has allowed_ext_ips configured, then
there is an additional match ip4.dst == allowed_ext_ips .
- Similarly, for IPV6, match would be ip6.dst ==
- allowed_ext_ips.
+ Similarly, for IPV6, match would be ip6.dst == al
+ lowed_ext_ips.
- · If the NAT rule has exempted_ext_ips set, then there is
+ • If the NAT rule has exempted_ext_ips set, then there is
an additional flow configured at the priority + 1 of cor‐
- responding NAT rule. The flow matches if destination ip
+ responding NAT rule. The flow matches if destination ip
is an exempted_ext_ip and the action is next; . This flow
is used to bypass the ct_snat action for a packet which
is destinted to exempted_ext_ips.
- · A priority-0 logical flow with match 1 has actions next;.
+ • A priority-0 logical flow with match 1 has actions next;.
Egress Table 3: SNAT on Distributed Routers
- · For each configuration in the OVN Northbound database,
+ • For each configuration in the OVN Northbound database,
that asks to change the source IP address of a packet
- from an IP address of A or to change the source IP
- address of a packet that belongs to network A to B, two
+ from an IP address of A or to change the source IP ad‐
+ dress of a packet that belongs to network A to B, two
flows are added. The priority P of these flows are calcu‐
- lated based on the mask of A, with matches having larger
+ lated based on the mask of A, with matches having larger
masks getting higher priorities.
- If the NAT rule cannot be handled in a distributed man‐
- ner, then the below flows are only programmed on the
- gateway chassis increasing flow priority by 128 in order
+ If the NAT rule cannot be handled in a distributed man‐
+ ner, then the below flows are only programmed on the
+ gateway chassis increasing flow priority by 128 in order
to be run first.
- · The first flow is added with the calculated prior‐
+ • The first flow is added with the calculated prior‐
ity P and match ip &&&& ip4.src == A &&&& outport ==
GW, where GW is the logical router gateway port,
- with an action ct_snat_in_czone(B); to SNATed in
- the common zone. If the NAT rule is of type
- dnat_and_snat and has stateless=true in the
- options, then the action would be ip4/6.src=(B).
-
- · The second flow is added with the calculated pri‐
- ority P + 1 and match ip &&&& ip4.src == A &&&& out‐
- port == GW &&&& REGBIT_DST_NAT_IP_LOCAL == 0, where
- GW is the logical router gateway port, with an
- action ct_snat(B); to SNAT in the snat zone. If
- the NAT rule is of type dnat_and_snat and has
- stateless=true in the options, then the action
+ with an action ct_snat(B); to SNATed in the common
+ zone. If the NAT rule is of type dnat_and_snat and
+ has stateless=true in the options, then the action
would be ip4/6.src=(B).
If the NAT rule can be handled in a distributed manner,
@@ -3545,19 +3632,26 @@
If the NAT rule has allowed_ext_ips configured, then
there is an additional match ip4.dst == allowed_ext_ips .
- Similarly, for IPV6, match would be ip6.dst ==
- allowed_ext_ips.
-
- If the NAT rule has exempted_ext_ips set, then there is
- an additional flow configured at the priority P + 2 of
- corresponding NAT rule. The flow matches if destination
- ip is an exempted_ext_ip and the action is next; . This
- flow is used to bypass the ct_snat action for a flow
+ Similarly, for IPV6, match would be ip6.dst == al
+ lowed_ext_ips.
+
+ If the NAT rule has exempted_ext_ips set, then there is
+ an additional flow configured at the priority P + 2 of
+ corresponding NAT rule. The flow matches if destination
+ ip is an exempted_ext_ip and the action is next; . This
+ flow is used to bypass the ct_snat action for a flow
which is destinted to exempted_ext_ips.
- · A priority-0 logical flow with match 1 has actions next;.
+ • A priority-0 logical flow with match 1 has actions next;.
+
+ Egress Table 4: Post SNAT
+
+ Packets reaching this table are processed according to the flows below:
- Egress Table 4: Egress Loopback
+ • A priority-0 logical flow that matches all packets not
+ already handled (match 1) and action next;.
+
+ Egress Table 5: Egress Loopback
For distributed logical routers where one of the logical router ports
specifies a gateway chassis.
@@ -3565,15 +3659,15 @@
While UNDNAT and SNAT processing have already occurred by this point,
this traffic needs to be forced through egress loopback on this dis‐
tributed gateway port instance, in order for UNSNAT and DNAT processing
- to be applied, and also for IP routing and ARP resolution after all of
+ to be applied, and also for IP routing and ARP resolution after all of
the NAT processing, so that the packet can be forwarded to the destina‐
tion.
This table has the following flows:
- · For each NAT rule in the OVN Northbound database on a
+ • For each NAT rule in the OVN Northbound database on a
distributed router, a priority-100 logical flow with
- match ip4.dst == E &&&& outport == GW &&&& is_chassis_resi‐
+ match ip4.dst == E &&&& outport == GW &&&& is_chassis_resi‐‐
dent(P), where E is the external IP address specified in
the NAT rule, GW is the distributed gateway port corre‐
sponding to the NAT rule (specified or inferred). For
@@ -3588,7 +3682,6 @@
outport = "";
flags = 0;
flags.loopback = 1;
- flags.use_snat_zone = REGBIT_DST_NAT_IP_LOCAL;
reg0 = 0;
reg1 = 0;
...
@@ -3600,46 +3693,44 @@
flags.loopback is set since in_port is unchanged and the
packet may return back to that port after NAT processing.
- REGBIT_EGRESS_LOOPBACK is set to indicate that egress
- loopback has occurred, in order to skip the source IP
- address check against the router address.
+ REGBIT_EGRESS_LOOPBACK is set to indicate that egress
+ loopback has occurred, in order to skip the source IP ad‐
+ dress check against the router address.
- · A priority-0 logical flow with match 1 has actions next;.
+ • A priority-0 logical flow with match 1 has actions next;.
- Egress Table 5: Delivery
+ Egress Table 6: Delivery
Packets that reach this table are ready for delivery. It contains:
- · Priority-110 logical flows that match IP multicast pack‐
+ • Priority-110 logical flows that match IP multicast pack‐
ets on each enabled logical router port and modify the
Ethernet source address of the packets to the Ethernet
address of the port and then execute action output;.
- · Priority-100 logical flows that match packets on each
- enabled logical router port, with action output;.
+ • Priority-100 logical flows that match packets on each en‐
+ abled logical router port, with action output;.
- · A priority-0 logical flow that matches all packets not
+ • A priority-0 logical flow that matches all packets not
already handled (match 1) and drops them (action drop;).
DROP SAMPLING
- As described in the previous section, there are several places where
- ovn-northd might decided to drop a packet by explicitly creating a Log‐
+ As described in the previous section, there are several places where
+ ovn-northd might decided to drop a packet by explicitly creating a Log‐‐
ical_Flow with the drop; action.
When debug drop-sampling has been cofigured in the OVN Northbound data‐
- base, the ovn-northd will replace all the drop; actions with a sam‐
- ple(priority=65535, collector_set=id, obs_domain=obs_id,
+ base, the ovn-northd will replace all the drop; actions with a sam‐‐
+ ple(priority=65535, collector_set=id, obs_domain=obs_id,
obs_point=@cookie) action, where:
- · id is the value the debug_drop_collector_set option con‐
+ • id is the value the debug_drop_collector_set option con‐
figured in the OVN Northbound.
- · obs_id has it’s 8 most significant bits equal to the
- value of the debug_drop_domain_id option in the OVN
- Northbound and it’s 24 least significant bits equal to
+ • obs_id has it’s 8 most significant bits equal to the
+ value of the debug_drop_domain_id option in the OVN
+ Northbound and it’s 24 least significant bits equal to
the datapath’s tunnel key.
-
-
-OVN 22.12.90 ovn-northd ovn-northd(8)
+OVN 24.03.90 ovn-northd ovn-northd(8)
diff --git a/src/static/support/dist-docs/ovn-northd.8.pdf b/src/static/support/dist-docs/ovn-northd.8.pdf
index 60e813f2..5d45a078 100644
Binary files a/src/static/support/dist-docs/ovn-northd.8.pdf and b/src/static/support/dist-docs/ovn-northd.8.pdf differ
diff --git a/src/static/support/dist-docs/ovn-northd.8.txt b/src/static/support/dist-docs/ovn-northd.8.txt
index f1e83baf..8e9148df 100644
--- a/src/static/support/dist-docs/ovn-northd.8.txt
+++ b/src/static/support/dist-docs/ovn-northd.8.txt
@@ -1,59 +1,39 @@
ovn-northd(8) OVN Manual ovn-northd(8)
-
-
NAME
- ovn-northd and ovn-northd-ddlog - Open Virtual Network central control
- daemon
+ ovn-northd - Open Virtual Network central control daemon
SYNOPSIS
ovn-northd [options]
DESCRIPTION
- ovn-northd is a centralized daemon responsible for translating the
- high-level OVN configuration into logical configuration consumable by
- daemons such as ovn-controller. It translates the logical network con‐
- figuration in terms of conventional network concepts, taken from the
+ ovn-northd is a centralized daemon responsible for translating the
+ high-level OVN configuration into logical configuration consumable by
+ daemons such as ovn-controller. It translates the logical network con‐
+ figuration in terms of conventional network concepts, taken from the
OVN Northbound Database (see ovn-nb(5)), into logical datapath flows in
the OVN Southbound Database (see ovn-sb(5)) below it.
- ovn-northd is implemented in C. ovn-northd-ddlog is a compatible imple‐
- mentation written in DDlog, a language for incremental database pro‐
- cessing. This documentation applies to both implementations, with dif‐
- ferences indicated where relevant.
-
OPTIONS
--ovnnb-db=database
- The OVSDB database containing the OVN Northbound Database. If
- the OVN_NB_DB environment variable is set, its value is used as
+ The OVSDB database containing the OVN Northbound Database. If
+ the OVN_NB_DB environment variable is set, its value is used as
the default. Otherwise, the default is unix:/ovnnb_db.sock.
--ovnsb-db=database
- The OVSDB database containing the OVN Southbound Database. If
- the OVN_SB_DB environment variable is set, its value is used as
+ The OVSDB database containing the OVN Southbound Database. If
+ the OVN_SB_DB environment variable is set, its value is used as
the default. Otherwise, the default is unix:/ovnsb_db.sock.
- --ddlog-record=file
- This option is for ovn-north-ddlog only. It causes the daemon to
- record the initial database state and later changes to file in
- the text-based DDlog command format. The ovn_northd_cli program
- can later replay these changes for debugging purposes. This
- option has a performance impact. See debugging-ddlog.rst in the
- OVN documentation for more details.
-
--dry-run
Causes ovn-northd to start paused. In the paused state,
ovn-northd does not apply any changes to the databases, although
- it continues to monitor them. For more information, see the
+ it continues to monitor them. For more information, see the
pause command, under Runtime Management Commands below.
- For ovn-northd-ddlog, one could use this option with
- --ddlog-record to generate a replay log without restarting a
- process or disturbing a running system.
-
n-threads N
- In certain situations, it may be desirable to enable paral‐
- lelization on a system to decrease latency (at the potential
+ In certain situations, it may be desirable to enable paral‐
+ lelization on a system to decrease latency (at the potential
cost of increasing CPU usage).
This option will cause ovn-northd to use N threads when building
@@ -64,15 +44,13 @@ OPTIONS
lelization is enabled (with 256 threads) and a warning is
logged.
- ovn-northd-ddlog does not support this option.
-
database in the above options must be an OVSDB active or passive con‐
nection method, as described in ovsdb(7).
Daemon Options
--pidfile[=pidfile]
Causes a file (by default, program.pid) to be created indicating
- the PID of the running process. If the pidfile argument is not
+ the PID of the running process. If the pidfile argument is not
specified, or if it does not begin with /, then it is created in
.
@@ -90,13 +68,13 @@ OPTIONS
Runs this program as a background process. The process forks,
and in the child it starts a new session, closes the standard
file descriptors (which has the side effect of disabling logging
- to the console), and changes its current directory to the root
- (unless --no-chdir is specified). After the child completes its
+ to the console), and changes its current directory to the root
+ (unless --no-chdir is specified). After the child completes its
initialization, the parent exits.
--monitor
- Creates an additional process to monitor this program. If it
- dies due to a signal that indicates a programming error (SIGA‐
+ Creates an additional process to monitor this program. If it
+ dies due to a signal that indicates a programming error (SIGA‐
BRT, SIGALRM, SIGBUS, SIGFPE, SIGILL, SIGPIPE, SIGSEGV, SIGXCPU,
or SIGXFSZ) then the monitor process starts a new copy of it. If
the daemon dies or exits for another reason, the monitor process
@@ -107,10 +85,10 @@ OPTIONS
--no-chdir
By default, when --detach is specified, the daemon changes its
- current working directory to the root directory after it
- detaches. Otherwise, invoking the daemon from a carelessly cho‐
- sen directory would prevent the administrator from unmounting
- the file system that holds that directory.
+ current working directory to the root directory after it de‐
+ taches. Otherwise, invoking the daemon from a carelessly chosen
+ directory would prevent the administrator from unmounting the
+ file system that holds that directory.
Specifying --no-chdir suppresses this behavior, preventing the
daemon from changing its current working directory. This may be
@@ -129,21 +107,21 @@ OPTIONS
implementations that are typically enforced from kernel-space
(e.g. DAC or MAC), self-confinement is imposed from the user-
space daemon itself and hence should not be considered as a full
- confinement strategy, but instead should be viewed as an addi‐
+ confinement strategy, but instead should be viewed as an addi‐
tional layer of security.
--user=user:group
- Causes this program to run as a different user specified in
- user:group, thus dropping most of the root privileges. Short
- forms user and :group are also allowed, with current user or
- group assumed, respectively. Only daemons started by the root
+ Causes this program to run as a different user specified in
+ user:group, thus dropping most of the root privileges. Short
+ forms user and :group are also allowed, with current user or
+ group assumed, respectively. Only daemons started by the root
user accepts this argument.
On Linux, daemons will be granted CAP_IPC_LOCK and
- CAP_NET_BIND_SERVICES before dropping root privileges. Daemons
- that interact with a datapath, such as ovs-vswitchd, will be
- granted three additional capabilities, namely CAP_NET_ADMIN,
- CAP_NET_BROADCAST and CAP_NET_RAW. The capability change will
+ CAP_NET_BIND_SERVICES before dropping root privileges. Daemons
+ that interact with a datapath, such as ovs-vswitchd, will be
+ granted three additional capabilities, namely CAP_NET_ADMIN,
+ CAP_NET_BROADCAST and CAP_NET_RAW. The capability change will
apply even if the new user is root.
On Windows, this option is not currently supported. For security
@@ -158,13 +136,13 @@ OPTIONS
words separated by spaces or commas or colons, up to one from each
category below:
- · A valid module name, as displayed by the vlog/list command
+ • A valid module name, as displayed by the vlog/list command
on ovs-appctl(8), limits the log level change to the speci‐
fied module.
- · syslog, console, or file, to limit the log level change to
- only to the system log, to the console, or to a file,
- respectively. (If --detach is specified, the daemon closes
+ • syslog, console, or file, to limit the log level change to
+ only to the system log, to the console, or to a file, re‐
+ spectively. (If --detach is specified, the daemon closes
its standard file descriptors, so logging to the console
will have no effect.)
@@ -172,15 +150,15 @@ OPTIONS
only useful along with the --syslog-target option (the word
has no effect otherwise).
- · off, emer, err, warn, info, or dbg, to control the log
- level. Messages of the given severity or higher will be
- logged, and messages of lower severity will be filtered
- out. off filters out all messages. See ovs-appctl(8) for a
+ • off, emer, err, warn, info, or dbg, to control the log
+ level. Messages of the given severity or higher will be
+ logged, and messages of lower severity will be filtered
+ out. off filters out all messages. See ovs-appctl(8) for a
definition of each log level.
Case is not significant within spec.
- Regardless of the log levels set for file, logging to a file will
+ Regardless of the log levels set for file, logging to a file will
not take place unless --log-file is also specified (see below).
For compatibility with older versions of OVS, any is accepted as a
@@ -188,22 +166,22 @@ OPTIONS
-v
--verbose
- Sets the maximum logging verbosity level, equivalent to --ver‐
+ Sets the maximum logging verbosity level, equivalent to --ver‐
bose=dbg.
-vPATTERN:destination:pattern
--verbose=PATTERN:destination:pattern
- Sets the log pattern for destination to pattern. Refer to
- ovs-appctl(8) for a description of the valid syntax for pattern.
+ Sets the log pattern for destination to pattern. Refer to ovs-ap‐
+ pctl(8) for a description of the valid syntax for pattern.
-vFACILITY:facility
--verbose=FACILITY:facility
Sets the RFC5424 facility of the log message. facility can be one
of kern, user, mail, daemon, auth, syslog, lpr, news, uucp, clock,
- ftp, ntp, audit, alert, clock2, local0, local1, local2, local3,
+ ftp, ntp, audit, alert, clock2, local0, local1, local2, local3,
local4, local5, local6 or local7. If this option is not specified,
- daemon is used as the default for the local system syslog and
- local0 is used while sending a message to the target provided via
+ daemon is used as the default for the local system syslog and lo‐
+ cal0 is used while sending a message to the target provided via
the --syslog-target option.
--log-file[=file]
@@ -212,64 +190,64 @@ OPTIONS
if file is omitted is /usr/local/var/log/ovn/program.log.
--syslog-target=host:port
- Send syslog messages to UDP port on host, in addition to the sys‐
- tem syslog. The host must be a numerical IP address, not a host‐
+ Send syslog messages to UDP port on host, in addition to the sys‐
+ tem syslog. The host must be a numerical IP address, not a host‐
name.
--syslog-method=method
- Specify method as how syslog messages should be sent to syslog
+ Specify method as how syslog messages should be sent to syslog
daemon. The following forms are supported:
- · libc, to use the libc syslog() function. Downside of using
- this options is that libc adds fixed prefix to every mes‐
- sage before it is actually sent to the syslog daemon over
+ • libc, to use the libc syslog() function. Downside of using
+ this options is that libc adds fixed prefix to every mes‐
+ sage before it is actually sent to the syslog daemon over
/dev/log UNIX domain socket.
- · unix:file, to use a UNIX domain socket directly. It is pos‐
+ • unix:file, to use a UNIX domain socket directly. It is pos‐
sible to specify arbitrary message format with this option.
- However, rsyslogd 8.9 and older versions use hard coded
- parser function anyway that limits UNIX domain socket use.
- If you want to use arbitrary message format with older
- rsyslogd versions, then use UDP socket to localhost IP
- address instead.
-
- · udp:ip:port, to use a UDP socket. With this method it is
- possible to use arbitrary message format also with older
- rsyslogd. When sending syslog messages over UDP socket
- extra precaution needs to be taken into account, for exam‐
- ple, syslog daemon needs to be configured to listen on the
- specified UDP port, accidental iptables rules could be
- interfering with local syslog traffic and there are some
- security considerations that apply to UDP sockets, but do
- not apply to UNIX domain sockets.
-
- · null, to discard all messages logged to syslog.
-
- The default is taken from the OVS_SYSLOG_METHOD environment vari‐
+ However, rsyslogd 8.9 and older versions use hard coded
+ parser function anyway that limits UNIX domain socket use.
+ If you want to use arbitrary message format with older
+ rsyslogd versions, then use UDP socket to localhost IP ad‐
+ dress instead.
+
+ • udp:ip:port, to use a UDP socket. With this method it is
+ possible to use arbitrary message format also with older
+ rsyslogd. When sending syslog messages over UDP socket ex‐
+ tra precaution needs to be taken into account, for example,
+ syslog daemon needs to be configured to listen on the spec‐
+ ified UDP port, accidental iptables rules could be inter‐
+ fering with local syslog traffic and there are some secu‐
+ rity considerations that apply to UDP sockets, but do not
+ apply to UNIX domain sockets.
+
+ • null, to discard all messages logged to syslog.
+
+ The default is taken from the OVS_SYSLOG_METHOD environment vari‐
able; if it is unset, the default is libc.
PKI Options
- PKI configuration is required in order to use SSL for the connections
+ PKI configuration is required in order to use SSL for the connections
to the Northbound and Southbound databases.
-p privkey.pem
--private-key=privkey.pem
- Specifies a PEM file containing the private key used as
+ Specifies a PEM file containing the private key used as
identity for outgoing SSL connections.
-c cert.pem
--certificate=cert.pem
- Specifies a PEM file containing a certificate that certi‐
+ Specifies a PEM file containing a certificate that certi‐
fies the private key specified on -p or --private-key to be
trustworthy. The certificate must be signed by the certifi‐
- cate authority (CA) that the peer in SSL connections will
+ cate authority (CA) that the peer in SSL connections will
use to verify it.
-C cacert.pem
--ca-cert=cacert.pem
Specifies a PEM file containing the CA certificate for ver‐
ifying certificates presented to this program by SSL peers.
- (This may be the same certificate that SSL peers use to
+ (This may be the same certificate that SSL peers use to
verify the certificate specified on -c or --certificate, or
it may be a different one, depending on the PKI design in
use.)
@@ -284,9 +262,9 @@ OPTIONS
Other Options
--unixctl=socket
Sets the name of the control socket on which program listens for
- runtime management commands (see RUNTIME MANAGEMENT COMMANDS,
- below). If socket does not begin with /, it is interpreted as
- relative to . If --unixctl is not used at all, the default
+ runtime management commands (see RUNTIME MANAGEMENT COMMANDS,
+ below). If socket does not begin with /, it is interpreted as
+ relative to . If --unixctl is not used at all, the default
socket is /program.pid.ctl, where pid is program’s process ID.
On Windows a local named pipe is used to listen for runtime man‐
@@ -315,7 +293,7 @@ RUNTIME MANAGEMENT COMMANDS
pause Pauses ovn-northd. When it is paused, ovn-northd receives
changes from the Northbound and Southbound database
- changes as usual, but it does not send any updates. A
+ changes as usual, but it does not send any updates. A
paused ovn-northd also drops database locks, which allows
any other non-paused instance of ovn-northd to take over.
@@ -328,7 +306,7 @@ RUNTIME MANAGEMENT COMMANDS
Returns "true" if ovn-northd is currently paused, "false"
otherwise.
- status Prints this server’s status. Status will be "active" if
+ status Prints this server’s status. Status will be "active" if
ovn-northd has acquired OVSDB lock on SB DB, "standby" if
it has not or "paused" if this instance is paused.
@@ -338,100 +316,80 @@ RUNTIME MANAGEMENT COMMANDS
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-northd 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-northd will reset
- its local index so that it can interact with the south‐
- bound database again.
+ will be reset to zero. This will cause ovn-northd to be
+ unable to read or write to the southbound database, be‐
+ cause it will always detect the data as stale. In such a
+ case, run this command so that ovn-northd will reset its
+ local index so that it can interact with the southbound
+ database again.
nb-cluster-state-reset
- Reset northbound database cluster status when databases
+ Reset northbound database cluster status when databases
are destroyed and rebuilt.
- This performs the same task as sb-cluster-state-reset
- except for the northbound database client.
+ This performs the same task as sb-cluster-state-reset ex‐
+ cept for the northbound database client.
set-n-threads N
Set the number of threads used for building logical
- flows. When N is within [2-256], parallelization is
- enabled. When N is 1 parallelization is disabled. When N
- is less than 1 or more than 256, an error is returned. If
- ovn-northd fails to start parallelization (e.g. fails to
- setup semaphores, parallelization is disabled and an
- error is returned.
+ flows. When N is within [2-256], parallelization is en‐
+ abled. When N is 1 parallelization is disabled. When N is
+ less than 1 or more than 256, an error is returned. If
+ ovn-northd fails to start parallelization (e.g. fails to
+ setup semaphores, parallelization is disabled and an er‐
+ ror is returned.
get-n-threads
- Return the number of threads used for building logical
+ Return the number of threads used for building logical
flows.
inc-engine/show-stats
- Display ovn-northd engine counters. For each engine node
+ Display ovn-northd engine counters. For each engine node
the following counters have been added:
- · recompute
+ • recompute
- · compute
+ • compute
- · abort
+ • abort
inc-engine/show-stats engine_node_name counter_name
- Display the ovn-northd engine counter(s) for the speci‐
- fied engine_node_name. counter_name is optional and can
+ Display the ovn-northd engine counter(s) for the speci‐
+ fied engine_node_name. counter_name is optional and can
be one of recompute, compute or abort.
inc-engine/clear-stats
Reset ovn-northd engine counters.
- Only ovn-northd-ddlog supports the following commands:
-
- enable-cpu-profiling
- disable-cpu-profiling
- Enables or disables profiling of CPU time used by the DDlog
- engine. When CPU profiling is enabled, the profile command
- (see below) will include DDlog CPU usage statistics in its
- output. Enabling CPU profiling will slow ovn-northd-ddlog.
- Disabling CPU profiling does not clear any previously
- recorded statistics.
-
- profile
- Outputs a profile of the current and peak sizes of arrange‐
- ments inside DDlog. This profiling data can be useful for
- optimizing DDlog code. If CPU profiling was previously
- enabled (even if it was later disabled), the output also
- includes a CPU time profile. See Profiling inside the tuto‐
- rial in the DDlog repository for an introduction to profil‐
- ing DDlog.
-
ACTIVE-STANDBY FOR HIGH AVAILABILITY
You may run ovn-northd more than once in an OVN deployment. When con‐
nected to a standalone or clustered DB setup, OVN will automatically
ensure that only one of them is active at a time. If multiple instances
- of ovn-northd are running and the active ovn-northd fails, one of the
+ of ovn-northd are running and the active ovn-northd fails, one of the
hot standby instances of ovn-northd will automatically take over.
Active-Standby with multiple OVN DB servers
You may run multiple OVN DB servers in an OVN deployment with:
- · OVN DB servers deployed in active/passive mode with one
+ • OVN DB servers deployed in active/passive mode with one
active and multiple passive ovsdb-servers.
- · ovn-northd also deployed on all these nodes, using unix
+ • ovn-northd also deployed on all these nodes, using unix
ctl sockets to connect to the local OVN DB servers.
- In such deployments, the ovn-northds on the passive nodes will process
- the DB changes and compute logical flows to be thrown out later,
- because write transactions are not allowed by the passive ovsdb-
- servers. It results in unnecessary CPU usage.
+ In such deployments, the ovn-northds on the passive nodes will process
+ the DB changes and compute logical flows to be thrown out later, be‐
+ cause write transactions are not allowed by the passive ovsdb-servers.
+ It results in unnecessary CPU usage.
- With the help of runtime management command pause, you can pause
- ovn-northd on these nodes. When a passive node becomes master, you can
- use the runtime management command resume to resume the ovn-northd to
+ With the help of runtime management command pause, you can pause
+ ovn-northd on these nodes. When a passive node becomes master, you can
+ use the runtime management command resume to resume the ovn-northd to
process the DB changes.
LOGICAL FLOW TABLE STRUCTURE
- One of the main purposes of ovn-northd is to populate the Logical_Flow
- table in the OVN_Southbound database. This section describes how
+ One of the main purposes of ovn-northd is to populate the Logical_Flow
+ table in the OVN_Southbound database. This section describes how
ovn-northd does this for switch and router logical datapaths.
Logical Switch Datapaths
@@ -439,83 +397,112 @@ LOGICAL FLOW TABLE STRUCTURE
Ingress table 0 contains these logical flows:
- · Priority 100 flows to drop packets with VLAN tags or mul‐
+ • Priority 100 flows to drop packets with VLAN tags or mul‐
ticast Ethernet source addresses.
- · For each disabled logical port, a priority 100 flow is
+ • For each disabled logical port, a priority 100 flow is
added which matches on all packets and applies the action
REGBIT_PORT_SEC_DROP" = 1; next;" so that the packets are
dropped in the next stage.
- · For each (enabled) vtep logical port, a priority 70 flow
- is added which matches on all packets and applies the
- action next(pipeline=ingress, table=S_SWITCH_IN_L2_LKUP)
- = 1; to skip most stages of ingress pipeline and go
- directly to ingress L2 lookup table to determine the out‐
- put port. Packets from VTEP (RAMP) switch should not be
- subjected to any ACL checks. Egress pipeline will do the
- ACL checks.
-
- · For each enabled logical port configured with qdisc queue
- id in the options:qdisc_queue_id column of Logi‐
+ • For each (enabled) vtep logical port, a priority 70 flow
+ is added which matches on all packets and applies the ac‐
+ tion next(pipeline=ingress, table=S_SWITCH_IN_L3_LKUP) =
+ 1; to skip most stages of ingress pipeline and go di‐
+ rectly to ingress L2 lookup table to determine the output
+ port. Packets from VTEP (RAMP) switch should not be sub‐
+ jected to any ACL checks. Egress pipeline will do the ACL
+ checks.
+
+ • For each enabled logical port configured with qdisc queue
+ id in the options:qdisc_queue_id column of Logi‐
cal_Switch_Port, a priority 70 flow is added which
matches on all packets and applies the action
set_queue(id); REGBIT_PORT_SEC_DROP" =
check_in_port_sec(); next;".
- · A priority 1 flow is added which matches on all packets
- for all the logical ports and applies the action REG‐
+ • A priority 1 flow is added which matches on all packets
+ for all the logical ports and applies the action REG‐
BIT_PORT_SEC_DROP" = check_in_port_sec(); next; to evalu‐
- ate the port security. The action check_in_port_sec
- applies the port security rules defined in the port_secu‐
+ ate the port security. The action check_in_port_sec ap‐
+ plies the port security rules defined in the port_secu‐
rity column of Logical_Switch_Port table.
Ingress Table 1: Ingress Port Security - Apply
+ For each logical switch port P of type router connected to a gw router
+ a priority-120 flow that matches ’recirculated’ icmp{4,6} error ’packet
+ too big’ and eth.src == D && outport == P && flags.tunnel_rx == 1 where
+ D is the peer logical router port RP mac address, swaps inport and out‐
+ port and applies the action next(pipeline=S_SWITCH_IN_L2_LKUP).
+
+ For each logical switch port P of type router connected to a distrib‐
+ uted router a priority-120 flow that matches ’recirculated’ icmp{4,6}
+ error ’packet too big’ and eth.dst == D && flags.tunnel_rx == 1 where D
+ is the peer logical router port RP mac address, swaps inport and out‐
+ port and applies the action next(pipeline=S_SWITCH_IN_L2_LKUP).
+
+ This table adds a priority-110 flow that matches ’recirculated’
+ icmp{4,6} error ’packet too big’ to drop the packet.
+
This table drops the packets if the port security check failed in the
previous stage i.e the register bit REGBIT_PORT_SEC_DROP is set to 1.
Ingress table 1 contains these logical flows:
- · A priority-50 fallback flow that drops the packet if the
+ • A priority-50 fallback flow that drops the packet if the
register bit REGBIT_PORT_SEC_DROP is set to 1.
- · One priority-0 fallback flow that matches all packets and
+ • One priority-0 fallback flow that matches all packets and
advances to the next table.
Ingress Table 2: Lookup MAC address learning table
- This table looks up the MAC learning table of the logical switch data‐
- path to check if the port-mac pair is present or not. MAC is learnt
- only for logical switch VIF ports whose port security is disabled and
- ’unknown’ address set.
+ This table looks up the MAC learning table of the logical switch data‐
+ path to check if the port-mac pair is present or not. MAC is learnt for
+ logical switch VIF ports whose port security is disabled and ’unknown’
+ address setn as well as for localnet ports with option local‐
+ net_learn_fdb. A localnet port entry does not overwrite a VIF port en‐
+ try.
- · For each such logical port p whose port security is dis‐
- abled and ’unknown’ address set following flow is added.
+ • For each such VIF logical port p whose port security is
+ disabled and ’unknown’ address set following flow is
+ added.
- · Priority 100 flow with the match inport == p and
+ • Priority 100 flow with the match inport == p and
action reg0[11] = lookup_fdb(inport, eth.src);
next;
- · One priority-0 fallback flow that matches all packets and
+ • For each such localnet logical port p following flow is
+ added.
+
+ • Priority 100 flow with the match inport == p and
+ action flags.localnet = 1; reg0[11] =
+ lookup_fdb(inport, eth.src); next;
+
+ • One priority-0 fallback flow that matches all packets and
advances to the next table.
Ingress Table 3: Learn MAC of ’unknown’ ports.
- This table learns the MAC addresses seen on the logical ports whose
- port security is disabled and ’unknown’ address set if the lookup_fdb
- action returned false in the previous table.
+ This table learns the MAC addresses seen on the VIF logical ports whose
+ port security is disabled and ’unknown’ address set as well as on lo‐
+ calnet ports with localnet_learn_fdb option set if the lookup_fdb ac‐
+ tion returned false in the previous table. For localnet ports (with
+ flags.localnet = 1), lookup_fdb returns true if (port, mac) is found or
+ if a mac is found for a port of type vif.
- · For each such logical port p whose port security is dis‐
- abled and ’unknown’ address set following flow is added.
+ • For each such VIF logical port p whose port security is
+ disabled and ’unknown’ address set and localnet port fol‐
+ lowing flow is added.
- · Priority 100 flow with the match inport == p &&
+ • Priority 100 flow with the match inport == p &&
reg0[11] == 0 and action put_fdb(inport, eth.src);
- next; which stores the port-mac in the mac learn‐
- ing table of the logical switch datapath and
- advances the packet to the next table.
+ next; which stores the port-mac in the mac learn‐
+ ing table of the logical switch datapath and ad‐
+ vances the packet to the next table.
- · One priority-0 fallback flow that matches all packets and
+ • One priority-0 fallback flow that matches all packets and
advances to the next table.
Ingress Table 4: from-lport Pre-ACLs
@@ -524,18 +511,21 @@ LOGICAL FLOW TABLE STRUCTURE
ingress table ACLs. It contains a priority-0 flow that simply moves
traffic to the next table. If stateful ACLs are used in the logical
datapath, a priority-100 flow is added that sets a hint (with reg0[0] =
- 1; next;) for table Pre-stateful to send IP packets to the connection
- tracker before eventually advancing to ingress table ACLs. If special
- ports such as route ports or localnet ports can’t use ct(), a prior‐
- ity-110 flow is added to skip over stateful ACLs. Multicast, IPv6
- Neighbor Discovery and MLD traffic also skips stateful ACLs. For
- "allow-stateless" ACLs, a flow is added to bypass setting the hint for
- connection tracker processing when there are stateful ACLs or LB rules;
- REGBIT_ACL_STATELESS is set for traffic matching stateless ACL flows.
+ 1; next;) for table Pre-stateful to send IP packets to the connection
+ tracker before eventually advancing to ingress table ACLs. If special
+ ports such as route ports or localnet ports can’t use ct(), a prior‐
+ ity-110 flow is added to skip over stateful ACLs. This priority-110
+ flow is not addd for router ports if the option enable_router_port_acl
+ is set to true in options:enable_router_port_acl column of Logi‐
+ cal_Switch_Port. Multicast, IPv6 Neighbor Discovery and MLD traffic
+ also skips stateful ACLs. For "allow-stateless" ACLs, a flow is added
+ to bypass setting the hint for connection tracker processing when there
+ are stateful ACLs or LB rules; REGBIT_ACL_STATELESS is set for traffic
+ matching stateless ACL flows.
This table also has a priority-110 flow with the match eth.dst == E for
all logical switch datapaths to move traffic to the next table. Where E
- is the service monitor mac defined in the options:svc_monitor_mac col‐
+ is the service monitor mac defined in the options:svc_monitor_mac col‐
umn of NB_Global table.
Ingress Table 5: Pre-LB
@@ -546,19 +536,19 @@ LOGICAL FLOW TABLE STRUCTURE
priority-110 flows to move multicast, IPv6 Neighbor Discovery and MLD
traffic to the next table. It also contains two priority-110 flows to
move stateless traffic, i.e traffic for which REGBIT_ACL_STATELESS is
- set, to the next table. If load balancing rules with virtual IP
- addresses (and ports) are configured in OVN_Northbound database for a
+ set, to the next table. If load balancing rules with virtual IP ad‐
+ dresses (and ports) are configured in OVN_Northbound database for a
logical switch datapath, a priority-100 flow is added with the match ip
to match on IP packets and sets the action reg0[2] = 1; next; to act as
a hint for table Pre-stateful to send IP packets to the connection
- tracker for packet de-fragmentation (and to possibly do DNAT for
- already established load balanced traffic) before eventually advancing
- to ingress table Stateful. If controller_event has been enabled and
- load balancing rules with empty backends have been added in OVN_North‐
- bound, a 130 flow is added to trigger ovn-controller events whenever
- the chassis receives a packet for that particular VIP. If event-elb
- meter has been previously created, it will be associated to the
- empty_lb logical flow
+ tracker for packet de-fragmentation (and to possibly do DNAT for al‐
+ ready established load balanced traffic) before eventually advancing to
+ ingress table Stateful. If controller_event has been enabled and load
+ balancing rules with empty backends have been added in OVN_Northbound,
+ a 130 flow is added to trigger ovn-controller events whenever the chas‐
+ sis receives a packet for that particular VIP. If event-elb meter has
+ been previously created, it will be associated to the empty_lb logical
+ flow
Prior to OVN 20.09 we were setting the reg0[0] = 1 only if the IP des‐
tination matches the load balancer VIP. However this had few issues
@@ -566,7 +556,7 @@ LOGICAL FLOW TABLE STRUCTURE
action. To understand the issue lets a take a TCP load balancer -
10.0.0.10:80=10.0.0.3:80. If a logical port - p1 with IP - 10.0.0.5
opens a TCP connection with the VIP - 10.0.0.10, then the packet in the
- ingress pipeline of ’p1’ is sent to the p1’s conntrack zone id and the
+ ingress pipeline of ’p1’ is sent to the p1’s conntrack zone id and the
packet is load balanced to the backend - 10.0.0.3. For the reply packet
from the backend lport, it is not sent to the conntrack of backend
lport’s zone id. This is fine as long as the packet is valid. Suppose
@@ -592,7 +582,7 @@ LOGICAL FLOW TABLE STRUCTURE
This table also has a priority-110 flow with the match inport == I for
all logical switch datapaths to move traffic to the next table. Where I
- is the peer of a logical router port. This flow is added to skip the
+ is the peer of a logical router port. This flow is added to skip the
connection tracking of packets which enter from logical router datapath
to logical switch datapath.
@@ -602,9 +592,9 @@ LOGICAL FLOW TABLE STRUCTURE
tables. It contains a priority-0 flow that simply moves traffic to the
next table.
- · Priority-120 flows that send the packets to connection
- tracker using ct_lb_mark; as the action so that the
- already established traffic destined to the load balancer
+ • Priority-120 flows that send the packets to connection
+ tracker using ct_lb_mark; as the action so that the al‐
+ ready established traffic destined to the load balancer
VIP gets DNATted. These flows match each VIPs IP and
port. For IPv4 traffic the flows also load the original
destination IP and transport port in registers reg1 and
@@ -612,227 +602,279 @@ LOGICAL FLOW TABLE STRUCTURE
destination IP and transport port in registers xxreg1 and
reg2.
- · A priority-110 flow sends the packets that don’t match
- the above flows to connection tracker based on a hint
+ • A priority-110 flow sends the packets that don’t match
+ the above flows to connection tracker based on a hint
provided by the previous tables (with a match for reg0[2]
== 1) by using the ct_lb_mark; action.
- · A priority-100 flow sends the packets to connection
+ • A priority-100 flow sends the packets to connection
tracker based on a hint provided by the previous tables
- (with a match for reg0[0] == 1) by using the ct_next;
- action.
+ (with a match for reg0[0] == 1) by using the ct_next; ac‐
+ tion.
Ingress Table 7: from-lport ACL hints
- This table consists of logical flows that set hints (reg0 bits) to be
- used in the next stage, in the ACL processing table, if stateful ACLs
- or load balancers are configured. Multiple hints can be set for the
+ This table consists of logical flows that set hints (reg0 bits) to be
+ used in the next stage, in the ACL processing table, if stateful ACLs
+ or load balancers are configured. Multiple hints can be set for the
same packet. The possible hints are:
- · reg0[7]: the packet might match an allow-related ACL and
+ • reg0[7]: the packet might match an allow-related ACL and
might have to commit the connection to conntrack.
- · reg0[8]: the packet might match an allow-related ACL but
- there will be no need to commit the connection to con‐
+ • reg0[8]: the packet might match an allow-related ACL but
+ there will be no need to commit the connection to con‐
ntrack because it already exists.
- · reg0[9]: the packet might match a drop/reject.
+ • reg0[9]: the packet might match a drop/reject.
- · reg0[10]: the packet might match a drop/reject ACL but
+ • reg0[10]: the packet might match a drop/reject ACL but
the connection was previously allowed so it might have to
be committed again with ct_label=1/1.
The table contains the following flows:
- · A priority-65535 flow to advance to the next table if the
+ • A priority-65535 flow to advance to the next table if the
logical switch has no ACLs configured, otherwise a prior‐
ity-0 flow to advance to the next table.
- · A priority-7 flow that matches on packets that initiate a
- new session. This flow sets reg0[7] and reg0[9] and then
+ • A priority-7 flow that matches on packets that initiate a
+ new session. This flow sets reg0[7] and reg0[9] and then
advances to the next table.
- · A priority-6 flow that matches on packets that are in the
+ • A priority-6 flow that matches on packets that are in the
request direction of an already existing session that has
- been marked as blocked. This flow sets reg0[7] and
+ been marked as blocked. This flow sets reg0[7] and
reg0[9] and then advances to the next table.
- · A priority-5 flow that matches untracked packets. This
- flow sets reg0[8] and reg0[9] and then advances to the
+ • A priority-5 flow that matches untracked packets. This
+ flow sets reg0[8] and reg0[9] and then advances to the
next table.
- · A priority-4 flow that matches on packets that are in the
+ • A priority-4 flow that matches on packets that are in the
request direction of an already existing session that has
- not been marked as blocked. This flow sets reg0[8] and
+ not been marked as blocked. This flow sets reg0[8] and
reg0[10] and then advances to the next table.
- · A priority-3 flow that matches on packets that are in not
+ • A priority-3 flow that matches on packets that are in not
part of established sessions. This flow sets reg0[9] and
then advances to the next table.
- · A priority-2 flow that matches on packets that are part
+ • A priority-2 flow that matches on packets that are part
of an established session that has been marked as
blocked. This flow sets reg0[9] and then advances to the
next table.
- · A priority-1 flow that matches on packets that are part
+ • A priority-1 flow that matches on packets that are part
of an established session that has not been marked as
blocked. This flow sets reg0[10] and then advances to the
next table.
- Ingress table 8: from-lport ACLs before LB
+ Ingress table 8: from-lport ACL evaluation before LB
Logical flows in this table closely reproduce those in the ACL table in
the OVN_Northbound database for the from-lport direction without the
option apply-after-lb set or set to false. The priority values from the
- ACL table have a limited range and have 1000 added to them to leave
+ ACL table have a limited range and have 1000 added to them to leave
room for OVN default flows at both higher and lower priorities.
- · allow ACLs translate into logical flows with the next;
- action. If there are any stateful ACLs on this datapath,
- then allow ACLs translate to ct_commit; next; (which acts
- as a hint for the next tables to commit the connection to
- conntrack). In case the ACL has a label then reg3 is
- loaded with the label value and reg0[13] bit is set to 1
- (which acts as a hint for the next tables to commit the
- label to conntrack).
-
- · allow-related ACLs translate into logical flows with the
- ct_commit(ct_label=0/1); next; actions for new connec‐
- tions and reg0[1] = 1; next; for existing connections. In
- case the ACL has a label then reg3 is loaded with the
- label value and reg0[13] bit is set to 1 (which acts as a
- hint for the next tables to commit the label to con‐
- ntrack).
-
- · allow-stateless ACLs translate into logical flows with
- the next; action.
-
- · reject ACLs translate into logical flows with the
- tcp_reset { output <-> inport; next(pipeline=egress,ta‐
- ble=5);} action for TCP connections,icmp4/icmp6 action
- for UDP connections, and sctp_abort {output <-%gt;
- inport; next(pipeline=egress,table=5);} action for SCTP
- associations.
-
- · Other ACLs translate to drop; for new or untracked con‐
- nections and ct_commit(ct_label=1/1); for known connec‐
- tions. Setting ct_label marks a connection as one that
- was previously allowed, but should no longer be allowed
- due to a policy change.
-
- This table contains a priority-65535 flow to advance to the next table
- if the logical switch has no ACLs configured, otherwise a priority-0
- flow to advance to the next table so that ACLs allow packets by default
- if options:default_acl_drop column of NB_Global is false or not set.
- Otherwise the flow action is set to drop; to implement a default drop
- behavior.
-
- If the logical datapath has a stateful ACL or a load balancer with VIP
- configured, the following flows will also be added:
-
- · If options:default_acl_drop column of NB_Global is false
- or not set, a priority-1 flow that sets the hint to com‐
- mit IP traffic that is not part of established sessions
- to the connection tracker (with action reg0[1] = 1;
- next;). This is needed for the default allow policy
- because, while the initiator’s direction may not have any
- stateful rules, the server’s may and then its return
- traffic would not be known and marked as invalid.
+ • This table is responsible for evaluating ACLs, and set‐
+ ting a register bit to indicate whether the ACL decided
+ to allow, drop, or reject the traffic. The allow bit is
+ reg8[16]. The drop bit is reg8[17]. All flows in this ta‐
+ ble will advance the packet to the next table, where the
+ bits from before are evaluated to determine what to do
+ with the packet. Any flows in this table that intend for
+ the packet to pass will set reg8[16] to 1, even if an ACL
+ with an allow-type action was not matched. This lets the
+ next table know to allow the traffic to pass. These bits
+ will be referred to as the "allow", "drop", and "reject"
+ bits in the upcoming paragraphs.
+
+ • If the tier column has been configured on the ACL, then
+ OVN will also match the current tier counter against the
+ configured ACL tier. OVN keeps count of the current tier
+ in reg8[30..31].
+
+ • allow ACLs translate into logical flows that set the al‐
+ low bit to 1 and advance the packet to the next table. If
+ there are any stateful ACLs on this datapath, then allow
+ ACLs set the allow bit to one and in addition perform
+ ct_commit; (which acts as a hint for future tables to
+ commit the connection to conntrack). In case the ACL has
+ a label then reg3 is loaded with the label value and
+ reg0[13] bit is set to 1 (which acts as a hint for the
+ next tables to commit the label to conntrack).
+
+ • allow-related ACLs translate into logical flows that set
+ the allow bit and additionally have ct_commit(ct_la‐
+ bel=0/1); next; actions for new connections and reg0[1] =
+ 1; next; for existing connections. In case the ACL has a
+ label then reg3 is loaded with the label value and
+ reg0[13] bit is set to 1 (which acts as a hint for the
+ next tables to commit the label to conntrack).
+
+ • allow-stateless ACLs translate into logical flows that
+ set the allow bit and advance to the next table.
+
+ • reject ACLs translate into logical flows with that set
+ the reject bit and advance to the next table.
+
+ • pass ACLs translate into logical flows that do not set
+ the allow, drop, or reject bit and advance to the next
+ table.
- · If options:default_acl_drop column of NB_Global is true,
- a priority-1 flow that drops IP traffic that is not part
- of established sessions.
+ • Other ACLs set the drop bit and advance to the next table
+ for new or untracked connections. For known connections,
+ they set the drop bit, as well as running the ct_com‐
+ mit(ct_label=1/1); action. Setting ct_label marks a con‐
+ nection as one that was previously allowed, but should no
+ longer be allowed due to a policy change.
+
+ This table contains a priority-65535 flow to set the allow bit and ad‐
+ vance to the next table if the logical switch has no ACLs configured,
+ otherwise a priority-0 flow to advance to the next table is added. This
+ flow does not set the allow bit, so that the next table can decide
+ whether to allow or drop the packet based on the value of the op‐
+ tions:default_acl_drop column of the NB_Global table.
+
+ A priority-65532 flow is added that sets the allow bit for IPv6 Neigh‐
+ bor solicitation, Neighbor discover, Router solicitation, Router adver‐
+ tisement and MLD packets regardless of other ACLs defined.
+
+ If the logical datapath has a stateful ACL or a load balancer with VIP
+ configured, the following flows will also be added:
- · A priority-1 flow that sets the hint to commit IP traffic
+ • If options:default_acl_drop column of NB_Global is false
+ or not set, a priority-1 flow that sets the hint to com‐
+ mit IP traffic that is not part of established sessions
to the connection tracker (with action reg0[1] = 1;
- next;). This is needed for the default allow policy
- because, while the initiator’s direction may not have any
+ next;). This is needed for the default allow policy be‐
+ cause, while the initiator’s direction may not have any
stateful rules, the server’s may and then its return
traffic would not be known and marked as invalid.
- · A priority-65532 flow that allows any traffic in the
- reply direction for a connection that has been committed
- to the connection tracker (i.e., established flows), as
- long as the committed flow does not have ct_mark.blocked
- set. We only handle traffic in the reply direction here
- because we want all packets going in the request direc‐
- tion to still go through the flows that implement the
- currently defined policy based on ACLs. If a connection
- is no longer allowed by policy, ct_mark.blocked will get
- set and packets in the reply direction will no longer be
- allowed, either. This flow also clears the register bits
- reg0[9] and reg0[10]. If ACL logging and logging of
- related packets is enabled, then a companion prior‐
- ity-65533 flow will be installed that accomplishes the
- same thing but also logs the traffic.
-
- · A priority-65532 flow that allows any traffic that is
- considered related to a committed flow in the connection
- tracker (e.g., an ICMP Port Unreachable from a non-lis‐
- tening UDP port), as long as the committed flow does not
- have ct_mark.blocked set. This flow also applies NAT to
- the related traffic so that ICMP headers and the inner
- packet have correct addresses. If ACL logging and logging
- of related packets is enabled, then a companion prior‐
- ity-65533 flow will be installed that accomplishes the
- same thing but also logs the traffic.
-
- · A priority-65532 flow that drops all traffic marked by
- the connection tracker as invalid.
-
- · A priority-65532 flow that drops all traffic in the reply
- direction with ct_mark.blocked set meaning that the con‐
- nection should no longer be allowed due to a policy
- change. Packets in the request direction are skipped here
- to let a newly created ACL re-allow this connection.
-
- · A priority-65532 flow that allows IPv6 Neighbor solicita‐
- tion, Neighbor discover, Router solicitation, Router
- advertisement and MLD packets.
+ • A priority-1 flow that sets the allow bit and sets the
+ hint to commit IP traffic to the connection tracker (with
+ action reg0[1] = 1; next;). This is needed for the de‐
+ fault allow policy because, while the initiator’s direc‐
+ tion may not have any stateful rules, the server’s may
+ and then its return traffic would not be known and marked
+ as invalid.
+
+ • A priority-65532 flow that sets the allow bit for any
+ traffic in the reply direction for a connection that has
+ been committed to the connection tracker (i.e., estab‐
+ lished flows), as long as the committed flow does not
+ have ct_mark.blocked set. We only handle traffic in the
+ reply direction here because we want all packets going in
+ the request direction to still go through the flows that
+ implement the currently defined policy based on ACLs. If
+ a connection is no longer allowed by policy,
+ ct_mark.blocked will get set and packets in the reply di‐
+ rection will no longer be allowed, either. This flow also
+ clears the register bits reg0[9] and reg0[10] and sets
+ register bit reg0[17]. If ACL logging and logging of re‐
+ lated packets is enabled, then a companion priority-65533
+ flow will be installed that accomplishes the same thing
+ but also logs the traffic.
+
+ • A priority-65532 flow that sets the allow bit for any
+ traffic that is considered related to a committed flow in
+ the connection tracker (e.g., an ICMP Port Unreachable
+ from a non-listening UDP port), as long as the committed
+ flow does not have ct_mark.blocked set. This flow also
+ applies NAT to the related traffic so that ICMP headers
+ and the inner packet have correct addresses. If ACL log‐
+ ging and logging of related packets is enabled, then a
+ companion priority-65533 flow will be installed that ac‐
+ complishes the same thing but also logs the traffic.
+
+ • A priority-65532 flow that sets the drop bit for all
+ traffic marked by the connection tracker as invalid.
+
+ • A priority-65532 flow that sets the drop bit for all
+ traffic in the reply direction with ct_mark.blocked set
+ meaning that the connection should no longer be allowed
+ due to a policy change. Packets in the request direction
+ are skipped here to let a newly created ACL re-allow this
+ connection.
If the logical datapath has any ACL or a load balancer with VIP config‐
ured, the following flow will also be added:
- · A priority 34000 logical flow is added for each logical
- switch datapath with the match eth.dst = E to allow the
- service monitor reply packet destined to ovn-controller
- with the action next, where E is the service monitor mac
- defined in the options:svc_monitor_mac column of
+ • A priority 34000 logical flow is added for each logical
+ switch datapath with the match eth.dst = E to allow the
+ service monitor reply packet destined to ovn-controller
+ that sets the allow bit, where E is the service monitor
+ mac defined in the options:svc_monitor_mac column of
NB_Global table.
- Ingress Table 9: from-lport QoS Marking
+ Ingress Table 9: from-lport ACL action
+
+ Logical flows in this table decide how to proceed based on the values
+ of the allow, drop, and reject bits that may have been set in the pre‐
+ vious table.
+
+ • If no ACLs are configured, then a priority 0 flow is in‐
+ stalled that matches everything and advances to the next
+ table.
+
+ • A priority 1000 flow is installed that will advance the
+ packet to the next table if the allow bit is set.
+
+ • A priority 1000 flow is installed that will run the drop;
+ action if the drop bit is set.
+
+ • A priority 1000 flow is installed that will run the
+ tcp_reset { output <-> inport; next(pipeline=egress,ta‐
+ ble=5);} action for TCP connections,icmp4/icmp6 action
+ for UDP connections, and sctp_abort {output <-%gt; in‐
+ port; next(pipeline=egress,table=5);} action for SCTP as‐
+ sociations.
+
+ • If any ACLs have tiers configured on them, then three
+ priority 500 flows are installed. If the current tier
+ counter is 0, 1, or 2, then the current tier counter is
+ incremented by one and the packet is sent back to the
+ previous table for re-evaluation.
+
+ Ingress Table 10: from-lport QoS Marking
Logical flows in this table closely reproduce those in the QoS table
with the action column set in the OVN_Northbound database for the
from-lport direction.
- · For every qos_rules entry in a logical switch with DSCP
+ • For every qos_rules entry in a logical switch with DSCP
marking enabled, a flow will be added at the priority
mentioned in the QoS table.
- · One priority-0 fallback flow that matches all packets and
+ • For every qos_rules entry in a logical switch with packet
+ marking enabled, a flow will be added at the priority
+ mentioned in the QoS table.
+
+ • One priority-0 fallback flow that matches all packets and
advances to the next table.
- Ingress Table 10: from-lport QoS Meter
+ Ingress Table 11: from-lport QoS Meter
Logical flows in this table closely reproduce those in the QoS table
with the bandwidth column set in the OVN_Northbound database for the
from-lport direction.
- · For every qos_rules entry in a logical switch with meter‐
- ing enabled, a flow will be added at the priority men‐
+ • For every qos_rules entry in a logical switch with meter‐
+ ing enabled, a flow will be added at the priority men‐
tioned in the QoS table.
- · One priority-0 fallback flow that matches all packets and
+ • One priority-0 fallback flow that matches all packets and
advances to the next table.
- Ingress Table 11: Load balancing affinity check
+ Ingress Table 12: Load balancing affinity check
Load balancing affinity check table contains the following logical
flows:
- · For all the configured load balancing rules for a switch
+ • For all the configured load balancing rules for a switch
in OVN_Northbound database where a positive affinity
timeout is specified in options column, that includes a
L4 port PORT of protocol P and IP address VIP, a prior‐
@@ -842,26 +884,26 @@ LOGICAL FLOW TABLE STRUCTURE
&& P.dst == PORT. The flow’s action is reg9[6] =
chk_lb_aff(); next;.
- · A priority 0 flow is added which matches on all packets
+ • A priority 0 flow is added which matches on all packets
and applies the action next;.
- Ingress Table 12: LB
+ Ingress Table 13: LB
- · For all the configured load balancing rules for a switch
+ • For all the configured load balancing rules for a switch
in OVN_Northbound database where a positive affinity
timeout is specified in options column, that includes a
L4 port PORT of protocol P and IP address VIP, a prior‐
ity-150 flow is added. For IPv4 VIPs, the flow matches
reg9[6] == 1 && ct.new && ip && ip4.dst == VIP && P.dst
== PORT . For IPv6 VIPs, the flow matches reg9[6] == 1 &&
- ct.new && ip && ip6.dst == VIP && P && P.dst == PORT.
- The flow’s action is ct_lb_mark(args), where args con‐
- tains comma separated IP addresses (and optional port
+ ct.new && ip && ip6.dst == VIP && P && P.dst == PORT.
+ The flow’s action is ct_lb_mark(args), where args con‐
+ tains comma separated IP addresses (and optional port
numbers) to load balance to. The address family of the IP
addresses of args is the same as the address family of
VIP.
- · For all the configured load balancing rules for a switch
+ • For all the configured load balancing rules for a switch
in OVN_Northbound database that includes a L4 port PORT
of protocol P and IP address VIP, a priority-120 flow is
added. For IPv4 VIPs , the flow matches ct.new && ip &&
@@ -870,7 +912,7 @@ LOGICAL FLOW TABLE STRUCTURE
PORT. The flow’s action is ct_lb_mark(args) , where args
contains comma separated IP addresses (and optional port
numbers) to load balance to. The address family of the IP
- addresses of args is the same as the address family of
+ addresses of args is the same as the address family of
VIP. If health check is enabled, then args will only con‐
tain those endpoints whose service monitor status entry
in OVN_Southbound db is either online or empty. For IPv4
@@ -878,43 +920,43 @@ LOGICAL FLOW TABLE STRUCTURE
and transport port in registers reg1 and reg2. For IPv6
traffic the flow also loads the original destination IP
and transport port in registers xxreg1 and reg2. The
- above flow is created even if the load balancer is
- attached to a logical router connected to the current
- logical switch and the install_ls_lb_from_router variable
- in options is set to true.
-
- · For all the configured load balancing rules for a switch
- in OVN_Northbound database that includes just an IP
- address VIP to match on, OVN adds a priority-110 flow.
- For IPv4 VIPs, the flow matches ct.new && ip && ip4.dst
- == VIP. For IPv6 VIPs, the flow matches ct.new && ip &&
- ip6.dst == VIP. The action on this flow is
- ct_lb_mark(args), where args contains comma separated IP
- addresses of the same address family as VIP. For IPv4
- traffic the flow also loads the original destination IP
- and transport port in registers reg1 and reg2. For IPv6
- traffic the flow also loads the original destination IP
- and transport port in registers xxreg1 and reg2. The
- above flow is created even if the load balancer is
- attached to a logical router connected to the current
- logical switch and the install_ls_lb_from_router variable
- in options is set to true.
-
- · If the load balancer is created with --reject option and
+ above flow is created even if the load balancer is at‐
+ tached to a logical router connected to the current logi‐
+ cal switch and the install_ls_lb_from_router variable in
+ options is set to true.
+
+ • For all the configured load balancing rules for a switch
+ in OVN_Northbound database that includes just an IP ad‐
+ dress VIP to match on, OVN adds a priority-110 flow. For
+ IPv4 VIPs, the flow matches ct.new && ip && ip4.dst ==
+ VIP. For IPv6 VIPs, the flow matches ct.new && ip &&
+ ip6.dst == VIP. The action on this flow is
+ ct_lb_mark(args), where args contains comma separated IP
+ addresses of the same address family as VIP. For IPv4
+ traffic the flow also loads the original destination IP
+ and transport port in registers reg1 and reg2. For IPv6
+ traffic the flow also loads the original destination IP
+ and transport port in registers xxreg1 and reg2. The
+ above flow is created even if the load balancer is at‐
+ tached to a logical router connected to the current logi‐
+ cal switch and the install_ls_lb_from_router variable in
+ options is set to true.
+
+ • If the load balancer is created with --reject option and
it has no active backends, a TCP reset segment (for tcp)
or an ICMP port unreachable packet (for all other kind of
- traffic) will be sent whenever an incoming packet is
- received for this load-balancer. Please note using
- --reject option will disable empty_lb SB controller event
- for this load balancer.
+ traffic) will be sent whenever an incoming packet is re‐
+ ceived for this load-balancer. Please note using --reject
+ option will disable empty_lb SB controller event for this
+ load balancer.
- Ingress Table 13: Load balancing affinity learn
+ Ingress Table 14: Load balancing affinity learn
- Load balancing affinity learn table contains the following logical
+ Load balancing affinity learn table contains the following logical
flows:
- · For all the configured load balancing rules for a switch
- in OVN_Northbound database where a positive affinity
+ • For all the configured load balancing rules for a switch
+ in OVN_Northbound database where a positive affinity
timeout T is specified in options column, that includes a
L4 port PORT of protocol P and IP address VIP, a prior‐
ity-100 flow is added. For IPv4 VIPs, the flow matches
@@ -924,74 +966,12 @@ LOGICAL FLOW TABLE STRUCTURE
is commit_lb_aff(vip = VIP:PORT, backend = backend ip:
backend port, proto = P, timeout = T); .
- · A priority 0 flow is added which matches on all packets
+ • A priority 0 flow is added which matches on all packets
and applies the action next;.
- Ingress table 14: from-lport ACLs after LB
-
- Logical flows in this table closely reproduce those in the ACL table in
- the OVN_Northbound database for the from-lport direction with the
- option apply-after-lb set to true. The priority values from the ACL ta‐
- ble have a limited range and have 1000 added to them to leave room for
- OVN default flows at both higher and lower priorities.
+ Ingress Table 15: Pre-Hairpin
- · allow apply-after-lb ACLs translate into logical flows
- with the next; action. If there are any stateful ACLs
- (including both before-lb and after-lb ACLs) on this
- datapath, then allow ACLs translate to ct_commit; next;
- (which acts as a hint for the next tables to commit the
- connection to conntrack). In case the ACL has a label
- then reg3 is loaded with the label value and reg0[13] bit
- is set to 1 (which acts as a hint for the next tables to
- commit the label to conntrack).
-
- · allow-related apply-after-lb ACLs translate into logical
- flows with the ct_commit(ct_label=0/1); next; actions for
- new connections and reg0[1] = 1; next; for existing con‐
- nections. In case the ACL has a label then reg3 is loaded
- with the label value and reg0[13] bit is set to 1 (which
- acts as a hint for the next tables to commit the label to
- conntrack).
-
- · allow-stateless apply-after-lb ACLs translate into logi‐
- cal flows with the next; action.
-
- · reject apply-after-lb ACLs translate into logical flows
- with the tcp_reset { output <-> inport; next(pipe‐
- line=egress,table=5);} action for TCP connec‐
- tions,icmp4/icmp6 action for UDP connections, and
- sctp_abort {output <-%gt; inport; next(pipe‐
- line=egress,table=5);} action for SCTP associations.
-
- · Other apply-after-lb ACLs translate to drop; for new or
- untracked connections and ct_commit(ct_label=1/1); for
- known connections. Setting ct_label marks a connection as
- one that was previously allowed, but should no longer be
- allowed due to a policy change.
-
- · One priority-0 fallback flow that matches all packets and
- advances to the next table.
-
- Ingress Table 15: Stateful
-
- · A priority 100 flow is added which commits the packet to
- the conntrack and sets the most significant 32-bits of
- ct_label with the reg3 value based on the hint provided
- by previous tables (with a match for reg0[1] == 1 &&
- reg0[13] == 1). This is used by the ACLs with label to
- commit the label value to conntrack.
-
- · For ACLs without label, a second priority-100 flow com‐
- mits packets to connection tracker using ct_commit; next;
- action based on a hint provided by the previous tables
- (with a match for reg0[1] == 1 && reg0[13] == 0).
-
- · A priority-0 flow that simply moves traffic to the next
- table.
-
- Ingress Table 16: Pre-Hairpin
-
- · If the logical switch has load balancer(s) configured,
+ • If the logical switch has load balancer(s) configured,
then a priority-100 flow is added with the match ip &&
ct.trk to check if the packet needs to be hairpinned (if
after load balancing the destination IP matches the
@@ -999,61 +979,173 @@ LOGICAL FLOW TABLE STRUCTURE
chk_lb_hairpin(); and reg0[12] = chk_lb_hairpin_reply();
and advances the packet to the next table.
- · A priority-0 flow that simply moves traffic to the next
+ • A priority-0 flow that simply moves traffic to the next
table.
- Ingress Table 17: Nat-Hairpin
+ Ingress Table 16: Nat-Hairpin
- · If the logical switch has load balancer(s) configured,
+ • If the logical switch has load balancer(s) configured,
then a priority-100 flow is added with the match ip &&
ct.new && ct.trk && reg0[6] == 1 which hairpins the traf‐
fic by NATting source IP to the load balancer VIP by exe‐
cuting the action ct_snat_to_vip and advances the packet
to the next table.
- · If the logical switch has load balancer(s) configured,
+ • If the logical switch has load balancer(s) configured,
then a priority-100 flow is added with the match ip &&
ct.est && ct.trk && reg0[6] == 1 which hairpins the traf‐
fic by NATting source IP to the load balancer VIP by exe‐
cuting the action ct_snat and advances the packet to the
next table.
- · If the logical switch has load balancer(s) configured,
+ • If the logical switch has load balancer(s) configured,
then a priority-90 flow is added with the match ip &&
reg0[12] == 1 which matches on the replies of hairpinned
traffic (i.e., destination IP is VIP, source IP is the
backend IP and source L4 port is backend port for L4 load
- balancers) and executes ct_snat and advances the packet
+ balancers) and executes ct_snat and advances the packet
to the next table.
- · A priority-0 flow that simply moves traffic to the next
+ • A priority-0 flow that simply moves traffic to the next
table.
- Ingress Table 18: Hairpin
+ Ingress Table 17: Hairpin
+
+ • If logical switch has attached logical switch port of
+ vtep type, then for each distributed gateway router port
+ RP attached to this logical switch and has chassis redi‐
+ rect port cr-RP, a priority-2000 flow is added with the
+ match .IP
+ reg0[14] == 1 && is_chassis_resident(cr-RP)
- · For each distributed gateway router port RP attached to
- the logical switch, a priority-2000 flow is added with
- the match reg0[14] == 1 && is_chassis_resident(RP)
- and action next; to pass the traffic to the next table
- to respond to the ARP requests for the router port IPs.
+ and action next;.
reg0[14] register bit is set in the ingress L2 port secu‐
rity check table for traffic received from HW VTEP (ramp)
ports.
- · A priority-1000 flow that matches on reg0[14] register
- bit for the traffic received from HW VTEP (ramp) ports.
- This traffic is passed to ingress table ls_in_l2_lkup.
+ • If logical switch has attached logical switch port of
+ vtep type, then a priority-1000 flow that matches on
+ reg0[14] register bit for the traffic received from HW
+ VTEP (ramp) ports. This traffic is passed to ingress ta‐
+ ble ls_in_l2_lkup.
- · A priority-1 flow that hairpins traffic matched by non-
+ • A priority-1 flow that hairpins traffic matched by non-
default flows in the Pre-Hairpin table. Hairpinning is
done at L2, Ethernet addresses are swapped and the pack‐
ets are looped back on the input port.
- · A priority-0 flow that simply moves traffic to the next
+ • A priority-0 flow that simply moves traffic to the next
+ table.
+
+ Ingress table 18: from-lport ACL evaluation after LB
+
+ Logical flows in this table closely reproduce those in the ACL eval ta‐
+ ble in the OVN_Northbound database for the from-lport direction with
+ the option apply-after-lb set to true. The priority values from the ACL
+ table have a limited range and have 1000 added to them to leave room
+ for OVN default flows at both higher and lower priorities. The flows in
+ this table indicate the ACL verdict by setting reg8[16] for allow-type
+ ACLs, reg8[17] for drop ACLs, and reg8[17] for reject ACLs, and then
+ advancing the packet to the next table. These will be reffered to as
+ the allow bit, drop bit, and reject bit throughout the documentation
+ for this table and the next one.
+
+ Like with ACLs that are evaluated before load balancers, if the ACL is
+ configured with a tier value, then the current tier counter, supplied
+ in reg8[30..31] is matched against the ACL’s configured tier in addi‐
+ tion to the ACL’s match.
+
+ • allow apply-after-lb ACLs translate into logical flows
+ that set the allow bit. If there are any stateful ACLs
+ (including both before-lb and after-lb ACLs) on this
+ datapath, then allow ACLs also run ct_commit; next;
+ (which acts as a hint for an upcoming table to commit the
+ connection to conntrack). In case the ACL has a label
+ then reg3 is loaded with the label value and reg0[13] bit
+ is set to 1 (which acts as a hint for the next tables to
+ commit the label to conntrack).
+
+ • allow-related apply-after-lb ACLs translate into logical
+ flows that set the allow bit and run the ct_commit(ct_la‐
+ bel=0/1); next; actions for new connections and reg0[1] =
+ 1; next; for existing connections. In case the ACL has a
+ label then reg3 is loaded with the label value and
+ reg0[13] bit is set to 1 (which acts as a hint for the
+ next tables to commit the label to conntrack).
+
+ • allow-stateless apply-after-lb ACLs translate into logi‐
+ cal flows that set the allow bit and advance to the next
+ table.
+
+ • reject apply-after-lb ACLs translate into logical flows
+ that set the reject bit and advance to the next table.
+
+ • pass apply-after-lb ACLs translate into logical flows
+ that do not set the allow, drop, or reject bit and ad‐
+ vance to the next table.
+
+ • Other apply-after-lb ACLs set the drop bit for new or un‐
+ tracked connections and ct_commit(ct_label=1/1); for
+ known connections. Setting ct_label marks a connection as
+ one that was previously allowed, but should no longer be
+ allowed due to a policy change.
+
+ • One priority-65532 flow matching packets with reg0[17]
+ set (either replies to existing sessions or traffic re‐
+ lated to existing sessions) and allows these by setting
+ the allow bit and advancing to the next table.
+
+ • One priority-0 fallback flow that matches all packets and
+ advances to the next table.
+
+ Ingress Table 19: from-lport ACL action after LB
+
+ Logical flows in this table decide how to proceed based on the values
+ of the allow, drop, and reject bits that may have been set in the pre‐
+ vious table.
+
+ • If no ACLs are configured, then a priority 0 flow is in‐
+ stalled that matches everything and advances to the next
+ table.
+
+ • A priority 1000 flow is installed that will advance the
+ packet to the next table if the allow bit is set.
+
+ • A priority 1000 flow is installed that will run the drop;
+ action if the drop bit is set.
+
+ • A priority 1000 flow is installed that will run the
+ tcp_reset { output <-> inport; next(pipeline=egress,ta‐
+ ble=5);} action for TCP connections,icmp4/icmp6 action
+ for UDP connections, and sctp_abort {output <-%gt; in‐
+ port; next(pipeline=egress,table=5);} action for SCTP as‐
+ sociations.
+
+ • If any ACLs have tiers configured on them, then three
+ priority 500 flows are installed. If the current tier
+ counter is 0, 1, or 2, then the current tier counter is
+ incremented by one and the packet is sent back to the
+ previous table for re-evaluation.
+
+ Ingress Table 20: Stateful
+
+ • A priority 100 flow is added which commits the packet to
+ the conntrack and sets the most significant 32-bits of
+ ct_label with the reg3 value based on the hint provided
+ by previous tables (with a match for reg0[1] == 1 &&
+ reg0[13] == 1). This is used by the ACLs with label to
+ commit the label value to conntrack.
+
+ • For ACLs without label, a second priority-100 flow com‐
+ mits packets to connection tracker using ct_commit; next;
+ action based on a hint provided by the previous tables
+ (with a match for reg0[1] == 1 && reg0[13] == 0).
+
+ • A priority-0 flow that simply moves traffic to the next
table.
- Ingress Table 19: ARP/ND responder
+ Ingress Table 21: ARP/ND responder
This table implements ARP/ND responder in a logical switch for known
IPs. The advantage of the ARP responder flow is to limit ARP broadcasts
@@ -1063,54 +1155,61 @@ LOGICAL FLOW TABLE STRUCTURE
visor rather than broadcast across the whole network and responded to
by the destination VM. This behavior is proxy ARP.
- ARP requests arrive from VMs from a logical switch inport of type
- default. For this case, the logical switch proxy ARP rules can be for
+ ARP requests arrive from VMs from a logical switch inport of type de‐
+ fault. For this case, the logical switch proxy ARP rules can be for
other VMs or logical router ports. Logical switch proxy ARP rules may
be programmed both for mac binding of IP addresses on other logical
switch VIF ports (which are of the default logical switch port type,
representing connectivity to VMs or containers), and for mac binding of
- IP addresses on logical switch router type ports, representing their
- logical router port peers. In order to support proxy ARP for logical
- router ports, an IP address must be configured on the logical switch
- router type port, with the same value as the peer logical router port.
+ IP addresses on logical switch router type ports, representing their
+ logical router port peers. In order to support proxy ARP for logical
+ router ports, an IP address must be configured on the logical switch
+ router type port, with the same value as the peer logical router port.
The configured MAC addresses must match as well. When a VM sends an ARP
request for a distributed logical router port and if the peer router
type port of the attached logical switch does not have an IP address
configured, the ARP request will be broadcast on the logical switch.
One of the copies of the ARP request will go through the logical switch
- router type port to the logical router datapath, where the logical
- router ARP responder will generate a reply. The MAC binding of a dis‐
- tributed logical router, once learned by an associated VM, is used for
- all that VM’s communication needing routing. Hence, the action of a VM
- re-arping for the mac binding of the logical router port should be
+ router type port to the logical router datapath, where the logical
+ router ARP responder will generate a reply. The MAC binding of a dis‐
+ tributed logical router, once learned by an associated VM, is used for
+ all that VM’s communication needing routing. Hence, the action of a VM
+ re-arping for the mac binding of the logical router port should be
rare.
- Logical switch ARP responder proxy ARP rules can also be hit when
- receiving ARP requests externally on a L2 gateway port. In this case,
- the hypervisor acting as an L2 gateway, responds to the ARP request on
- behalf of a destination VM.
+ Logical switch ARP responder proxy ARP rules can also be hit when re‐
+ ceiving ARP requests externally on a L2 gateway port. In this case, the
+ hypervisor acting as an L2 gateway, responds to the ARP request on be‐
+ half of a destination VM.
- Note that ARP requests received from localnet logical inports can
- either go directly to VMs, in which case the VM responds or can hit an
- ARP responder for a logical router port if the packet is used to
- resolve a logical router port next hop address. In either case, logical
+ Note that ARP requests received from localnet logical inports can ei‐
+ ther go directly to VMs, in which case the VM responds or can hit an
+ ARP responder for a logical router port if the packet is used to re‐
+ solve a logical router port next hop address. In either case, logical
switch ARP responder rules will not be hit. It contains these logical
flows:
- · Priority-100 flows to skip the ARP responder if inport is
- of type localnet advances directly to the next table. ARP
- requests sent to localnet ports can be received by multi‐
- ple hypervisors. Now, because the same mac binding rules
- are downloaded to all hypervisors, each of the multiple
- hypervisors will respond. This will confuse L2 learning
- on the source of the ARP requests. ARP requests received
- on an inport of type router are not expected to hit any
- logical switch ARP responder flows. However, no skip
- flows are installed for these packets, as there would be
- some additional flow cost for this and the value appears
- limited.
-
- · If inport V is of type virtual adds a priority-100 logi‐
+ • If packet was received from HW VTEP (ramp switch), and
+ this packet is ARP or Neighbor Solicitation, such packet
+ is passed to next table with max proirity. ARP/ND re‐
+ quests from HW VTEP must be handled in logical router
+ ingress pipeline.
+
+ • If the logical switch has no router ports with op‐
+ tions:arp_proxy configured add a priority-100 flows to
+ skip the ARP responder if inport is of type localnet ad‐
+ vances directly to the next table. ARP requests sent to
+ localnet ports can be received by multiple hypervisors.
+ Now, because the same mac binding rules are downloaded to
+ all hypervisors, each of the multiple hypervisors will
+ respond. This will confuse L2 learning on the source of
+ the ARP requests. ARP requests received on an inport of
+ type router are not expected to hit any logical switch
+ ARP responder flows. However, no skip flows are installed
+ for these packets, as there would be some additional flow
+ cost for this and the value appears limited.
+
+ • If inport V is of type virtual adds a priority-100 logi‐
cal flows for each P configured in the options:virtual-
parents column with the match
@@ -1125,14 +1224,14 @@ LOGICAL FLOW TABLE STRUCTURE
and advances the packet to the next table.
- Where VIP is the virtual ip configured in the column
- options:virtual-ip and NS_MULTICAST_ADDR is solicited-
- node multicast address corresponding to the VIP.
+ Where VIP is the virtual ip configured in the column op‐
+ tions:virtual-ip and NS_MULTICAST_ADDR is solicited-node
+ multicast address corresponding to the VIP.
- · Priority-50 flows that match ARP requests to each known
+ • Priority-50 flows that match ARP requests to each known
IP address A of every logical switch port, and respond
- with ARP replies directly with corresponding Ethernet
- address E:
+ with ARP replies directly with corresponding Ethernet ad‐
+ dress E:
eth.dst = eth.src;
eth.src = E;
@@ -1146,12 +1245,12 @@ LOGICAL FLOW TABLE STRUCTURE
output;
- These flows are omitted for logical ports (other than
- router ports or localport ports) that are down (unless
- ignore_lsp_down is configured as true in options column
+ These flows are omitted for logical ports (other than
+ router ports or localport ports) that are down (unless
+ ignore_lsp_down is configured as true in options column
of NB_Global table of the Northbound database), for logi‐
- cal ports of type virtual, for logical ports with
- ’unknown’ address set and for logical ports of a logical
+ cal ports of type virtual, for logical ports with ’un‐
+ known’ address set and for logical ports of a logical
switch configured with other_config:vlan-passthru=true.
The above ARP responder flows are added for the list of
@@ -1159,7 +1258,7 @@ LOGICAL FLOW TABLE STRUCTURE
Logical_Switch_Port table for logical switch ports of
type router.
- · Priority-50 flows that match IPv6 ND neighbor solicita‐
+ • Priority-50 flows that match IPv6 ND neighbor solicita‐
tions to each known IP address A (and A’s solicited node
address) of every logical switch port except of type
router, and respond with neighbor advertisements directly
@@ -1176,10 +1275,10 @@ LOGICAL FLOW TABLE STRUCTURE
};
- Priority-50 flows that match IPv6 ND neighbor solicita‐
- tions to each known IP address A (and A’s solicited node
- address) of logical switch port of type router, and
- respond with neighbor advertisements directly with corre‐
+ Priority-50 flows that match IPv6 ND neighbor solicita‐
+ tions to each known IP address A (and A’s solicited node
+ address) of logical switch port of type router, and re‐
+ spond with neighbor advertisements directly with corre‐
sponding Ethernet address E:
nd_na_router {
@@ -1193,35 +1292,40 @@ LOGICAL FLOW TABLE STRUCTURE
};
- These flows are omitted for logical ports (other than
- router ports or localport ports) that are down (unless
- ignore_lsp_down is configured as true in options column
+ These flows are omitted for logical ports (other than
+ router ports or localport ports) that are down (unless
+ ignore_lsp_down is configured as true in options column
of NB_Global table of the Northbound database), for logi‐
- cal ports of type virtual and for logical ports with
- ’unknown’ address set.
+ cal ports of type virtual and for logical ports with ’un‐
+ known’ address set.
+
+ The above NDP responder flows are added for the list of
+ IPv6 addresses if defined in options:arp_proxy column of
+ Logical_Switch_Port table for logical switch ports of
+ type router.
- · Priority-100 flows with match criteria like the ARP and
+ • Priority-100 flows with match criteria like the ARP and
ND flows above, except that they only match packets from
the inport that owns the IP addresses in question, with
action next;. These flows prevent OVN from replying to,
for example, an ARP request emitted by a VM for its own
- IP address. A VM only makes this kind of request to
- attempt to detect a duplicate IP address assignment, so
+ IP address. A VM only makes this kind of request to at‐
+ tempt to detect a duplicate IP address assignment, so
sending a reply will prevent the VM from accepting the IP
address that it owns.
- In place of next;, it would be reasonable to use drop;
+ In place of next;, it would be reasonable to use drop;
for the flows’ actions. If everything is working as it is
configured, then this would produce equivalent results,
since no host should reply to the request. But ARPing for
- one’s own IP address is intended to detect situations
- where the network is not working as configured, so drop‐
+ one’s own IP address is intended to detect situations
+ where the network is not working as configured, so drop‐
ping the request would frustrate that intent.
- · For each SVC_MON_SRC_IP defined in the value of the
- ip_port_mappings:ENDPOINT_IP column of Load_Balancer ta‐
- ble, priority-110 logical flow is added with the match
- arp.tpa == SVC_MON_SRC_IP && && arp.op == 1 and applies
+ • For each SVC_MON_SRC_IP defined in the value of the
+ ip_port_mappings:ENDPOINT_IP column of Load_Balancer ta‐
+ ble, priority-110 logical flow is added with the match
+ arp.tpa == SVC_MON_SRC_IP && && arp.op == 1 and applies
the action
eth.dst = eth.src;
@@ -1236,8 +1340,8 @@ LOGICAL FLOW TABLE STRUCTURE
output;
- where E is the service monitor source mac defined in the
- options:svc_monitor_mac column in the NB_Global table.
+ where E is the service monitor source mac defined in the
+ options:svc_monitor_mac column in the NB_Global table.
This mac is used as the source mac in the service monitor
packets for the load balancer endpoint IP health checks.
@@ -1248,7 +1352,22 @@ LOGICAL FLOW TABLE STRUCTURE
These flows are required if an ARP request is sent for
the IP SVC_MON_SRC_IP.
- · For each VIP configured in the table Forwarding_Group a
+ For IPv6 the similar flow is added with the following ac‐
+ tion
+
+ nd_na {
+ eth.dst = eth.src;
+ eth.src = E;
+ ip6.src = A;
+ nd.target = A;
+ nd.tll = E;
+ outport = inport;
+ flags.loopback = 1;
+ output;
+ };
+
+
+ • For each VIP configured in the table Forwarding_Group a
priority-50 logical flow is added with the match arp.tpa
== vip && && arp.op == 1
and applies the action
@@ -1269,26 +1388,26 @@ LOGICAL FLOW TABLE STRUCTURE
vmac.
A is used as either the destination ip for load balancing
- traffic to child ports or as nexthop to hosts behind the
+ traffic to child ports or as nexthop to hosts behind the
child ports.
- These flows are required to respond to an ARP request if
+ These flows are required to respond to an ARP request if
an ARP request is sent for the IP vip.
- · One priority-0 fallback flow that matches all packets and
+ • One priority-0 fallback flow that matches all packets and
advances to the next table.
- Ingress Table 20: DHCP option processing
+ Ingress Table 22: DHCP option processing
This table adds the DHCPv4 options to a DHCPv4 packet from the logical
ports configured with IPv4 address(es) and DHCPv4 options, and simi‐
larly for DHCPv6 options. This table also adds flows for the logical
ports of type external.
- · A priority-100 logical flow is added for these logical
+ • A priority-100 logical flow is added for these logical
ports which matches the IPv4 packet with udp.src = 68 and
- udp.dst = 67 and applies the action put_dhcp_opts and
- advances the packet to the next table.
+ udp.dst = 67 and applies the action put_dhcp_opts and ad‐
+ vances the packet to the next table.
reg0[3] = put_dhcp_opts(offer_ip = ip, options...);
next;
@@ -1300,7 +1419,7 @@ LOGICAL FLOW TABLE STRUCTURE
other kinds of packets, it just stores 0 into reg0[3].
Either way, it continues to the next table.
- · A priority-100 logical flow is added for these logical
+ • A priority-100 logical flow is added for these logical
ports which matches the IPv6 packet with udp.src = 546
and udp.dst = 547 and applies the action put_dhcpv6_opts
and advances the packet to the next table.
@@ -1316,16 +1435,16 @@ LOGICAL FLOW TABLE STRUCTURE
stores 0 into reg0[3]. Either way, it continues to the
next table.
- · A priority-0 flow that matches all packets to advances to
+ • A priority-0 flow that matches all packets to advances to
table 16.
- Ingress Table 21: DHCP responses
+ Ingress Table 23: DHCP responses
- This table implements DHCP responder for the DHCP replies generated by
+ This table implements DHCP responder for the DHCP replies generated by
the previous table.
- · A priority 100 logical flow is added for the logical
- ports configured with DHCPv4 options which matches IPv4
+ • A priority 100 logical flow is added for the logical
+ ports configured with DHCPv4 options which matches IPv4
packets with udp.src == 68 && udp.dst == 67 && reg0[3] ==
1 and responds back to the inport after applying these
actions. If reg0[3] is set to 1, it means that the action
@@ -1341,16 +1460,16 @@ LOGICAL FLOW TABLE STRUCTURE
output;
- where E is the server MAC address and S is the server
- IPv4 address defined in the DHCPv4 options. Note that
+ where E is the server MAC address and S is the server
+ IPv4 address defined in the DHCPv4 options. Note that
ip4.dst field is handled by put_dhcp_opts.
- (This terminates ingress packet processing; the packet
+ (This terminates ingress packet processing; the packet
does not go to the next ingress table.)
- · A priority 100 logical flow is added for the logical
- ports configured with DHCPv6 options which matches IPv6
- packets with udp.src == 546 && udp.dst == 547 && reg0[3]
+ • A priority 100 logical flow is added for the logical
+ ports configured with DHCPv6 options which matches IPv6
+ packets with udp.src == 546 && udp.dst == 547 && reg0[3]
== 1 and responds back to the inport after applying these
actions. If reg0[3] is set to 1, it means that the action
put_dhcpv6_opts was successful.
@@ -1366,25 +1485,25 @@ LOGICAL FLOW TABLE STRUCTURE
output;
- where E is the server MAC address and S is the server
- IPv6 LLA address generated from the server_id defined in
- the DHCPv6 options and A is the IPv6 address defined in
+ where E is the server MAC address and S is the server
+ IPv6 LLA address generated from the server_id defined in
+ the DHCPv6 options and A is the IPv6 address defined in
the logical port’s addresses column.
- (This terminates packet processing; the packet does not
+ (This terminates packet processing; the packet does not
go on the next ingress table.)
- · A priority-0 flow that matches all packets to advances to
+ • A priority-0 flow that matches all packets to advances to
table 17.
- Ingress Table 22 DNS Lookup
+ Ingress Table 24 DNS Lookup
This table looks up and resolves the DNS names to the corresponding
configured IP address(es).
- · A priority-100 logical flow for each logical switch data‐
- path if it is configured with DNS records, which matches
- the IPv4 and IPv6 packets with udp.dst = 53 and applies
+ • A priority-100 logical flow for each logical switch data‐
+ path if it is configured with DNS records, which matches
+ the IPv4 and IPv6 packets with udp.dst = 53 and applies
the action dns_lookup and advances the packet to the next
table.
@@ -1394,18 +1513,18 @@ LOGICAL FLOW TABLE STRUCTURE
For valid DNS packets, this transforms the packet into a
DNS reply if the DNS name can be resolved, and stores 1
into reg0[4]. For failed DNS resolution or other kinds of
- packets, it just stores 0 into reg0[4]. Either way, it
+ packets, it just stores 0 into reg0[4]. Either way, it
continues to the next table.
- Ingress Table 23 DNS Responses
+ Ingress Table 25 DNS Responses
- This table implements DNS responder for the DNS replies generated by
+ This table implements DNS responder for the DNS replies generated by
the previous table.
- · A priority-100 logical flow for each logical switch data‐
+ • A priority-100 logical flow for each logical switch data‐
path if it is configured with DNS records, which matches
the IPv4 and IPv6 packets with udp.dst = 53 && reg0[4] ==
- 1 and responds back to the inport after applying these
+ 1 and responds back to the inport after applying these
actions. If reg0[4] is set to 1, it means that the action
dns_lookup was successful.
@@ -1421,50 +1540,50 @@ LOGICAL FLOW TABLE STRUCTURE
(This terminates ingress packet processing; the packet
does not go to the next ingress table.)
- Ingress table 24 External ports
+ Ingress table 26 External ports
Traffic from the external logical ports enter the ingress datapath
pipeline via the localnet port. This table adds the below logical flows
to handle the traffic from these ports.
- · A priority-100 flow is added for each external logical
- port which doesn’t reside on a chassis to drop the
- ARP/IPv6 NS request to the router IP(s) (of the logical
+ • A priority-100 flow is added for each external logical
+ port which doesn’t reside on a chassis to drop the
+ ARP/IPv6 NS request to the router IP(s) (of the logical
switch) which matches on the inport of the external logi‐
- cal port and the valid eth.src address(es) of the exter‐
+ cal port and the valid eth.src address(es) of the exter‐
nal logical port.
This flow guarantees that the ARP/NS request to the
router IP address from the external ports is responded by
- only the chassis which has claimed these external ports.
+ only the chassis which has claimed these external ports.
All the other chassis, drops these packets.
- A priority-100 flow is added for each external logical
+ A priority-100 flow is added for each external logical
port which doesn’t reside on a chassis to drop any packet
- destined to the router mac - with the match inport ==
- external && eth.src == E && eth.dst == R && !is_chas‐
+ destined to the router mac - with the match inport == ex‐
+ ternal && eth.src == E && eth.dst == R && !is_chas‐
sis_resident("external") where E is the external port mac
and R is the router port mac.
- · A priority-0 flow that matches all packets to advances to
+ • A priority-0 flow that matches all packets to advances to
table 20.
- Ingress Table 25 Destination Lookup
+ Ingress Table 27 Destination Lookup
- This table implements switching behavior. It contains these logical
+ This table implements switching behavior. It contains these logical
flows:
- · A priority-110 flow with the match eth.src == E for all
- logical switch datapaths and applies the action han‐
+ • A priority-110 flow with the match eth.src == E for all
+ logical switch datapaths and applies the action han‐
dle_svc_check(inport). Where E is the service monitor mac
defined in the options:svc_monitor_mac column of
NB_Global table.
- · A priority-100 flow that punts all IGMP/MLD packets to
+ • A priority-100 flow that punts all IGMP/MLD packets to
ovn-controller if multicast snooping is enabled on the
logical switch.
- · Priority-90 flows that forward registered IP multicast
+ • Priority-90 flows that forward registered IP multicast
traffic to their corresponding multicast group, which
ovn-northd creates based on learnt IGMP_Group entries.
The flows also forward packets to the MC_MROUTER_FLOOD
@@ -1472,34 +1591,34 @@ LOGICAL FLOW TABLE STRUCTURE
logical ports that are connected to logical routers with
options:mcast_relay=’true’.
- · A priority-85 flow that forwards all IP multicast traffic
+ • A priority-85 flow that forwards all IP multicast traffic
destined to 224.0.0.X to the MC_FLOOD_L2 multicast group,
which ovn-northd populates with all non-router logical
ports.
- · A priority-85 flow that forwards all IP multicast traffic
- destined to reserved multicast IPv6 addresses (RFC 4291,
- 2.7.1, e.g., Solicited-Node multicast) to the MC_FLOOD
- multicast group, which ovn-northd populates with all
- enabled logical ports.
+ • A priority-85 flow that forwards all IP multicast traffic
+ destined to reserved multicast IPv6 addresses (RFC 4291,
+ 2.7.1, e.g., Solicited-Node multicast) to the MC_FLOOD
+ multicast group, which ovn-northd populates with all en‐
+ abled logical ports.
- · A priority-80 flow that forwards all unregistered IP mul‐
+ • A priority-80 flow that forwards all unregistered IP mul‐
ticast traffic to the MC_STATIC multicast group, which
ovn-northd populates with all the logical ports that have
- options :mcast_flood=’true’. The flow also forwards
- unregistered IP multicast traffic to the MC_MROUTER_FLOOD
- multicast group, which ovn-northd populates with all the
- logical ports connected to logical routers that have
- options :mcast_relay=’true’.
-
- · A priority-80 flow that drops all unregistered IP multi‐
- cast traffic if other_config :mcast_snoop=’true’ and
- other_config :mcast_flood_unregistered=’false’ and the
- switch is not connected to a logical router that has
- options :mcast_relay=’true’ and the switch doesn’t have
- any logical port with options :mcast_flood=’true’.
-
- · Priority-80 flows for each IP address/VIP/NAT address
+ options :mcast_flood=’true’. The flow also forwards un‐
+ registered IP multicast traffic to the MC_MROUTER_FLOOD
+ multicast group, which ovn-northd populates with all the
+ logical ports connected to logical routers that have op‐
+ tions :mcast_relay=’true’.
+
+ • A priority-80 flow that drops all unregistered IP multi‐
+ cast traffic if other_config :mcast_snoop=’true’ and
+ other_config :mcast_flood_unregistered=’false’ and the
+ switch is not connected to a logical router that has op‐
+ tions :mcast_relay=’true’ and the switch doesn’t have any
+ logical port with options :mcast_flood=’true’.
+
+ • Priority-80 flows for each IP address/VIP/NAT address
owned by a router port connected to the switch. These
flows match ARP requests and ND packets for the specific
IP addresses. Matched packets are forwarded only to the
@@ -1507,75 +1626,80 @@ LOGICAL FLOW TABLE STRUCTURE
multicast group which contains all non-router logical
ports.
- · Priority-75 flows for each port connected to a logical
- router matching self originated ARP request/RARP
- request/ND packets. These packets are flooded to the
+ • Priority-75 flows for each port connected to a logical
+ router matching self originated ARP request/RARP re‐
+ quest/ND packets. These packets are flooded to the
MC_FLOOD_L2 which contains all non-router logical ports.
- · A priority-70 flow that outputs all packets with an Eth‐
+ • A priority-72 flow that outputs all ARP requests and ND
+ packets with an Ethernet broadcast or multicast eth.dst
+ to the MC_FLOOD_L2 multicast group if other_config:broad‐
+ cast-arps-to-all-routers=true.
+
+ • A priority-70 flow that outputs all packets with an Eth‐
ernet broadcast or multicast eth.dst to the MC_FLOOD mul‐
ticast group.
- · One priority-50 flow that matches each known Ethernet
- address against eth.dst. Action of this flow outputs the
- packet to the single associated output port if it is
- enabled. drop; action is applied if LSP is disabled.
+ • One priority-50 flow that matches each known Ethernet ad‐
+ dress against eth.dst. Action of this flow outputs the
+ packet to the single associated output port if it is en‐
+ abled. drop; action is applied if LSP is disabled.
For the Ethernet address on a logical switch port of type
- router, when that logical switch port’s addresses column
- is set to router and the connected logical router port
+ router, when that logical switch port’s addresses column
+ is set to router and the connected logical router port
has a gateway chassis:
- · The flow for the connected logical router port’s
+ • The flow for the connected logical router port’s
Ethernet address is only programmed on the gateway
chassis.
- · If the logical router has rules specified in nat
+ • If the logical router has rules specified in nat
with external_mac, then those addresses are also
used to populate the switch’s destination lookup
on the chassis where logical_port is resident.
For the Ethernet address on a logical switch port of type
- router, when that logical switch port’s addresses column
- is set to router and the connected logical router port
- specifies a reside-on-redirect-chassis and the logical
+ router, when that logical switch port’s addresses column
+ is set to router and the connected logical router port
+ specifies a reside-on-redirect-chassis and the logical
router to which the connected logical router port belongs
to has a distributed gateway LRP:
- · The flow for the connected logical router port’s
+ • The flow for the connected logical router port’s
Ethernet address is only programmed on the gateway
chassis.
- For each forwarding group configured on the logical
- switch datapath, a priority-50 flow that matches on
+ For each forwarding group configured on the logical
+ switch datapath, a priority-50 flow that matches on
eth.dst == VIP
- with an action of fwd_group(childports=args ), where
- args contains comma separated logical switch child ports
- to load balance to. If liveness is enabled, then action
+ with an action of fwd_group(childports=args ), where
+ args contains comma separated logical switch child ports
+ to load balance to. If liveness is enabled, then action
also includes liveness=true.
- · One priority-0 fallback flow that matches all packets
- with the action outport = get_fdb(eth.dst); next;. The
- action get_fdb gets the port for the eth.dst in the MAC
- learning table of the logical switch datapath. If there
- is no entry for eth.dst in the MAC learning table, then
+ • One priority-0 fallback flow that matches all packets
+ with the action outport = get_fdb(eth.dst); next;. The
+ action get_fdb gets the port for the eth.dst in the MAC
+ learning table of the logical switch datapath. If there
+ is no entry for eth.dst in the MAC learning table, then
it stores none in the outport.
- Ingress Table 26 Destination unknown
+ Ingress Table 28 Destination unknown
- This table handles the packets whose destination was not found or and
- looked up in the MAC learning table of the logical switch datapath. It
+ This table handles the packets whose destination was not found or and
+ looked up in the MAC learning table of the logical switch datapath. It
contains the following flows.
- · Priority 50 flow with the match outport == P is added for
+ • Priority 50 flow with the match outport == P is added for
each disabled Logical Switch Port P. This flow has action
drop;.
- · If the logical switch has logical ports with ’unknown’
+ • If the logical switch has logical ports with ’unknown’
addresses set, then the below logical flow is added
- · Priority 50 flow with the match outport == "none"
- then outputs them to the MC_UNKNOWN multicast
+ • Priority 50 flow with the match outport == "none"
+ then outputs them to the MC_UNKNOWN multicast
group, which ovn-northd populates with all enabled
logical ports that accept unknown destination
packets. As a small optimization, if no logical
@@ -1586,12 +1710,12 @@ LOGICAL FLOW TABLE STRUCTURE
If the logical switch has no logical ports with ’unknown’
address set, then the below logical flow is added
- · Priority 50 flow with the match outport == none
+ • Priority 50 flow with the match outport == none
and drops the packets.
- · One priority-0 fallback flow that outputs the packet to
- the egress stage with the outport learnt from get_fdb
- action.
+ • One priority-0 fallback flow that outputs the packet to
+ the egress stage with the outport learnt from get_fdb ac‐
+ tion.
Egress Table 0: to-lport Pre-ACLs
@@ -1611,95 +1735,121 @@ LOGICAL FLOW TABLE STRUCTURE
Egress Table 1: Pre-LB
This table is similar to ingress table Pre-LB. It contains a priority-0
- flow that simply moves traffic to the next table. Moreover it contains
- two priority-110 flows to move multicast, IPv6 Neighbor Discovery and
- MLD traffic to the next table. If any load balancing rules exist for
- the datapath, a priority-100 flow is added with a match of ip and
- action of reg0[2] = 1; next; to act as a hint for table Pre-stateful to
- send IP packets to the connection tracker for packet de-fragmentation
- and possibly DNAT the destination VIP to one of the selected backend
+ flow that simply moves traffic to the next table. Moreover it contains
+ two priority-110 flows to move multicast, IPv6 Neighbor Discovery and
+ MLD traffic to the next table. If any load balancing rules exist for
+ the datapath, a priority-100 flow is added with a match of ip and ac‐
+ tion of reg0[2] = 1; next; to act as a hint for table Pre-stateful to
+ send IP packets to the connection tracker for packet de-fragmentation
+ and possibly DNAT the destination VIP to one of the selected backend
for already committed load balanced traffic.
This table also has a priority-110 flow with the match eth.src == E for
all logical switch datapaths to move traffic to the next table. Where E
- is the service monitor mac defined in the options:svc_monitor_mac col‐
+ is the service monitor mac defined in the options:svc_monitor_mac col‐
umn of NB_Global table.
+ This table also has a priority-110 flow with the match outport == I for
+ all logical switch datapaths to move traffic to the next table, and, if
+ there are no stateful_acl, clear the ct_state. Where I is the peer of a
+ logical router port. This flow is added to skip the connection tracking
+ of packets which will be entering logical router datapath from logical
+ switch datapath for routing.
+
Egress Table 2: Pre-stateful
- This is similar to ingress table Pre-stateful. This table adds the
- below 3 logical flows.
+ This is similar to ingress table Pre-stateful. This table adds the be‐
+ low 3 logical flows.
- · A Priority-120 flow that send the packets to connection
- tracker using ct_lb_mark; as the action so that the
- already established traffic gets unDNATted from the back‐
- end IP to the load balancer VIP based on a hint provided
- by the previous tables with a match for reg0[2] == 1. If
- the packet was not DNATted earlier, then ct_lb_mark func‐
- tions like ct_next.
+ • A Priority-120 flow that send the packets to connection
+ tracker using ct_lb_mark; as the action so that the al‐
+ ready established traffic gets unDNATted from the backend
+ IP to the load balancer VIP based on a hint provided by
+ the previous tables with a match for reg0[2] == 1. If the
+ packet was not DNATted earlier, then ct_lb_mark functions
+ like ct_next.
- · A priority-100 flow sends the packets to connection
- tracker based on a hint provided by the previous tables
- (with a match for reg0[0] == 1) by using the ct_next;
- action.
+ • A priority-100 flow sends the packets to connection
+ tracker based on a hint provided by the previous tables
+ (with a match for reg0[0] == 1) by using the ct_next; ac‐
+ tion.
- · A priority-0 flow that matches all packets to advance to
+ • A priority-0 flow that matches all packets to advance to
the next table.
Egress Table 3: from-lport ACL hints
This is similar to ingress table ACL hints.
- Egress Table 4: to-lport ACLs
+ Egress Table 4: to-lport ACL evaluation
+
+ This is similar to ingress table ACL eval except for to-lport ACLs. As
+ a reminder, these flows use the following register bits to indicate
+ their verdicts. Allow-type ACLs set reg8[16], drop ACLs set reg8[17],
+ and reject ACLs set reg8[18].
+
+ Also like with ingress ACLs, egress ACLs can have a configured tier. If
+ a tier is configured, then the current tier counter is evaluated
+ against the ACL’s configured tier in addition to the ACL’s match. The
+ current tier counter is stored in reg8[30..31].
- This is similar to ingress table ACLs except for to-lport ACLs.
+ Similar to ingress table, a priority-65532 flow is added to allow IPv6
+ Neighbor solicitation, Neighbor discover, Router solicitation, Router
+ advertisement and MLD packets regardless of other ACLs defined.
In addition, the following flows are added.
- · A priority 34000 logical flow is added for each logical
+ • A priority 34000 logical flow is added for each logical
port which has DHCPv4 options defined to allow the DHCPv4
- reply packet and which has DHCPv6 options defined to
- allow the DHCPv6 reply packet from the Ingress Table 18:
- DHCP responses.
+ reply packet and which has DHCPv6 options defined to al‐
+ low the DHCPv6 reply packet from the Ingress Table 18:
+ DHCP responses. This is indicated by setting the allow
+ bit.
- · A priority 34000 logical flow is added for each logical
- switch datapath configured with DNS records with the
+ • A priority 34000 logical flow is added for each logical
+ switch datapath configured with DNS records with the
match udp.dst = 53 to allow the DNS reply packet from the
- Ingress Table 20: DNS responses.
+ Ingress Table 20: DNS responses. This is indicated by
+ setting the allow bit.
- · A priority 34000 logical flow is added for each logical
- switch datapath with the match eth.src = E to allow the
- service monitor request packet generated by ovn-con‐
+ • A priority 34000 logical flow is added for each logical
+ switch datapath with the match eth.src = E to allow the
+ service monitor request packet generated by ovn-con‐
troller with the action next, where E is the service mon‐
itor mac defined in the options:svc_monitor_mac column of
- NB_Global table.
+ NB_Global table. This is indicated by setting the allow
+ bit.
+
+ Egress Table 5: to-lport ACL action
- Egress Table 5: to-lport QoS Marking
+ This is similar to ingress table ACL action.
+
+ Egress Table 6: to-lport QoS Marking
This is similar to ingress table QoS marking except they apply to
to-lport QoS rules.
- Egress Table 6: to-lport QoS Meter
+ Egress Table 7: to-lport QoS Meter
This is similar to ingress table QoS meter except they apply to
to-lport QoS rules.
- Egress Table 7: Stateful
+ Egress Table 8: Stateful
This is similar to ingress table Stateful except that there are no
rules added for load balancing new connections.
- Egress Table 8: Egress Port Security - check
+ Egress Table 9: Egress Port Security - check
- This is similar to the port security logic in table Ingress Port Secu‐
+ This is similar to the port security logic in table Ingress Port Secu‐
rity check except that action check_out_port_sec is used to check the
port security rules. This table adds the below logical flows.
- · A priority 100 flow which matches on the multicast traf‐
+ • A priority 100 flow which matches on the multicast traf‐
fic and applies the action REGBIT_PORT_SEC_DROP" = 0;
next;" to skip the out port security checks.
- · A priority 0 logical flow is added which matches on all
+ • A priority 0 logical flow is added which matches on all
the packets and applies the action REGBIT_PORT_SEC_DROP"
= check_out_port_sec(); next;". The action
check_out_port_sec applies the port security rules based
@@ -1707,16 +1857,23 @@ LOGICAL FLOW TABLE STRUCTURE
Logical_Switch_Port table before delivering the packet to
the outport.
- Egress Table 9: Egress Port Security - Apply
+ Egress Table 10: Egress Port Security - Apply
- This is similar to the ingress port security logic in ingress table A
+ This is similar to the ingress port security logic in ingress table A
Ingress Port Security - Apply. This table drops the packets if the port
- security check failed in the previous stage i.e the register bit REG‐
+ security check failed in the previous stage i.e the register bit REG‐
BIT_PORT_SEC_DROP is set to 1.
The following flows are added.
- · For each localnet port configured with egress qos in the
+ • For each port configured with egress qos in the op‐
+ tions:qdisc_queue_id column of Logical_Switch_Port, run‐
+ ning a localnet port on the same logical switch, a prior‐
+ ity 110 flow is added which matches on the localnet out‐
+ port and on the port inport and applies the action
+ set_queue(id); output;".
+
+ • For each localnet port configured with egress qos in the
options:qdisc_queue_id column of Logical_Switch_Port, a
priority 100 flow is added which matches on the localnet
outport and applies the action set_queue(id); output;".
@@ -1724,10 +1881,10 @@ LOGICAL FLOW TABLE STRUCTURE
Please remember to mark the corresponding physical inter‐
face with ovn-egress-iface set to true in external_ids.
- · A priority-50 flow that drops the packet if the register
+ • A priority-50 flow that drops the packet if the register
bit REGBIT_PORT_SEC_DROP is set to 1.
- · A priority-0 flow that outputs the packet to the outport.
+ • A priority-0 flow that outputs the packet to the outport.
Logical Router Datapaths
Logical router datapaths will only exist for Logical_Router rows in the
@@ -1738,49 +1895,59 @@ LOGICAL FLOW TABLE STRUCTURE
This table drops packets that the router shouldn’t see at all based on
their Ethernet headers. It contains the following flows:
- · Priority-100 flows to drop packets with VLAN tags or mul‐
+ • Priority-100 flows to drop packets with VLAN tags or mul‐
ticast Ethernet source addresses.
- · For each enabled router port P with Ethernet address E, a
+ • For each enabled router port P with Ethernet address E, a
priority-50 flow that matches inport == P && (eth.mcast
|| eth.dst == E), stores the router port ethernet address
- and advances to next table, with action xreg0[0..47]=E;
+ and advances to next table, with action xreg0[0..47]=E;
next;.
- For the gateway port on a distributed logical router
- (where one of the logical router ports specifies a gate‐
- way chassis), the above flow matching eth.dst == E is
+ For the gateway port on a distributed logical router
+ (where one of the logical router ports specifies a gate‐
+ way chassis), the above flow matching eth.dst == E is
only programmed on the gateway port instance on the gate‐
way chassis. If LRP’s logical switch has attached LSP of
vtep type, the is_chassis_resident() part is not added to
- lflow to allow traffic originated from logical switch to
+ lflow to allow traffic originated from logical switch to
reach LR services (LBs, NAT).
- For a distributed logical router or for gateway router
+ For each gateway port GW on a distributed logical router
+ a priority-120 flow that matches ’recirculated’ icmp{4,6}
+ error ’packet too big’ and eth.dst == D && !is_chas‐
+ sis_resident( cr-GW) where D is the gateway port mac ad‐
+ dress and cr-GW is the chassis resident port of GW, swap
+ inport and outport and stores GW as inport.
+
+ This table adds a priority-110 flow that matches ’recir‐
+ culated’ icmp{4,6} error ’packet too big’ to drop the
+ packet.
+
+ For a distributed logical router or for gateway router
where the port is configured with options:gateway_mtu the
action of the above flow is modified adding
- check_pkt_larger in order to mark the packet setting REG‐
- BIT_PKT_LARGER if the size is greater than the MTU. If
- the port is also configured with options:gate‐
- way_mtu_bypass then another flow is added, with prior‐
- ity-55, to bypass the check_pkt_larger flow. This is use‐
- ful for traffic that normally doesn’t need to be frag‐
- mented and for which check_pkt_larger, which might not be
- offloadable, is not really needed. One such example is
- TCP traffic.
-
- · For each dnat_and_snat NAT rule on a distributed router
- that specifies an external Ethernet address E, a prior‐
- ity-50 flow that matches inport == GW && eth.dst == E,
- where GW is the logical router distributed gateway port
- corresponding to the NAT rule (specified or inferred),
+ check_pkt_larger in order to mark the packet setting REG‐
+ BIT_PKT_LARGER if the size is greater than the MTU. If
+ the port is also configured with options:gateway_mtu_by‐
+ pass then another flow is added, with priority-55, to by‐
+ pass the check_pkt_larger flow. This is useful for traf‐
+ fic that normally doesn’t need to be fragmented and for
+ which check_pkt_larger, which might not be offloadable,
+ is not really needed. One such example is TCP traffic.
+
+ • For each dnat_and_snat NAT rule on a distributed router
+ that specifies an external Ethernet address E, a prior‐
+ ity-50 flow that matches inport == GW && eth.dst == E,
+ where GW is the logical router distributed gateway port
+ corresponding to the NAT rule (specified or inferred),
with action xreg0[0..47]=E; next;.
This flow is only programmed on the gateway port instance
on the chassis where the logical_port specified in the
NAT rule resides.
- · A priority-0 logical flow that matches all packets not
+ • A priority-0 logical flow that matches all packets not
already handled (match 1) and drops them (action drop;).
Other packets are implicitly dropped.
@@ -1791,10 +1958,10 @@ LOGICAL FLOW TABLE STRUCTURE
MAC_Binding records to determine if OVN needs to learn the mac bind‐
ings. Following flows are added:
- · For each router port P that owns IP address A, which
- belongs to subnet S with prefix length L, if the option
- always_learn_from_arp_request is true for this router, a
- priority-100 flow is added which matches inport == P &&
+ • For each router port P that owns IP address A, which be‐
+ longs to subnet S with prefix length L, if the option al‐
+ ways_learn_from_arp_request is true for this router, a
+ priority-100 flow is added which matches inport == P &&
arp.spa == S/L && arp.op == 1 (ARP request) with the fol‐
lowing actions:
@@ -1806,8 +1973,8 @@ LOGICAL FLOW TABLE STRUCTURE
following two flows are added.
A priority-110 flow is added which matches inport == P &&
- arp.spa == S/L && arp.tpa == A && arp.op == 1 (ARP
- request) with the following actions:
+ arp.spa == S/L && arp.tpa == A && arp.op == 1 (ARP re‐
+ quest) with the following actions:
reg9[2] = lookup_arp(inport, arp.spa, arp.sha);
reg9[3] = 1;
@@ -1827,9 +1994,9 @@ LOGICAL FLOW TABLE STRUCTURE
router port, additional match is_chassis_resident(cr-P)
is added for all these flows.
- · A priority-100 flow which matches on ARP reply packets
- and applies the actions if the option
- always_learn_from_arp_request is true:
+ • A priority-100 flow which matches on ARP reply packets
+ and applies the actions if the option al‐
+ ways_learn_from_arp_request is true:
reg9[2] = lookup_arp(inport, arp.spa, arp.sha);
next;
@@ -1843,8 +2010,8 @@ LOGICAL FLOW TABLE STRUCTURE
next;
- · A priority-100 flow which matches on IPv6 Neighbor Dis‐
- covery advertisement packet and applies the actions if
+ • A priority-100 flow which matches on IPv6 Neighbor Dis‐
+ covery advertisement packet and applies the actions if
the option always_learn_from_arp_request is true:
reg9[2] = lookup_nd(inport, nd.target, nd.tll);
@@ -1859,7 +2026,7 @@ LOGICAL FLOW TABLE STRUCTURE
next;
- · A priority-100 flow which matches on IPv6 Neighbor Dis‐
+ • A priority-100 flow which matches on IPv6 Neighbor Dis‐
covery solicitation packet and applies the actions if the
option always_learn_from_arp_request is true:
@@ -1875,7 +2042,7 @@ LOGICAL FLOW TABLE STRUCTURE
next;
- · A priority-0 fallback flow that matches all packets and
+ • A priority-0 fallback flow that matches all packets and
applies the action reg9[2] = 1; next; advancing the
packet to the next table.
@@ -1886,49 +2053,49 @@ LOGICAL FLOW TABLE STRUCTURE
to the lookup results from the previous stage.
reg9[2] will be 1 if the lookup_arp/lookup_nd in the previous table was
- successful or skipped, meaning no need to learn mac binding from the
+ successful or skipped, meaning no need to learn mac binding from the
packet.
reg9[3] will be 1 if the lookup_arp_ip/lookup_nd_ip in the previous ta‐
ble was successful or skipped, meaning it is ok to learn mac binding
from the packet (if reg9[2] is 0).
- · A priority-100 flow with the match reg9[2] == 1 ||
+ • A priority-100 flow with the match reg9[2] == 1 ||
reg9[3] == 0 and advances the packet to the next table as
there is no need to learn the neighbor.
- · A priority-95 flow with the match nd_ns && (ip6.src == 0
+ • A priority-95 flow with the match nd_ns && (ip6.src == 0
|| nd.sll == 0) and applies the action next;
- · A priority-90 flow with the match arp and applies the
- action put_arp(inport, arp.spa, arp.sha); next;
+ • A priority-90 flow with the match arp and applies the ac‐
+ tion put_arp(inport, arp.spa, arp.sha); next;
- · A priority-95 flow with the match nd_na && nd.tll == 0
+ • A priority-95 flow with the match nd_na && nd.tll == 0
and applies the action put_nd(inport, nd.target,
eth.src); next;
- · A priority-90 flow with the match nd_na and applies the
+ • A priority-90 flow with the match nd_na and applies the
action put_nd(inport, nd.target, nd.tll); next;
- · A priority-90 flow with the match nd_ns and applies the
+ • A priority-90 flow with the match nd_ns and applies the
action put_nd(inport, ip6.src, nd.sll); next;
- · A priority-0 logical flow that matches all packets not
+ • A priority-0 logical flow that matches all packets not
already handled (match 1) and drops them (action drop;).
Ingress Table 3: IP Input
This table is the core of the logical router datapath functionality. It
- contains the following flows to implement very basic IP host function‐
+ contains the following flows to implement very basic IP host function‐
ality.
- · For each dnat_and_snat NAT rule on a distributed logical
- routers or gateway routers with gateway port configured
- with options:gateway_mtu to a valid integer value M, a
- priority-160 flow with the match inport == LRP && REG‐
- BIT_PKT_LARGER && REGBIT_EGRESS_LOOPBACK == 0, where LRP
- is the logical router port and applies the following
- action for ipv4 and ipv6 respectively:
+ • For each dnat_and_snat NAT rule on a distributed logical
+ routers or gateway routers with gateway port configured
+ with options:gateway_mtu to a valid integer value M, a
+ priority-160 flow with the match inport == LRP && REG‐
+ BIT_PKT_LARGER && REGBIT_EGRESS_LOOPBACK == 0, where LRP
+ is the logical router port and applies the following ac‐
+ tion for ipv4 and ipv6 respectively:
icmp4_error {
icmp4.type = 3; /* Destination Unreachable. */
@@ -1962,15 +2129,15 @@ LOGICAL FLOW TABLE STRUCTURE
};
- where E and I are the NAT rule external mac and IP
- respectively.
+ where E and I are the NAT rule external mac and IP re‐
+ spectively.
- · For distributed logical routers or gateway routers with
- gateway port configured with options:gateway_mtu to a
- valid integer value, a priority-150 flow with the match
- inport == LRP && REGBIT_PKT_LARGER && REGBIT_EGRESS_LOOP‐
- BACK == 0, where LRP is the logical router port and
- applies the following action for ipv4 and ipv6 respec‐
+ • For distributed logical routers or gateway routers with
+ gateway port configured with options:gateway_mtu to a
+ valid integer value, a priority-150 flow with the match
+ inport == LRP && REGBIT_PKT_LARGER && REGBIT_EGRESS_LOOP‐
+ BACK == 0, where LRP is the logical router port and ap‐
+ plies the following action for ipv4 and ipv6 respec‐
tively:
icmp4_error {
@@ -1999,70 +2166,70 @@ LOGICAL FLOW TABLE STRUCTURE
};
- · For each NAT entry of a distributed logical router (with
+ • For each NAT entry of a distributed logical router (with
distributed gateway router port(s)) of type snat, a pri‐
ority-120 flow with the match inport == P && ip4.src == A
- advances the packet to the next pipeline, where P is the
- distributed logical router port corresponding to the NAT
- entry (specified or inferred) and A is the external_ip
- set in the NAT entry. If A is an IPv6 address, then
+ advances the packet to the next pipeline, where P is the
+ distributed logical router port corresponding to the NAT
+ entry (specified or inferred) and A is the external_ip
+ set in the NAT entry. If A is an IPv6 address, then
ip6.src is used for the match.
- The above flow is required to handle the routing of the
+ The above flow is required to handle the routing of the
East/west NAT traffic.
- · For each BFD port the two following priority-110 flows
+ • For each BFD port the two following priority-110 flows
are added to manage BFD traffic:
- · if ip4.src or ip6.src is any IP address owned by
- the router port and udp.dst == 3784 , the packet
+ • if ip4.src or ip6.src is any IP address owned by
+ the router port and udp.dst == 3784 , the packet
is advanced to the next pipeline stage.
- · if ip4.dst or ip6.dst is any IP address owned by
- the router port and udp.dst == 3784 , the han‐
+ • if ip4.dst or ip6.dst is any IP address owned by
+ the router port and udp.dst == 3784 , the han‐
dle_bfd_msg action is executed.
- · L3 admission control: Priority-120 flows allows IGMP and
- MLD packets if the router has logical ports that have
- options :mcast_flood=’true’.
+ • L3 admission control: Priority-120 flows allows IGMP and
+ MLD packets if the router has logical ports that have op‐
+ tions :mcast_flood=’true’.
- · L3 admission control: A priority-100 flow drops packets
+ • L3 admission control: A priority-100 flow drops packets
that match any of the following:
- · ip4.src[28..31] == 0xe (multicast source)
+ • ip4.src[28..31] == 0xe (multicast source)
- · ip4.src == 255.255.255.255 (broadcast source)
+ • ip4.src == 255.255.255.255 (broadcast source)
- · ip4.src == 127.0.0.0/8 || ip4.dst == 127.0.0.0/8
+ • ip4.src == 127.0.0.0/8 || ip4.dst == 127.0.0.0/8
(localhost source or destination)
- · ip4.src == 0.0.0.0/8 || ip4.dst == 0.0.0.0/8 (zero
+ • ip4.src == 0.0.0.0/8 || ip4.dst == 0.0.0.0/8 (zero
network source or destination)
- · ip4.src or ip6.src is any IP address owned by the
- router, unless the packet was recirculated due to
- egress loopback as indicated by REG‐
+ • ip4.src or ip6.src is any IP address owned by the
+ router, unless the packet was recirculated due to
+ egress loopback as indicated by REG‐
BIT_EGRESS_LOOPBACK.
- · ip4.src is the broadcast address of any IP network
+ • ip4.src is the broadcast address of any IP network
known to the router.
- · A priority-100 flow parses DHCPv6 replies from IPv6 pre‐
+ • A priority-100 flow parses DHCPv6 replies from IPv6 pre‐
fix delegation routers (udp.src == 547 && udp.dst ==
546). The handle_dhcpv6_reply is used to send IPv6 prefix
delegation messages to the delegation router.
- · ICMP echo reply. These flows reply to ICMP echo requests
- received for the router’s IP address. Let A be an IP
- address owned by a router port. Then, for each A that is
- an IPv4 address, a priority-90 flow matches on ip4.dst ==
- A and icmp4.type == 8 && icmp4.code == 0 (ICMP echo
- request). For each A that is an IPv6 address, a prior‐
- ity-90 flow matches on ip6.dst == A and icmp6.type == 128
- && icmp6.code == 0 (ICMPv6 echo request). The port of the
- router that receives the echo request does not matter.
- Also, the ip.ttl of the echo request packet is not
- checked, so it complies with RFC 1812, section 4.2.2.9.
+ • ICMP echo reply. These flows reply to ICMP echo requests
+ received for the router’s IP address. Let A be an IP ad‐
+ dress owned by a router port. Then, for each A that is an
+ IPv4 address, a priority-90 flow matches on ip4.dst == A
+ and icmp4.type == 8 && icmp4.code == 0 (ICMP echo re‐
+ quest). For each A that is an IPv6 address, a priority-90
+ flow matches on ip6.dst == A and icmp6.type == 128 &&
+ icmp6.code == 0 (ICMPv6 echo request). The port of the
+ router that receives the echo request does not matter.
+ Also, the ip.ttl of the echo request packet is not
+ checked, so it complies with RFC 1812, section 4.2.2.9.
Flows for ICMPv4 echo requests use the following actions:
ip4.dst <-> ip4.src;
@@ -2081,11 +2248,11 @@ LOGICAL FLOW TABLE STRUCTURE
next;
- · Reply to ARP requests.
+ • Reply to ARP requests.
These flows reply to ARP requests for the router’s own IP
- address. The ARP requests are handled only if the
- requestor’s IP belongs to the same subnets of the logical
+ address. The ARP requests are handled only if the re‐
+ questor’s IP belongs to the same subnets of the logical
router port. For each router port P that owns IP address
A, which belongs to subnet S with prefix length L, and
Ethernet address E, a priority-90 flow matches inport ==
@@ -2112,22 +2279,23 @@ LOGICAL FLOW TABLE STRUCTURE
ferent chassis, and allows upstream MAC learning to point
to the gateway chassis.
- For the logical router port with the option reside-on-re‐
- direct-chassis set (which is centralized), the above
- flows are only programmed on the gateway port instance on
- the gateway chassis (if the logical router has a distrib‐
- uted gateway port). This behavior avoids generation of
- multiple ARP responses from different chassis, and allows
- upstream MAC learning to point to the gateway chassis.
-
- · Reply to IPv6 Neighbor Solicitations. These flows reply
- to Neighbor Solicitation requests for the router’s own
- IPv6 address and populate the logical router’s mac bind‐
+ For the logical router port with the option re‐
+ side-on-redirect-chassis set (which is centralized), the
+ above flows are only programmed on the gateway port in‐
+ stance on the gateway chassis (if the logical router has
+ a distributed gateway port). This behavior avoids genera‐
+ tion of multiple ARP responses from different chassis,
+ and allows upstream MAC learning to point to the gateway
+ chassis.
+
+ • Reply to IPv6 Neighbor Solicitations. These flows reply
+ to Neighbor Solicitation requests for the router’s own
+ IPv6 address and populate the logical router’s mac bind‐
ing table.
- For each router port P that owns IPv6 address A,
- solicited node address S, and Ethernet address E, a pri‐
- ority-90 flow matches inport == P && nd_ns && ip6.dst ==
+ For each router port P that owns IPv6 address A, so‐
+ licited node address S, and Ethernet address E, a prior‐
+ ity-90 flow matches inport == P && nd_ns && ip6.dst ==
{A, E} && nd.target == A with the following actions:
nd_na_router {
@@ -2141,24 +2309,24 @@ LOGICAL FLOW TABLE STRUCTURE
};
- For the gateway port on a distributed logical router
- (where one of the logical router ports specifies a gate‐
- way chassis), the above flows replying to IPv6 Neighbor
- Solicitations are only programmed on the gateway port
- instance on the gateway chassis. This behavior avoids
- generation of multiple replies from different chassis,
- and allows upstream MAC learning to point to the gateway
+ For the gateway port on a distributed logical router
+ (where one of the logical router ports specifies a gate‐
+ way chassis), the above flows replying to IPv6 Neighbor
+ Solicitations are only programmed on the gateway port in‐
+ stance on the gateway chassis. This behavior avoids gen‐
+ eration of multiple replies from different chassis, and
+ allows upstream MAC learning to point to the gateway
chassis.
- · These flows reply to ARP requests or IPv6 neighbor solic‐
- itation for the virtual IP addresses configured in the
+ • These flows reply to ARP requests or IPv6 neighbor solic‐
+ itation for the virtual IP addresses configured in the
router for NAT (both DNAT and SNAT) or load balancing.
- IPv4: For a configured NAT (both DNAT and SNAT) IP
- address or a load balancer IPv4 VIP A, for each router
- port P with Ethernet address E, a priority-90 flow
- matches arp.op == 1 && arp.tpa == A (ARP request) with
- the following actions:
+ IPv4: For a configured NAT (both DNAT and SNAT) IP ad‐
+ dress or a load balancer IPv4 VIP A, for each router port
+ P with Ethernet address E, a priority-90 flow matches
+ arp.op == 1 && arp.tpa == A (ARP request) with the fol‐
+ lowing actions:
eth.dst = eth.src;
eth.src = xreg0[0..47];
@@ -2180,13 +2348,13 @@ LOGICAL FLOW TABLE STRUCTURE
port, then the is_chassis_resident(P) is also added in
the match condition for the load balancer IPv4 VIP A.
- IPv6: For a configured NAT (both DNAT and SNAT) IP
- address or a load balancer IPv6 VIP A (if the VIP is
- reachable from any logical router port of the logical
- router), solicited node address S, for each router port P
- with Ethernet address E, a priority-90 flow matches
- inport == P && nd_ns && ip6.dst == {A, S} && nd.target ==
- A with the following actions:
+ IPv6: For a configured NAT (both DNAT and SNAT) IP ad‐
+ dress or a load balancer IPv6 VIP A (if the VIP is reach‐
+ able from any logical router port of the logical router),
+ solicited node address S, for each router port P with
+ Ethernet address E, a priority-90 flow matches inport ==
+ P && nd_ns && ip6.dst == {A, S} && nd.target == A with
+ the following actions:
eth.dst = eth.src;
nd_na {
@@ -2205,27 +2373,26 @@ LOGICAL FLOW TABLE STRUCTURE
the match condition for the load balancer IPv6 VIP A.
For the gateway port on a distributed logical router with
- NAT (where one of the logical router ports specifies a
+ NAT (where one of the logical router ports specifies a
gateway chassis):
- · If the corresponding NAT rule cannot be handled in
+ • If the corresponding NAT rule cannot be handled in
a distributed manner, then a priority-92 flow is
programmed on the gateway port instance on the
gateway chassis. A priority-91 drop flow is pro‐
grammed on the other chassis when ARP requests/NS
- packets are received on the gateway port. This
- behavior avoids generation of multiple ARP
- responses from different chassis, and allows
- upstream MAC learning to point to the gateway
- chassis.
-
- · If the corresponding NAT rule can be handled in a
- distributed manner, then this flow is only pro‐
- grammed on the gateway port instance where the
+ packets are received on the gateway port. This be‐
+ havior avoids generation of multiple ARP responses
+ from different chassis, and allows upstream MAC
+ learning to point to the gateway chassis.
+
+ • If the corresponding NAT rule can be handled in a
+ distributed manner, then this flow is only pro‐
+ grammed on the gateway port instance where the
logical_port specified in the NAT rule resides.
- Some of the actions are different for this case,
- using the external_mac specified in the NAT rule
+ Some of the actions are different for this case,
+ using the external_mac specified in the NAT rule
rather than the gateway port’s Ethernet address E:
eth.src = external_mac;
@@ -2238,43 +2405,43 @@ LOGICAL FLOW TABLE STRUCTURE
nd.tll = external_mac;
- This behavior avoids generation of multiple ARP
- responses from different chassis, and allows
- upstream MAC learning to point to the correct
- chassis.
+ This behavior avoids generation of multiple ARP
+ responses from different chassis, and allows up‐
+ stream MAC learning to point to the correct chas‐
+ sis.
- · Priority-85 flows which drops the ARP and IPv6 Neighbor
+ • Priority-85 flows which drops the ARP and IPv6 Neighbor
Discovery packets.
- · A priority-84 flow explicitly allows IPv6 multicast traf‐
+ • A priority-84 flow explicitly allows IPv6 multicast traf‐
fic that is supposed to reach the router pipeline (i.e.,
router solicitation and router advertisement packets).
- · A priority-83 flow explicitly drops IPv6 multicast traf‐
+ • A priority-83 flow explicitly drops IPv6 multicast traf‐
fic that is destined to reserved multicast groups.
- · A priority-82 flow allows IP multicast traffic if
- options:mcast_relay=’true’, otherwise drops it.
+ • A priority-82 flow allows IP multicast traffic if op‐
+ tions:mcast_relay=’true’, otherwise drops it.
- · UDP port unreachable. Priority-80 flows generate ICMP
- port unreachable messages in reply to UDP datagrams
- directed to the router’s IP address, except in the spe‐
- cial case of gateways, which accept traffic directed to a
+ • UDP port unreachable. Priority-80 flows generate ICMP
+ port unreachable messages in reply to UDP datagrams di‐
+ rected to the router’s IP address, except in the special
+ case of gateways, which accept traffic directed to a
router IP for load balancing and NAT purposes.
These flows should not match IP fragments with nonzero
offset.
- · TCP reset. Priority-80 flows generate TCP reset messages
- in reply to TCP datagrams directed to the router’s IP
- address, except in the special case of gateways, which
- accept traffic directed to a router IP for load balancing
+ • TCP reset. Priority-80 flows generate TCP reset messages
+ in reply to TCP datagrams directed to the router’s IP ad‐
+ dress, except in the special case of gateways, which ac‐
+ cept traffic directed to a router IP for load balancing
and NAT purposes.
- These flows should not match IP fragments with nonzero
+ These flows should not match IP fragments with nonzero
offset.
- · Protocol or address unreachable. Priority-70 flows gener‐
+ • Protocol or address unreachable. Priority-70 flows gener‐
ate ICMP protocol or address unreachable messages for
IPv4 and IPv6 respectively in reply to packets directed
to the router’s IP address on IP protocols other than
@@ -2285,33 +2452,38 @@ LOGICAL FLOW TABLE STRUCTURE
These flows should not match IP fragments with nonzero
offset.
- · Drop other IP traffic to this router. These flows drop
+ • Drop other IP traffic to this router. These flows drop
any other traffic destined to an IP address of this
router that is not already handled by one of the flows
above, which amounts to ICMP (other than echo requests)
and fragments with nonzero offsets. For each IP address A
- owned by the router, a priority-60 flow matches ip4.dst
- == A or ip6.dst == A and drops the traffic. An exception
- is made and the above flow is not added if the router
- port’s own IP address is used to SNAT packets passing
- through that router or if it is used as a load balancer
+ owned by the router, a priority-60 flow matches ip4.dst
+ == A or ip6.dst == A and drops the traffic. An exception
+ is made and the above flow is not added if the router
+ port’s own IP address is used to SNAT packets passing
+ through that router or if it is used as a load balancer
VIP.
The flows above handle all of the traffic that might be directed to the
router itself. The following flows (with lower priorities) handle the
remaining traffic, potentially for forwarding:
- · Drop Ethernet local broadcast. A priority-50 flow with
+ • Drop Ethernet local broadcast. A priority-50 flow with
match eth.bcast drops traffic destined to the local Eth‐
ernet broadcast address. By definition this traffic
should not be forwarded.
- · ICMP time exceeded. For each router port P, whose IP
- address is A, a priority-100 flow with match inport == P
- && ip.ttl == {0, 1} && !ip.later_frag matches packets
- whose TTL has expired, with the following actions to send
- an ICMP time exceeded reply for IPv4 and IPv6 respec‐
- tively:
+ • Avoid ICMP time exceeded for multicast. A priority-32
+ flow with match ip.ttl == {0, 1} && !ip.later_frag &&
+ (ip4.mcast || ip6.mcast) and actions drop; drops multi‐
+ cast packets whose TTL has expired without sending ICMP
+ time exceeded.
+
+ • ICMP time exceeded. For each router port P, whose IP ad‐
+ dress is A, a priority-31 flow with match inport == P &&
+ ip.ttl == {0, 1} && !ip.later_frag matches packets whose
+ TTL has expired, with the following actions to send an
+ ICMP time exceeded reply for IPv4 and IPv6 respectively:
icmp4 {
icmp4.type = 11; /* Time exceeded. */
@@ -2331,12 +2503,12 @@ LOGICAL FLOW TABLE STRUCTURE
};
- · TTL discard. A priority-30 flow with match ip.ttl == {0,
- 1} and actions drop; drops other packets whose TTL has
+ • TTL discard. A priority-30 flow with match ip.ttl == {0,
+ 1} and actions drop; drops other packets whose TTL has
expired, that should not receive a ICMP error reply (i.e.
fragments with nonzero offset).
- · Next table. A priority-0 flows match all packets that
+ • Next table. A priority-0 flows match all packets that
aren’t already handled and uses actions next; to feed
them to the next table.
@@ -2348,14 +2520,14 @@ LOGICAL FLOW TABLE STRUCTURE
Ingress Table 4: UNSNAT on Gateway and Distributed Routers
- · If the Router (Gateway or Distributed) is configured with
+ • If the Router (Gateway or Distributed) is configured with
load balancers, then below lflows are added:
For each IPv4 address A defined as load balancer VIP with
the protocol P (and the protocol port T if defined) is
also present as an external_ip in the NAT table, a prior‐
- ity-120 logical flow is added with the match ip4 &&
- ip4.dst == A && P with the action next; to advance the
+ ity-120 logical flow is added with the match ip4 &&
+ ip4.dst == A && P with the action next; to advance the
packet to the next table. If the load balancer has proto‐
col port B defined, then the match also has P.dst == B.
@@ -2363,7 +2535,7 @@ LOGICAL FLOW TABLE STRUCTURE
Ingress Table 4: UNSNAT on Gateway Routers
- · If the Gateway router has been configured to force SNAT
+ • If the Gateway router has been configured to force SNAT
any previously DNATted packets to B, a priority-110 flow
matches ip && ip4.dst == B or ip && ip6.dst == B with an
action ct_snat; .
@@ -2377,53 +2549,38 @@ LOGICAL FLOW TABLE STRUCTURE
If the Gateway router has been configured to force SNAT
any previously load-balanced packets to B, a priority-100
- flow matches ip && ip4.dst == B or ip && ip6.dst == B
+ flow matches ip && ip4.dst == B or ip && ip6.dst == B
with an action ct_snat; .
- For each NAT configuration in the OVN Northbound data‐
- base, that asks to change the source IP address of a
- packet from A to B, a priority-90 flow matches ip &&
- ip4.dst == B or ip && ip6.dst == B with an action
- ct_snat; . If the NAT rule is of type dnat_and_snat and
- has stateless=true in the options, then the action would
+ For each NAT configuration in the OVN Northbound data‐
+ base, that asks to change the source IP address of a
+ packet from A to B, a priority-90 flow matches ip &&
+ ip4.dst == B or ip && ip6.dst == B with an action
+ ct_snat; . If the NAT rule is of type dnat_and_snat and
+ has stateless=true in the options, then the action would
be next;.
A priority-0 logical flow with match 1 has actions next;.
Ingress Table 4: UNSNAT on Distributed Routers
- · For each configuration in the OVN Northbound database,
- that asks to change the source IP address of a packet
+ • For each configuration in the OVN Northbound database,
+ that asks to change the source IP address of a packet
from A to B, two priority-100 flows are added.
- If the NAT rule cannot be handled in a distributed man‐
- ner, then the below priority-100 flows are only pro‐
+ If the NAT rule cannot be handled in a distributed man‐
+ ner, then the below priority-100 flows are only pro‐
grammed on the gateway chassis.
- · The first flow matches ip && ip4.dst == B &&
- inport == GW && flags.loopback == 0 or ip &&
- ip6.dst == B && inport == GW && flags.loopback ==
- 0 where GW is the distributed gateway port corre‐
- sponding to the NAT rule (specified or inferred),
- with an action ct_snat_in_czone; to unSNAT in the
- common zone. If the NAT rule is of type
- dnat_and_snat and has stateless=true in the
- options, then the action would be next;.
-
- If the NAT entry is of type snat, then there is an
- additional match is_chassis_resident(cr-GW)
- where cr-GW is the chassis resident port of GW.
-
- · The second flow matches ip && ip4.dst == B &&
- inport == GW && flags.loopback == 1 &&
- flags.use_snat_zone == 1 or ip && ip6.dst == B &&
- inport == GW && flags.loopback == 0 &&
- flags.use_snat_zone == 1 where GW is the distrib‐
- uted gateway port corresponding to the NAT rule
- (specified or inferred), with an action ct_snat;
- to unSNAT in the snat zone. If the NAT rule is of
- type dnat_and_snat and has stateless=true in the
- options, then the action would be ip4/6.dst=(B).
+ • The first flow matches ip && ip4.dst == B && in‐
+ port == GW
+ or ip && ip6.dst == B && inport == GW where GW is
+ the distributed gateway port corresponding to the
+ NAT rule (specified or inferred), with an action
+ ct_snat; to unSNAT in the common zone. If the NAT
+ rule is of type dnat_and_snat and has state‐
+ less=true in the options, then the action would be
+ next;.
If the NAT entry is of type snat, then there is an
additional match is_chassis_resident(cr-GW)
@@ -2433,31 +2590,19 @@ LOGICAL FLOW TABLE STRUCTURE
Ingress Table 5: DEFRAG
- This is to send packets to connection tracker for tracking and defrag‐
- mentation. It contains a priority-0 flow that simply moves traffic to
+ This is to send packets to connection tracker for tracking and defrag‐
+ mentation. It contains a priority-0 flow that simply moves traffic to
the next table.
- If load balancing rules with only virtual IP addresses are configured
- in OVN_Northbound database for a Gateway router, a priority-100 flow is
- added for each configured virtual IP address VIP. For IPv4 VIPs the
- flow matches ip && ip4.dst == VIP. For IPv6 VIPs, the flow matches ip
- && ip6.dst == VIP. The flow applies the action reg0 = VIP; ct_dnat; (or
- xxreg0 for IPv6) to send IP packets to the connection tracker for
- packet de-fragmentation and to dnat the destination IP for the commit‐
- ted connection before sending it to the next table.
-
- If load balancing rules with virtual IP addresses and ports are config‐
- ured in OVN_Northbound database for a Gateway router, a priority-110
- flow is added for each configured virtual IP address VIP, protocol
- PROTO and port PORT. For IPv4 VIPs the flow matches ip && ip4.dst ==
- VIP && PROTO && PROTO.dst == PORT. For IPv6 VIPs, the flow matches ip
- && ip6.dst == VIP && PROTO && PROTO.dst == PORT. The flow applies the
- action reg0 = VIP; reg9[16..31] = PROTO.dst; ct_dnat; (or xxreg0 for
- IPv6) to send IP packets to the connection tracker for packet de-frag‐
- mentation and to dnat the destination IP for the committed connection
- before sending it to the next table.
-
- If ECMP routes with symmetric reply are configured in the OVN_North‐
+ For all load balancing rules that are configured in OVN_Northbound
+ database for a Gateway router, a priority-100 flow is added for each
+ configured virtual IP address VIP. For IPv4 VIPs the flow matches ip &&
+ ip4.dst == VIP. For IPv6 VIPs, the flow matches ip && ip6.dst == VIP.
+ The flow applies the action ct_dnat; to send IP packets to the connec‐
+ tion tracker for packet de-fragmentation and to dnat the destination IP
+ for the committed connection before sending it to the next table.
+
+ If ECMP routes with symmetric reply are configured in the OVN_North‐
bound database for a gateway router, a priority-100 flow is added for
each router port on which symmetric replies are configured. The match‐
ing logic for these ports essentially reverses the configured logic of
@@ -2466,7 +2611,7 @@ LOGICAL FLOW TABLE STRUCTURE
route’s prefix. The flow uses the actions chk_ecmp_nh_mac(); ct_next or
chk_ecmp_nh(); ct_next to send IP packets to table 76 or to table 77 in
order to check if source info are already stored by OVN and then to the
- connection tracker for packet de-fragmentation and tracking before
+ connection tracker for packet de-fragmentation and tracking before
sending it to the next table.
If load balancing rules are configured in OVN_Northbound database for a
@@ -2479,16 +2624,17 @@ LOGICAL FLOW TABLE STRUCTURE
Load balancing affinity check table contains the following logical
flows:
- · For all the configured load balancing rules for a logical
- router where a positive affinity timeout is specified in
- options column, that includes a L4 port PORT of protocol
- P and IPv4 or IPv6 address VIP, a priority-100 flow that
- matches on ct.new && ip && reg0 == VIP && P &&
- reg9[16..31] == PORT (xxreg0 == VIP
- in the IPv6 case) with an action of reg9[6] =
- chk_lb_aff(); next;
-
- · A priority 0 flow is added which matches on all packets
+ • For all the configured load balancing rules for a logical
+ router where a positive affinity timeout is specified in
+ options column, that includes a L4 port PORT of protocol
+ P and IPv4 or IPv6 address VIP, a priority-100 flow that
+ matches on ct.new && ip && ip.dst == VIP && P && P.dst ==
+ PORT (xxreg0 == VIP
+ in the IPv6 case) with an action of reg0 = ip.dst;
+ reg9[16..31] = P.dst; reg9[6] = chk_lb_aff(); next;
+ (xxreg0 == ip6.dst in the IPv6 case)
+
+ • A priority 0 flow is added which matches on all packets
and applies the action next;.
Ingress Table 7: DNAT
@@ -2504,136 +2650,103 @@ LOGICAL FLOW TABLE STRUCTURE
way chassis. These flows do not get programmed for load balancers with
IPv6 VIPs.
- · For all the configured load balancing rules for a logical
- router where a positive affinity timeout is specified in
- options column, that includes a L4 port PORT of protocol
- P and IPv4 or IPv6 address VIP, a priority-150 flow that
- matches on reg9[6] == 1 && ct.new && ip && reg0 == VIP &&
- P && reg9[16..31] == PORT (xxreg0 == VIP in the IPv6
- case) with an action of ct_lb_mark(args) , where args
- contains comma separated IP addresses (and optional port
- numbers) to load balance to. The address family of the IP
- addresses of args is the same as the address family of
- VIP.
-
- · If controller_event has been enabled for all the config‐
+ • For all the configured load balancing rules for a logical
+ router where a positive affinity timeout is specified in
+ options column, that includes a L4 port PORT of protocol
+ P and IPv4 or IPv6 address VIP, a priority-150 flow that
+ matches on reg9[6] == 1 && ct.new && ip && ip.dst == VIP
+ && P && P.dst == PORT with an action of ct_lb_mark(args)
+ , where args contains comma separated IP addresses (and
+ optional port numbers) to load balance to. The address
+ family of the IP addresses of args is the same as the ad‐
+ dress family of VIP.
+
+ • If controller_event has been enabled for all the config‐
ured load balancing rules for a Gateway router or Router
with gateway port in OVN_Northbound database that does
not have configured backends, a priority-130 flow is
added to trigger ovn-controller events whenever the chas‐
sis receives a packet for that particular VIP. If
- event-elb meter has been previously created, it will be
+ event-elb meter has been previously created, it will be
associated to the empty_lb logical flow
- · For all the configured load balancing rules for a Gateway
+ • For all the configured load balancing rules for a Gateway
router or Router with gateway port in OVN_Northbound
database that includes a L4 port PORT of protocol P and
IPv4 or IPv6 address VIP, a priority-120 flow that
- matches on ct.new && !ct.rel && ip && reg0 == VIP && P &&
- reg9[16..31] ==
- PORT (xxreg0 == VIP
- in the IPv6 case) with an action of ct_lb_mark(args),
- where args contains comma separated IPv4 or IPv6
- addresses (and optional port numbers) to load balance to.
- If the router is configured to force SNAT any load-bal‐
- anced packets, the above action will be replaced by
- flags.force_snat_for_lb = 1; ct_lb_mark(args);. If the
- load balancing rule is configured with skip_snat set to
- true, the above action will be replaced by
- flags.skip_snat_for_lb = 1; ct_lb_mark(args);. If health
- check is enabled, then args will only contain those end‐
- points whose service monitor status entry in OVN_South‐
- bound db is either online or empty.
-
- The previous table lr_in_defrag sets the register reg0
- (or xxreg0 for IPv6) and does ct_dnat. Hence for estab‐
- lished traffic, this table just advances the packet to
- the next stage.
-
- · For all the configured load balancing rules for a router
- in OVN_Northbound database that includes a L4 port PORT
- of protocol P and IPv4 or IPv6 address VIP, a prior‐
- ity-120 flow that matches on ct.est && !ct.rel && ip4 &&
- reg0 == VIP && P && reg9[16..31] ==
- PORT (ip6 and xxreg0 == VIP in the IPv6 case) with an
- action of next;. If the router is configured to force
- SNAT any load-balanced packets, the above action will be
- replaced by flags.force_snat_for_lb = 1; next;. If the
- load balancing rule is configured with skip_snat set to
- true, the above action will be replaced by
- flags.skip_snat_for_lb = 1; next;.
-
- The previous table lr_in_defrag sets the register reg0
- (or xxreg0 for IPv6) and does ct_dnat. Hence for estab‐
- lished traffic, this table just advances the packet to
- the next stage.
-
- · For all the configured load balancing rules for a router
- in OVN_Northbound database that includes just an IP
- address VIP to match on, a priority-110 flow that matches
- on ct.new && !ct.rel && ip4 && reg0 == VIP (ip6 and
- xxreg0 == VIP in the IPv6 case) with an action of
- ct_lb_mark(args), where args contains comma separated
- IPv4 or IPv6 addresses. If the router is configured to
- force SNAT any load-balanced packets, the above action
- will be replaced by flags.force_snat_for_lb = 1;
- ct_lb_mark(args);. If the load balancing rule is config‐
- ured with skip_snat set to true, the above action will be
- replaced by flags.skip_snat_for_lb = 1;
- ct_lb_mark(args);.
-
- The previous table lr_in_defrag sets the register reg0
- (or xxreg0 for IPv6) and does ct_dnat. Hence for estab‐
- lished traffic, this table just advances the packet to
- the next stage.
-
- · For all the configured load balancing rules for a router
- in OVN_Northbound database that includes just an IP
- address VIP to match on, a priority-110 flow that matches
- on ct.est && !ct.rel && ip4 && reg0 == VIP (or ip6 and
- xxreg0 == VIP) with an action of next;. If the router is
+ matches on ct.new && !ct.rel && ip && ip.dst == VIP && P
+ && P.dst ==
+ PORT with an action of ct_lb_mark(args), where args con‐
+ tains comma separated IPv4 or IPv6 addresses (and op‐
+ tional port numbers) to load balance to. If the router is
configured to force SNAT any load-balanced packets, the
above action will be replaced by flags.force_snat_for_lb
- = 1; next;. If the load balancing rule is configured with
- skip_snat set to true, the above action will be replaced
- by flags.skip_snat_for_lb = 1; next;.
+ = 1; ct_lb_mark(args; force_snat);. If the load balancing
+ rule is configured with skip_snat set to true, the above
+ action will be replaced by flags.skip_snat_for_lb = 1;
+ ct_lb_mark(args; skip_snat);. If health check is enabled,
+ then args will only contain those endpoints whose service
+ monitor status entry in OVN_Southbound db is either on‐
+ line or empty.
+
+ • For all the configured load balancing rules for a router
+ in OVN_Northbound database that includes just an IP ad‐
+ dress VIP to match on, a priority-110 flow that matches
+ on ct.new && !ct.rel && ip4 && ip.dst == VIP with an ac‐
+ tion of ct_lb_mark(args), where args contains comma sepa‐
+ rated IPv4 or IPv6 addresses. If the router is configured
+ to force SNAT any load-balanced packets, the above action
+ will be replaced by flags.force_snat_for_lb = 1;
+ ct_lb_mark(args; force_snat);. If the load balancing rule
+ is configured with skip_snat set to true, the above ac‐
+ tion will be replaced by flags.skip_snat_for_lb = 1;
+ ct_lb_mark(args; skip_snat);.
The previous table lr_in_defrag sets the register reg0
(or xxreg0 for IPv6) and does ct_dnat. Hence for estab‐
lished traffic, this table just advances the packet to
the next stage.
- · If the load balancer is created with --reject option and
+ • If the load balancer is created with --reject option and
it has no active backends, a TCP reset segment (for tcp)
or an ICMP port unreachable packet (for all other kind of
- traffic) will be sent whenever an incoming packet is
- received for this load-balancer. Please note using
- --reject option will disable empty_lb SB controller event
- for this load balancer.
+ traffic) will be sent whenever an incoming packet is re‐
+ ceived for this load-balancer. Please note using --reject
+ option will disable empty_lb SB controller event for this
+ load balancer.
- · For the related traffic, a priority 50 flow that matches
- ct.rel && !ct.est && !ct.new with an action of ct_com‐
+ • For the related traffic, a priority 50 flow that matches
+ ct.rel && !ct.est && !ct.new with an action of ct_com‐
mit_nat;, if the router has load balancer assigned to it.
Along with two priority 70 flows that match skip_snat and
- force_snat flags.
+ force_snat flags, setting the flags.force_snat_for_lb = 1
+ or flags.skip_snat_for_lb = 1 accordingly.
+
+ • For the established traffic, a priority 50 flow that
+ matches ct.est && !ct.rel && !ct.new && ct_mark.natted
+ with an action of next;, if the router has load balancer
+ assigned to it. Along with two priority 70 flows that
+ match skip_snat and force_snat flags, setting the
+ flags.force_snat_for_lb = 1 or flags.skip_snat_for_lb = 1
+ accordingly.
Ingress Table 7: DNAT on Gateway Routers
- · For each configuration in the OVN Northbound database,
+ • For each configuration in the OVN Northbound database,
that asks to change the destination IP address of a
packet from A to B, a priority-100 flow matches ip &&
ip4.dst == A or ip && ip6.dst == A with an action
flags.loopback = 1; ct_dnat(B);. If the Gateway router is
- configured to force SNAT any DNATed packet, the above
- action will be replaced by flags.force_snat_for_dnat = 1;
+ configured to force SNAT any DNATed packet, the above ac‐
+ tion will be replaced by flags.force_snat_for_dnat = 1;
flags.loopback = 1; ct_dnat(B);. If the NAT rule is of
type dnat_and_snat and has stateless=true in the options,
then the action would be ip4/6.dst= (B).
- If the NAT rule has allowed_ext_ips configured, then
+ If the NAT rule has allowed_ext_ips configured, then
there is an additional match ip4.src == allowed_ext_ips .
- Similarly, for IPV6, match would be ip6.src ==
- allowed_ext_ips.
+ Similarly, for IPV6, match would be ip6.src == al‐
+ lowed_ext_ips.
If the NAT rule has exempted_ext_ips set, then there is
an additional flow configured at priority 101. The flow
@@ -2641,7 +2754,7 @@ LOGICAL FLOW TABLE STRUCTURE
is next; . This flow is used to bypass the ct_dnat action
for a packet originating from exempted_ext_ips.
- · A priority-0 logical flow with match 1 has actions next;.
+ • A priority-0 logical flow with match 1 has actions next;.
Ingress Table 7: DNAT on Distributed Routers
@@ -2650,24 +2763,24 @@ LOGICAL FLOW TABLE STRUCTURE
a real IP address. The unDNAT processing in the reverse direction is
handled in a separate table in the egress pipeline.
- · For each configuration in the OVN Northbound database,
+ • For each configuration in the OVN Northbound database,
that asks to change the destination IP address of a
packet from A to B, a priority-100 flow matches ip &&
ip4.dst == B && inport == GW, where GW is the logical
router gateway port corresponding to the NAT rule (speci‐
- fied or inferred), with an action ct_dnat(B);. The match
- will include ip6.dst == B in the IPv6 case. If the NAT
- rule is of type dnat_and_snat and has stateless=true in
+ fied or inferred), with an action ct_dnat(B);. The match
+ will include ip6.dst == B in the IPv6 case. If the NAT
+ rule is of type dnat_and_snat and has stateless=true in
the options, then the action would be ip4/6.dst=(B).
- If the NAT rule cannot be handled in a distributed man‐
- ner, then the priority-100 flow above is only programmed
+ If the NAT rule cannot be handled in a distributed man‐
+ ner, then the priority-100 flow above is only programmed
on the gateway chassis.
- If the NAT rule has allowed_ext_ips configured, then
+ If the NAT rule has allowed_ext_ips configured, then
there is an additional match ip4.src == allowed_ext_ips .
- Similarly, for IPV6, match would be ip6.src ==
- allowed_ext_ips.
+ Similarly, for IPV6, match would be ip6.src == al‐
+ lowed_ext_ips.
If the NAT rule has exempted_ext_ips set, then there is
an additional flow configured at priority 101. The flow
@@ -2682,43 +2795,43 @@ LOGICAL FLOW TABLE STRUCTURE
Load balancing affinity learn table contains the following logical
flows:
- · For all the configured load balancing rules for a logical
- router where a positive affinity timeout T is specified
+ • For all the configured load balancing rules for a logical
+ router where a positive affinity timeout T is specified
in options
- column, that includes a L4 port PORT of protocol P and
- IPv4 or IPv6 address VIP, a priority-100 flow that
+ column, that includes a L4 port PORT of protocol P and
+ IPv4 or IPv6 address VIP, a priority-100 flow that
matches on reg9[6] == 0 && ct.new && ip && reg0 == VIP &&
P && reg9[16..31] == PORT (xxreg0 == VIP in the IPv6
case) with an action of commit_lb_aff(vip = VIP:PORT,
backend = backend ip: backend port, proto = P, timeout =
T);.
- · A priority 0 flow is added which matches on all packets
+ • A priority 0 flow is added which matches on all packets
and applies the action next;.
Ingress Table 9: ECMP symmetric reply processing
- · If ECMP routes with symmetric reply are configured in the
- OVN_Northbound database for a gateway router, a prior‐
- ity-100 flow is added for each router port on which sym‐
- metric replies are configured. The matching logic for
- these ports essentially reverses the configured logic of
- the ECMP route. So for instance, a route with a destina‐
- tion routing policy will instead match if the source IP
- address matches the static route’s prefix. The flow uses
- the action ct_commit { ct_label.ecmp_reply_eth =
- eth.src;" " ct_mark.ecmp_reply_port = K;}; com‐
+ • If ECMP routes with symmetric reply are configured in the
+ OVN_Northbound database for a gateway router, a prior‐
+ ity-100 flow is added for each router port on which sym‐
+ metric replies are configured. The matching logic for
+ these ports essentially reverses the configured logic of
+ the ECMP route. So for instance, a route with a destina‐
+ tion routing policy will instead match if the source IP
+ address matches the static route’s prefix. The flow uses
+ the action ct_commit { ct_label.ecmp_reply_eth =
+ eth.src;" " ct_mark.ecmp_reply_port = K;}; com‐
mit_ecmp_nh(); next;
- to commit the connection and storing eth.src and the
- ECMP reply port binding tunnel key K in the ct_label and
+ to commit the connection and storing eth.src and the
+ ECMP reply port binding tunnel key K in the ct_label and
the traffic pattern to table 76 or 77.
Ingress Table 10: IPv6 ND RA option processing
- · A priority-50 logical flow is added for each logical
- router port configured with IPv6 ND RA options which
- matches IPv6 ND Router Solicitation packet and applies
- the action put_nd_ra_opts and advances the packet to the
+ • A priority-50 logical flow is added for each logical
+ router port configured with IPv6 ND RA options which
+ matches IPv6 ND Router Solicitation packet and applies
+ the action put_nd_ra_opts and advances the packet to the
next table.
reg0[5] = put_nd_ra_opts(options);next;
@@ -2730,14 +2843,14 @@ LOGICAL FLOW TABLE STRUCTURE
packets, it just stores 0 into reg0[5]. Either way, it
continues to the next table.
- · A priority-0 logical flow with match 1 has actions next;.
+ • A priority-0 logical flow with match 1 has actions next;.
Ingress Table 11: IPv6 ND RA responder
This table implements IPv6 ND RA responder for the IPv6 ND RA replies
generated by the previous table.
- · A priority-50 logical flow is added for each logical
+ • A priority-50 logical flow is added for each logical
router port configured with IPv6 ND RA options which
matches IPv6 ND RA packets and reg0[5] == 1 and responds
back to the inport after applying these actions. If
@@ -2759,7 +2872,7 @@ LOGICAL FLOW TABLE STRUCTURE
(This terminates packet processing in ingress pipeline;
the packet does not go to the next ingress table.)
- · A priority-0 logical flow with match 1 has actions next;.
+ • A priority-0 logical flow with match 1 has actions next;.
Ingress Table 12: IP Routing Pre
@@ -2772,7 +2885,7 @@ LOGICAL FLOW TABLE STRUCTURE
This table contains the following logical flows:
- · Priority-100 flow with match inport == "LRP_NAME" value
+ • Priority-100 flow with match inport == "LRP_NAME" value
and action, which set route table identifier in reg7.
A priority-0 logical flow with match 1 has actions reg7 =
@@ -2780,9 +2893,9 @@ LOGICAL FLOW TABLE STRUCTURE
Ingress Table 13: IP Routing
- A packet that arrives at this table is an IP packet that should be
- routed to the address in ip4.dst or ip6.dst. This table implements IP
- routing, setting reg0 (or xxreg0 for IPv6) to the next-hop IP address
+ A packet that arrives at this table is an IP packet that should be
+ routed to the address in ip4.dst or ip6.dst. This table implements IP
+ routing, setting reg0 (or xxreg0 for IPv6) to the next-hop IP address
(leaving ip4.dst or ip6.dst, the packet’s final destination, unchanged)
and advances to the next table for ARP resolution. It also sets reg1
(or xxreg1) to the IP address owned by the selected router port
@@ -2796,12 +2909,12 @@ LOGICAL FLOW TABLE STRUCTURE
id and select a member id within the group based on 5-tuple hashing. It
stores group id in reg8[0..15] and member id in reg8[16..31]. This step
is skipped with a priority-10300 rule if the traffic going out the ECMP
- route is reply traffic, and the ECMP route was configured to use sym‐
- metric replies. Instead, the stored values in conntrack is used to
- choose the destination. The ct_label.ecmp_reply_eth tells the destina‐
- tion MAC address to which the packet should be sent. The
- ct_mark.ecmp_reply_port tells the logical router port on which the
- packet should be sent. These values saved to the conntrack fields when
+ route is reply traffic, and the ECMP route was configured to use sym‐
+ metric replies. Instead, the stored values in conntrack is used to
+ choose the destination. The ct_label.ecmp_reply_eth tells the destina‐
+ tion MAC address to which the packet should be sent. The
+ ct_mark.ecmp_reply_port tells the logical router port on which the
+ packet should be sent. These values saved to the conntrack fields when
the initial ingress traffic is received over the ECMP route and commit‐
ted to conntrack. If REGBIT_KNOWN_ECMP_NH is set, the priority-10300
flows in this stage set the outport, while the eth.dst is set by flows
@@ -2809,37 +2922,37 @@ LOGICAL FLOW TABLE STRUCTURE
This table contains the following logical flows:
- · Priority-10550 flow that drops IPv6 Router Solicita‐
+ • Priority-10550 flow that drops IPv6 Router Solicita‐
tion/Advertisement packets that were not processed in
previous tables.
- · Priority-10550 flows that drop IGMP and MLD packets with
+ • Priority-10550 flows that drop IGMP and MLD packets with
source MAC address owned by the router. These are used to
prevent looping statically forwarded IGMP and MLD packets
for which TTL is not decremented (it is always 1).
- · Priority-10500 flows that match IP multicast traffic des‐
+ • Priority-10500 flows that match IP multicast traffic des‐
tined to groups registered on any of the attached
- switches and sets outport to the associated multicast
- group that will eventually flood the traffic to all
- interested attached logical switches. The flows also
- decrement TTL.
+ switches and sets outport to the associated multicast
+ group that will eventually flood the traffic to all in‐
+ terested attached logical switches. The flows also decre‐
+ ment TTL.
- · Priority-10460 flows that match IGMP and MLD control
+ • Priority-10460 flows that match IGMP and MLD control
packets, set outport to the MC_STATIC multicast group,
which ovn-northd populates with the logical ports that
- have options :mcast_flood=’true’. If no router ports are
+ have options :mcast_flood=’true’. If no router ports are
configured to flood multicast traffic the packets are
dropped.
- · Priority-10450 flow that matches unregistered IP multi‐
+ • Priority-10450 flow that matches unregistered IP multi‐
cast traffic decrements TTL and sets outport to the
MC_STATIC multicast group, which ovn-northd populates
with the logical ports that have options
- :mcast_flood=’true’. If no router ports are configured to
+ :mcast_flood=’true’. If no router ports are configured to
flood multicast traffic the packets are dropped.
- · IPv4 routing table. For each route to IPv4 network N with
+ • IPv4 routing table. For each route to IPv4 network N with
netmask M, on router port P with IP address A and Ether‐
net address E, a logical flow with match ip4.dst == N/M,
whose priority is the number of 1-bits in M, has the fol‐
@@ -2862,8 +2975,8 @@ LOGICAL FLOW TABLE STRUCTURE
Instead, if the route is from a configured static route,
G is the next hop IP address. Else it is ip4.dst.
- · IPv6 routing table. For each route to IPv6 network N with
- netmask M, on router port P with IP address A and Ether‐
+ • IPv6 routing table. For each route to IPv6 network N with
+ netmask M, on router port P with IP address A and Ether‐
net address E, a logical flow with match in CIDR notation
ip6.dst == N/M, whose priority is the integer value of M,
has the following actions:
@@ -2895,19 +3008,19 @@ LOGICAL FLOW TABLE STRUCTURE
0.
For each connected route (route to the LRP’s subnet CIDR)
- the logical flow match portion has no reg7 == id && pre‐
+ the logical flow match portion has no reg7 == id && pre‐
fix to have route to LRP’s subnets in all routing tables.
- · For ECMP routes, they are grouped by policy and prefix.
- An unique id (non-zero) is assigned to each group, and
- each member is also assigned an unique id (non-zero)
+ • For ECMP routes, they are grouped by policy and prefix.
+ An unique id (non-zero) is assigned to each group, and
+ each member is also assigned an unique id (non-zero)
within each group.
- For each IPv4/IPv6 ECMP group with group id GID and mem‐
- ber ids MID1, MID2, ..., a logical flow with match in
- CIDR notation ip4.dst == N/M, or ip6.dst == N/M, whose
- priority is the integer value of M, has the following
- actions:
+ For each IPv4/IPv6 ECMP group with group id GID and mem‐
+ ber ids MID1, MID2, ..., a logical flow with match in
+ CIDR notation ip4.dst == N/M, or ip6.dst == N/M, whose
+ priority is the integer value of M, has the following ac‐
+ tions:
ip.ttl--;
flags.loopback = 1;
@@ -2915,7 +3028,7 @@ LOGICAL FLOW TABLE STRUCTURE
select(reg8[16..31], MID1, MID2, ...);
- · A priority-0 logical flow that matches all packets not
+ • A priority-0 logical flow that matches all packets not
already handled (match 1) and drops them (action drop;).
Ingress Table 14: IP_ROUTING_ECMP
@@ -2936,11 +3049,11 @@ LOGICAL FLOW TABLE STRUCTURE
This table contains the following logical flows:
- · A priority-150 flow that matches reg8[0..15] == 0 with
+ • A priority-150 flow that matches reg8[0..15] == 0 with
action next; directly bypasses packets of non-ECMP
routes.
- · For each member with ID MID in each ECMP group with ID
+ • For each member with ID MID in each ECMP group with ID
GID, a priority-100 flow with match reg8[0..15] == GID &&
reg8[16..31] == MID has following actions:
@@ -2950,20 +3063,20 @@ LOGICAL FLOW TABLE STRUCTURE
outport = P;
- · A priority-0 logical flow that matches all packets not
+ • A priority-0 logical flow that matches all packets not
already handled (match 1) and drops them (action drop;).
Ingress Table 15: Router policies
This table adds flows for the logical router policies configured on the
- logical router. Please see the OVN_Northbound database Logi‐
+ logical router. Please see the OVN_Northbound database Logi‐
cal_Router_Policy table documentation in ovn-nb for supported actions.
- · For each router policy configured on the logical router,
+ • For each router policy configured on the logical router,
a logical flow is added with specified priority, match
and actions.
- · If the policy action is reroute with 2 or more nexthops
+ • If the policy action is reroute with 2 or more nexthops
defined, then the logical flow is added with the follow‐
ing actions:
@@ -2974,12 +3087,12 @@ LOGICAL FLOW TABLE STRUCTURE
where GID is the ECMP group id generated by ovn-northd
for this policy and n is the number of nexthops. select
action selects one of the nexthop member id, stores it in
- the register reg8[16..31] and advances the packet to the
+ the register reg8[16..31] and advances the packet to the
next stage.
- · If the policy action is reroute with just one nexhop,
- then the logical flow is added with the following
- actions:
+ • If the policy action is reroute with just one nexhop,
+ then the logical flow is added with the following ac‐
+ tions:
[xx]reg0 = H;
eth.src = E;
@@ -2989,30 +3102,30 @@ LOGICAL FLOW TABLE STRUCTURE
next;
- where H is the nexthop defined in the router policy, E
- is the ethernet address of the logical router port from
- which the nexthop is reachable and P is the logical
+ where H is the nexthop defined in the router policy, E
+ is the ethernet address of the logical router port from
+ which the nexthop is reachable and P is the logical
router port from which the nexthop is reachable.
- · If a router policy has the option pkt_mark=m set and if
- the action is not drop, then the action also includes
+ • If a router policy has the option pkt_mark=m set and if
+ the action is not drop, then the action also includes
pkt.mark = m to mark the packet with the marker m.
Ingress Table 16: ECMP handling for router policies
- This table handles the ECMP for the router policies configured with
+ This table handles the ECMP for the router policies configured with
multiple nexthops.
- · A priority-150 flow is added to advance the packet to the
+ • A priority-150 flow is added to advance the packet to the
next stage if the ECMP group id register reg8[0..15] is
0.
- · For each ECMP reroute router policy with multiple nex‐
+ • For each ECMP reroute router policy with multiple nex‐
thops, a priority-100 flow is added for each nexthop H
with the match reg8[0..15] == GID && reg8[16..31] == M
where GID is the router policy group id generated by
ovn-northd and M is the member id of the nexthop H gener‐
- ated by ovn-northd. The following actions are added to
+ ated by ovn-northd. The following actions are added to
the flow:
[xx]reg0 = H;
@@ -3022,151 +3135,144 @@ LOGICAL FLOW TABLE STRUCTURE
"next;"
- where H is the nexthop defined in the router policy, E
- is the ethernet address of the logical router port from
- which the nexthop is reachable and P is the logical
+ where H is the nexthop defined in the router policy, E
+ is the ethernet address of the logical router port from
+ which the nexthop is reachable and P is the logical
router port from which the nexthop is reachable.
- · A priority-0 logical flow that matches all packets not
+ • A priority-0 logical flow that matches all packets not
already handled (match 1) and drops them (action drop;).
Ingress Table 17: ARP/ND Resolution
- Any packet that reaches this table is an IP packet whose next-hop IPv4
- address is in reg0 or IPv6 address is in xxreg0. (ip4.dst or ip6.dst
- contains the final destination.) This table resolves the IP address in
+ Any packet that reaches this table is an IP packet whose next-hop IPv4
+ address is in reg0 or IPv6 address is in xxreg0. (ip4.dst or ip6.dst
+ contains the final destination.) This table resolves the IP address in
reg0 (or xxreg0) into an output port in outport and an Ethernet address
in eth.dst, using the following flows:
- · A priority-500 flow that matches IP multicast traffic
+ • A priority-500 flow that matches IP multicast traffic
that was allowed in the routing pipeline. For this kind
of traffic the outport was already set so the flow just
advances to the next table.
- · Priority-200 flows that match ECMP reply traffic for the
+ • Priority-200 flows that match ECMP reply traffic for the
routes configured to use symmetric replies, with actions
push(xxreg1); xxreg1 = ct_label; eth.dst =
xxreg1[32..79]; pop(xxreg1); next;. xxreg1 is used here
to avoid masked access to ct_label, to make the flow HW-
offloading friendly.
- · Static MAC bindings. MAC bindings can be known statically
- based on data in the OVN_Northbound database. For router
- ports connected to logical switches, MAC bindings can be
- known statically from the addresses column in the Logi‐
- cal_Switch_Port table. For router ports connected to
- other logical routers, MAC bindings can be known stati‐
- cally from the mac and networks column in the Logi‐
- cal_Router_Port table. (Note: the flow is NOT installed
- for the IP addresses that belong to a neighbor logical
- router port if the current router has the
- options:dynamic_neigh_routers set to true)
+ • Static MAC bindings. MAC bindings can be known statically
+ based on data in the OVN_Northbound database. For router
+ ports connected to logical switches, MAC bindings can be
+ known statically from the addresses column in the Logi‐
+ cal_Switch_Port table. (Note: the flow is not installed
+ for IPs of logical switch ports of type virtual, and dy‐
+ namic MAC binding is used for those IPs instead, so that
+ virtual parent failover does not depend on ovn-northd, to
+ achieve better failover performance.) For router ports
+ connected to other logical routers, MAC bindings can be
+ known statically from the mac and networks column in the
+ Logical_Router_Port table. (Note: the flow is NOT in‐
+ stalled for the IP addresses that belong to a neighbor
+ logical router port if the current router has the op‐
+ tions:dynamic_neigh_routers set to true)
For each IPv4 address A whose host is known to have Eth‐
ernet address E on router port P, a priority-100 flow
with match outport === P && reg0 == A has actions eth.dst
= E; next;.
- For each virtual ip A configured on a logical port of
- type virtual and its virtual parent set in its corre‐
- sponding Port_Binding record and the virtual parent with
- the Ethernet address E and the virtual ip is reachable
- via the router port P, a priority-100 flow with match
- outport === P && xxreg0/reg0 == A has actions eth.dst =
- E; next;.
-
- For each virtual ip A configured on a logical port of
- type virtual and its virtual parent not set in its corre‐
- sponding Port_Binding record and the virtual ip A is
- reachable via the router port P, a priority-100 flow with
- match outport === P && xxreg0/reg0 == A has actions
- eth.dst = 00:00:00:00:00:00; next;. This flow is added so
- that the ARP is always resolved for the virtual ip A by
- generating ARP request and not consulting the MAC_Binding
- table as it can have incorrect value for the virtual ip
- A.
-
For each IPv6 address A whose host is known to have Eth‐
ernet address E on router port P, a priority-100 flow
with match outport === P && xxreg0 == A has actions
eth.dst = E; next;.
For each logical router port with an IPv4 address A and a
- mac address of E that is reachable via a different logi‐
+ mac address of E that is reachable via a different logi‐
cal router port P, a priority-100 flow with match outport
=== P && reg0 == A has actions eth.dst = E; next;.
For each logical router port with an IPv6 address A and a
- mac address of E that is reachable via a different logi‐
+ mac address of E that is reachable via a different logi‐
cal router port P, a priority-100 flow with match outport
=== P && xxreg0 == A has actions eth.dst = E; next;.
- · Static MAC bindings from NAT entries. MAC bindings can
+ • Static MAC bindings from NAT entries. MAC bindings can
also be known for the entries in the NAT table. Below
flows are programmed for distributed logical routers i.e
with a distributed router port.
For each row in the NAT table with IPv4 address A in the
- external_ip column of NAT table, a priority-100 flow with
- the match outport === P && reg0 == A has actions eth.dst
- = E; next;, where P is the distributed logical router
- port, E is the Ethernet address if set in the exter‐
- nal_mac column of NAT table for of type dnat_and_snat,
- otherwise the Ethernet address of the distributed logical
- router port. Note that if the external_ip is not within a
- subnet on the owning logical router, then OVN will only
- create ARP resolution flows if the options:add_route is
- set to true. Otherwise, no ARP resolution flows will be
- added.
+ external_ip column of NAT table, below two flows are pro‐
+ grammed:
+
+ A priority-100 flow with the match outport == P && reg0
+ == A has actions eth.dst = E; next;, where P is the dis‐
+ tributed logical router port, E is the Ethernet address
+ if set in the external_mac column of NAT table for of
+ type dnat_and_snat, otherwise the Ethernet address of the
+ distributed logical router port. Note that if the exter‐
+ nal_ip is not within a subnet on the owning logical
+ router, then OVN will only create ARP resolution flows if
+ the options:add_route is set to true. Otherwise, no ARP
+ resolution flows will be added.
+
+ Corresponding to the above flow, a priority-150 flow with
+ the match inport == P && outport == P && ip4.dst == A has
+ actions drop; to exclude packets that have gone through
+ DNAT/unSNAT stage but failed to convert the destination,
+ to avoid loop.
For IPv6 NAT entries, same flows are added, but using the
- register xxreg0 for the match.
+ register xxreg0 and field ip6 for the match.
- · If the router datapath runs a port with redirect-type set
- to bridged, for each distributed NAT rule with IP A in
- the logical_ip column and logical port P in the logi‐
+ • If the router datapath runs a port with redirect-type set
+ to bridged, for each distributed NAT rule with IP A in
+ the logical_ip column and logical port P in the logi‐
cal_port column of NAT table, a priority-90 flow with the
- match outport == Q && ip.src === A && is_chassis_resi‐
+ match outport == Q && ip.src === A && is_chassis_resi‐
dent(P), where Q is the distributed logical router port
and action get_arp(outport, reg0); next; for IPv4 and
get_nd(outport, xxreg0); next; for IPv6.
- · Traffic with IP destination an address owned by the
+ • Traffic with IP destination an address owned by the
router should be dropped. Such traffic is normally
dropped in ingress table IP Input except for IPs that are
- also shared with SNAT rules. However, if there was no
- unSNAT operation that happened successfully until this
+ also shared with SNAT rules. However, if there was no un‐
+ SNAT operation that happened successfully until this
point in the pipeline and the destination IP of the
packet is still a router owned IP, the packets can be
safely dropped.
A priority-2 logical flow with match ip4.dst = {..}
- matches on traffic destined to router owned IPv4
- addresses which are also SNAT IPs. This flow has action
+ matches on traffic destined to router owned IPv4 ad‐
+ dresses which are also SNAT IPs. This flow has action
drop;.
A priority-2 logical flow with match ip6.dst = {..}
- matches on traffic destined to router owned IPv6
- addresses which are also SNAT IPs. This flow has action
+ matches on traffic destined to router owned IPv6 ad‐
+ dresses which are also SNAT IPs. This flow has action
drop;.
A priority-0 logical that flow matches all packets not
already handled (match 1) and drops them (action drop;).
- · Dynamic MAC bindings. These flows resolve MAC-to-IP bind‐
- ings that have become known dynamically through ARP or
- neighbor discovery. (The ingress table ARP Request will
- issue an ARP or neighbor solicitation request for cases
+ • Dynamic MAC bindings. These flows resolve MAC-to-IP bind‐
+ ings that have become known dynamically through ARP or
+ neighbor discovery. (The ingress table ARP Request will
+ issue an ARP or neighbor solicitation request for cases
where the binding is not yet known.)
- A priority-0 logical flow with match ip4 has actions
+ A priority-0 logical flow with match ip4 has actions
get_arp(outport, reg0); next;.
- A priority-0 logical flow with match ip6 has actions
+ A priority-0 logical flow with match ip6 has actions
get_nd(outport, xxreg0); next;.
- · For a distributed gateway LRP with redirect-type set to
- bridged, a priority-50 flow will match outport ==
+ • For a distributed gateway LRP with redirect-type set to
+ bridged, a priority-50 flow will match outport ==
"ROUTER_PORT" and !is_chassis_resident ("cr-ROUTER_PORT")
has actions eth.dst = E; next;, where E is the ethernet
address of the logical router port.
@@ -3186,21 +3292,21 @@ LOGICAL FLOW TABLE STRUCTURE
L, it stores 1 in the register bit REGBIT_PKT_LARGER. The value of L is
taken from options:gateway_mtu column of Logical_Router_Port row.
- If the port is also configured with options:gateway_mtu_bypass then
- another flow is added, with priority-55, to bypass the check_pkt_larger
+ If the port is also configured with options:gateway_mtu_bypass then an‐
+ other flow is added, with priority-55, to bypass the check_pkt_larger
flow.
- This table adds one priority-0 fallback flow that matches all packets
+ This table adds one priority-0 fallback flow that matches all packets
and advances to the next table.
Ingress Table 19: Handle larger packets
- For distributed logical routers or gateway routers with gateway port
- configured with options:gateway_mtu to a valid integer value, this ta‐
- ble adds the following priority-150 logical flow for each logical
- router port with the match inport == LRP && outport == GW_PORT && REG‐
- BIT_PKT_LARGER && !REGBIT_EGRESS_LOOPBACK, where LRP is the logical
- router port and GW_PORT is the gateway port and applies the following
+ For distributed logical routers or gateway routers with gateway port
+ configured with options:gateway_mtu to a valid integer value, this ta‐
+ ble adds the following priority-150 logical flow for each logical
+ router port with the match inport == LRP && outport == GW_PORT && REG‐
+ BIT_PKT_LARGER && !REGBIT_EGRESS_LOOPBACK, where LRP is the logical
+ router port and GW_PORT is the gateway port and applies the following
action for ipv4 and ipv6 respectively:
icmp4 {
@@ -3229,34 +3335,46 @@ LOGICAL FLOW TABLE STRUCTURE
};
- · Where M is the (fragment MTU - 58) whose value is taken
- from options:gateway_mtu column of Logical_Router_Port
+ • Where M is the (fragment MTU - 58) whose value is taken
+ from options:gateway_mtu column of Logical_Router_Port
row.
- · E is the Ethernet address of the logical router port.
+ • E is the Ethernet address of the logical router port.
- · I is the IPv4/IPv6 address of the logical router port.
+ • I is the IPv4/IPv6 address of the logical router port.
- This table adds one priority-0 fallback flow that matches all packets
+ This table adds one priority-0 fallback flow that matches all packets
and advances to the next table.
Ingress Table 20: Gateway Redirect
For distributed logical routers where one or more of the logical router
ports specifies a gateway chassis, this table redirects certain packets
- to the distributed gateway port instances on the gateway chassises.
+ to the distributed gateway port instances on the gateway chassises.
This table has the following flows:
- · For each NAT rule in the OVN Northbound database that can
- be handled in a distributed manner, a priority-100 logi‐
- cal flow with match ip4.src == B && outport == GW &&
+ • For all the configured load balancing rules that include
+ an IPv4 address VIP, and a list of IPv4 backend addresses
+ B0, B1 .. Bn defined for the VIP a priority-200 flow is
+ added that matches ip4 && (ip4.src == B0 || ip4.src == B1
+ || ... || ip4.src == Bn) with an action outport = CR;
+ next; where CR is the chassisredirect port representing
+ the instance of the logical router distributed gateway
+ port on the gateway chassis. If the backend IPv4 address
+ Bx is also configured with L4 port PORT of protocol P,
+ then the match also includes P.src == PORT. Similar flows
+ are added for IPv6.
+
+ • For each NAT rule in the OVN Northbound database that can
+ be handled in a distributed manner, a priority-100 logi‐
+ cal flow with match ip4.src == B && outport == GW &&
is_chassis_resident(P), where GW is the distributed gate‐
way port specified in the NAT rule and P is the NAT logi‐
cal port. IP traffic matching the above rule will be man‐
aged locally setting reg1 to C and eth.src to D, where C
is NAT external ip and D is NAT external mac.
- · For each dnat_and_snat NAT rule with stateless=true and
+ • For each dnat_and_snat NAT rule with stateless=true and
allowed_ext_ips configured, a priority-75 flow is pro‐
grammed with match ip4.dst == B and action outport = CR;
next; where B is the NAT rule external IP and CR is the
@@ -3265,22 +3383,22 @@ LOGICAL FLOW TABLE STRUCTURE
chassis. Moreover a priority-70 flow is programmed with
same match and action drop;. For each dnat_and_snat NAT
rule with stateless=true and exempted_ext_ips configured,
- a priority-75 flow is programmed with match ip4.dst == B
- and action drop; where B is the NAT rule external IP. A
+ a priority-75 flow is programmed with match ip4.dst == B
+ and action drop; where B is the NAT rule external IP. A
similar flow is added for IPv6 traffic.
- · For each NAT rule in the OVN Northbound database that can
+ • For each NAT rule in the OVN Northbound database that can
be handled in a distributed manner, a priority-80 logical
- flow with drop action if the NAT logical port is a vir‐
+ flow with drop action if the NAT logical port is a vir‐
tual port not claimed by any chassis yet.
- · A priority-50 logical flow with match outport == GW has
- actions outport = CR; next;, where GW is the logical
- router distributed gateway port and CR is the chas‐
+ • A priority-50 logical flow with match outport == GW has
+ actions outport = CR; next;, where GW is the logical
+ router distributed gateway port and CR is the chas‐
sisredirect port representing the instance of the logical
router distributed gateway port on the gateway chassis.
- · A priority-0 logical flow with match 1 has actions next;.
+ • A priority-0 logical flow with match 1 has actions next;.
Ingress Table 21: ARP Request
@@ -3288,7 +3406,7 @@ LOGICAL FLOW TABLE STRUCTURE
this table outputs the packet. Otherwise, it composes and sends an ARP
or IPv6 Neighbor Solicitation request. It holds the following flows:
- · Unknown MAC address. A priority-100 flow for IPv4 packets
+ • Unknown MAC address. A priority-100 flow for IPv4 packets
with match eth.dst == 00:00:00:00:00:00 has the following
actions:
@@ -3304,8 +3422,8 @@ LOGICAL FLOW TABLE STRUCTURE
Unknown MAC address. For each IPv6 static route associ‐
ated with the router with the nexthop IP: G, a prior‐
ity-200 flow for IPv6 packets with match eth.dst ==
- 00:00:00:00:00:00 && xxreg0 == G with the following
- actions is added:
+ 00:00:00:00:00:00 && xxreg0 == G with the following ac‐
+ tions is added:
nd_ns {
eth.dst = E;
@@ -3316,7 +3434,7 @@ LOGICAL FLOW TABLE STRUCTURE
Where E is the multicast mac derived from the Gateway IP,
- I is the solicited-node multicast address corresponding
+ I is the solicited-node multicast address corresponding
to the target address G.
Unknown MAC address. A priority-100 flow for IPv6 packets
@@ -3329,15 +3447,15 @@ LOGICAL FLOW TABLE STRUCTURE
};
- (Ingress table IP Routing initialized reg1 with the IP
- address owned by outport and (xx)reg0 with the next-hop
+ (Ingress table IP Routing initialized reg1 with the IP
+ address owned by outport and (xx)reg0 with the next-hop
IP address)
- The IP packet that triggers the ARP/IPv6 NS request is
+ The IP packet that triggers the ARP/IPv6 NS request is
dropped.
- · Known MAC address. A priority-0 flow with match 1 has
- actions output;.
+ • Known MAC address. A priority-0 flow with match 1 has ac‐
+ tions output;.
Egress Table 0: Check DNAT local
@@ -3347,98 +3465,76 @@ LOGICAL FLOW TABLE STRUCTURE
distributed gateway ports and NAT entries. This check is done so that
SNAT and DNAT is done in different zones instead of a common zone.
- · For each NAT rule in the OVN Northbound database on a
- distributed router, a priority-50 logical flow with match
- ip4.dst == E && is_chassis_resident(P), where E is the
- external IP address specified in the NAT rule, GW is the
- logical router distributed gateway port. For
- dnat_and_snat NAT rule, P is the logical port specified
- in the NAT rule. If logical_port column of NAT table is
- NOT set, then P is the chassisredirect port of GW with
- the actions: REGBIT_DST_NAT_IP_LOCAL = 1; next;
-
- · A priority-0 logical flow with match 1 has actions REG‐
+ • A priority-0 logical flow with match 1 has actions REG‐
BIT_DST_NAT_IP_LOCAL = 0; next;.
- This table also installs a priority-50 logical flow for each logical
- router that has NATs configured on it. The flow has match ip &&
- ct_label.natted == 1 and action REGBIT_DST_NAT_IP_LOCAL = 1; next;.
- This is intended to ensure that traffic that was DNATted locally will
- use a separate conntrack zone for SNAT if SNAT is required later in the
- egress pipeline. Note that this flow checks the value of ct_label.nat‐
- ted, which is set in the ingress pipeline. This means that ovn-northd
- assumes that this value is carried over from the ingress pipeline to
- the egress pipeline and is not altered or cleared. If conntrack label
- values are ever changed to be cleared between the ingress and egress
- pipelines, then the match conditions of this flow will be updated
- accordingly.
-
Egress Table 1: UNDNAT
- This is for already established connections’ reverse traffic. i.e.,
- DNAT has already been done in ingress pipeline and now the packet has
- entered the egress pipeline as part of a reply. This traffic is unD‐
+ This is for already established connections’ reverse traffic. i.e.,
+ DNAT has already been done in ingress pipeline and now the packet has
+ entered the egress pipeline as part of a reply. This traffic is unD‐
NATed here.
- · A priority-0 logical flow with match 1 has actions next;.
+ • A priority-0 logical flow with match 1 has actions next;.
Egress Table 1: UNDNAT on Gateway Routers
- · For all IP packets, a priority-50 flow with an action
+ • For IPv6 Neighbor Discovery or Router Solicitation/Adver‐
+ tisement traffic, a priority-100 flow with action next;.
+
+ • For all IP packets, a priority-50 flow with an action
flags.loopback = 1; ct_dnat;.
Egress Table 1: UNDNAT on Distributed Routers
- · For all the configured load balancing rules for a router
- with gateway port in OVN_Northbound database that
- includes an IPv4 address VIP, for every backend IPv4
- address B defined for the VIP a priority-120 flow is pro‐
- grammed on gateway chassis that matches ip && ip4.src ==
- B && outport == GW, where GW is the logical router gate‐
- way port with an action ct_dnat_in_czone;. If the backend
- IPv4 address B is also configured with L4 port PORT of
- protocol P, then the match also includes P.src == PORT.
- These flows are not added for load balancers with IPv6
- VIPs.
-
- If the router is configured to force SNAT any load-bal‐
- anced packets, above action will be replaced by
+ • For all the configured load balancing rules for a router
+ with gateway port in OVN_Northbound database that in‐
+ cludes an IPv4 address VIP, for every backend IPv4 ad‐
+ dress B defined for the VIP a priority-120 flow is pro‐
+ grammed on gateway chassis that matches ip && ip4.src ==
+ B && outport == GW, where GW is the logical router gate‐
+ way port with an action ct_dnat;. If the backend IPv4 ad‐
+ dress B is also configured with L4 port PORT of protocol
+ P, then the match also includes P.src == PORT. These
+ flows are not added for load balancers with IPv6 VIPs.
+
+ If the router is configured to force SNAT any load-bal‐
+ anced packets, above action will be replaced by
flags.force_snat_for_lb = 1; ct_dnat;.
- · For each configuration in the OVN Northbound database
- that asks to change the destination IP address of a
- packet from an IP address of A to B, a priority-100 flow
- matches ip && ip4.src == B && outport == GW, where GW is
- the logical router gateway port, with an action
- ct_dnat_in_czone;. If the NAT rule is of type
- dnat_and_snat and has stateless=true in the options, then
- the action would be next;.
+ • For each configuration in the OVN Northbound database
+ that asks to change the destination IP address of a
+ packet from an IP address of A to B, a priority-100 flow
+ matches ip && ip4.src == B && outport == GW, where GW is
+ the logical router gateway port, with an action ct_dnat;.
+ If the NAT rule is of type dnat_and_snat and has state‐
+ less=true in the options, then the action would be next;.
- If the NAT rule cannot be handled in a distributed man‐
- ner, then the priority-100 flow above is only programmed
- on the gateway chassis with the action ct_dnat_in_czone.
+ If the NAT rule cannot be handled in a distributed man‐
+ ner, then the priority-100 flow above is only programmed
+ on the gateway chassis with the action ct_dnat.
- If the NAT rule can be handled in a distributed manner,
- then there is an additional action eth.src = EA;, where
+ If the NAT rule can be handled in a distributed manner,
+ then there is an additional action eth.src = EA;, where
EA is the ethernet address associated with the IP address
A in the NAT rule. This allows upstream MAC learning to
point to the correct chassis.
Egress Table 2: Post UNDNAT
- · A priority-50 logical flow is added that commits any
- untracked flows from the previous table lr_out_undnat for
+ • A priority-50 logical flow is added that commits any un‐
+ tracked flows from the previous table lr_out_undnat for
Gateway routers. This flow matches on ct.new && ip with
action ct_commit { } ; next; .
- · A priority-0 logical flow with match 1 has actions next;.
+ • A priority-0 logical flow with match 1 has actions next;.
Egress Table 3: SNAT
Packets that are configured to be SNATed get their source IP address
changed based on the configuration in the OVN Northbound database.
- · A priority-120 flow to advance the IPv6 Neighbor solici‐
+ • A priority-120 flow to advance the IPv6 Neighbor solici‐
tation packet to next table to skip SNAT. In the case
where ovn-controller injects an IPv6 Neighbor Solicita‐
tion packet (for nd_ns action) we don’t want the packet
@@ -3446,94 +3542,85 @@ LOGICAL FLOW TABLE STRUCTURE
Egress Table 3: SNAT on Gateway Routers
- · If the Gateway router in the OVN Northbound database has
+ • If the Gateway router in the OVN Northbound database has
been configured to force SNAT a packet (that has been
previously DNATted) to B, a priority-100 flow matches
flags.force_snat_for_dnat == 1 && ip with an action
ct_snat(B);.
- · If a load balancer configured to skip snat has been
- applied to the Gateway router pipeline, a priority-120
- flow matches flags.skip_snat_for_lb == 1 && ip with an
- action next;.
-
- · If the Gateway router in the OVN Northbound database has
- been configured to force SNAT a packet (that has been
- previously load-balanced) using router IP (i.e
- options:lb_force_snat_ip=router_ip), then for each logi‐
- cal router port P attached to the Gateway router, a pri‐
- ority-110 flow matches flags.force_snat_for_lb == 1 &&
- outport == P
+ • If a load balancer configured to skip snat has been ap‐
+ plied to the Gateway router pipeline, a priority-120 flow
+ matches flags.skip_snat_for_lb == 1 && ip with an action
+ next;.
+
+ • If the Gateway router in the OVN Northbound database has
+ been configured to force SNAT a packet (that has been
+ previously load-balanced) using router IP (i.e op‐
+ tions:lb_force_snat_ip=router_ip), then for each logical
+ router port P attached to the Gateway router, a prior‐
+ ity-110 flow matches flags.force_snat_for_lb == 1 && out‐
+ port == P
with an action ct_snat(R); where R is the IP configured
on the router port. If R is an IPv4 address then the
match will also include ip4 and if it is an IPv6 address,
then the match will also include ip6.
- If the logical router port P is configured with multiple
+ If the logical router port P is configured with multiple
IPv4 and multiple IPv6 addresses, only the first IPv4 and
first IPv6 address is considered.
- · If the Gateway router in the OVN Northbound database has
+ • If the Gateway router in the OVN Northbound database has
been configured to force SNAT a packet (that has been
previously load-balanced) to B, a priority-100 flow
matches flags.force_snat_for_lb == 1 && ip with an action
ct_snat(B);.
- · For each configuration in the OVN Northbound database,
- that asks to change the source IP address of a packet
- from an IP address of A or to change the source IP
- address of a packet that belongs to network A to B, a
- flow matches ip && ip4.src == A && (!ct.trk || !ct.rpl)
- with an action ct_snat(B);. The priority of the flow is
- calculated based on the mask of A, with matches having
- larger masks getting higher priorities. If the NAT rule
- is of type dnat_and_snat and has stateless=true in the
- options, then the action would be ip4/6.src= (B).
-
- · If the NAT rule has allowed_ext_ips configured, then
+ • For each configuration in the OVN Northbound database,
+ that asks to change the source IP address of a packet
+ from an IP address of A or to change the source IP ad‐
+ dress of a packet that belongs to network A to B, a flow
+ matches ip && ip4.src == A && (!ct.trk || !ct.rpl) with
+ an action ct_snat(B);. The priority of the flow is calcu‐
+ lated based on the mask of A, with matches having larger
+ masks getting higher priorities. If the NAT rule is of
+ type dnat_and_snat and has stateless=true in the options,
+ then the action would be ip4/6.src= (B).
+
+ • If the NAT rule has allowed_ext_ips configured, then
there is an additional match ip4.dst == allowed_ext_ips .
- Similarly, for IPV6, match would be ip6.dst ==
- allowed_ext_ips.
+ Similarly, for IPV6, match would be ip6.dst == al‐
+ lowed_ext_ips.
- · If the NAT rule has exempted_ext_ips set, then there is
+ • If the NAT rule has exempted_ext_ips set, then there is
an additional flow configured at the priority + 1 of cor‐
- responding NAT rule. The flow matches if destination ip
+ responding NAT rule. The flow matches if destination ip
is an exempted_ext_ip and the action is next; . This flow
is used to bypass the ct_snat action for a packet which
is destinted to exempted_ext_ips.
- · A priority-0 logical flow with match 1 has actions next;.
+ • A priority-0 logical flow with match 1 has actions next;.
Egress Table 3: SNAT on Distributed Routers
- · For each configuration in the OVN Northbound database,
+ • For each configuration in the OVN Northbound database,
that asks to change the source IP address of a packet
- from an IP address of A or to change the source IP
- address of a packet that belongs to network A to B, two
+ from an IP address of A or to change the source IP ad‐
+ dress of a packet that belongs to network A to B, two
flows are added. The priority P of these flows are calcu‐
- lated based on the mask of A, with matches having larger
+ lated based on the mask of A, with matches having larger
masks getting higher priorities.
- If the NAT rule cannot be handled in a distributed man‐
- ner, then the below flows are only programmed on the
- gateway chassis increasing flow priority by 128 in order
+ If the NAT rule cannot be handled in a distributed man‐
+ ner, then the below flows are only programmed on the
+ gateway chassis increasing flow priority by 128 in order
to be run first.
- · The first flow is added with the calculated prior‐
+ • The first flow is added with the calculated prior‐
ity P and match ip && ip4.src == A && outport ==
GW, where GW is the logical router gateway port,
- with an action ct_snat_in_czone(B); to SNATed in
- the common zone. If the NAT rule is of type
- dnat_and_snat and has stateless=true in the
- options, then the action would be ip4/6.src=(B).
-
- · The second flow is added with the calculated pri‐
- ority P + 1 and match ip && ip4.src == A && out‐
- port == GW && REGBIT_DST_NAT_IP_LOCAL == 0, where
- GW is the logical router gateway port, with an
- action ct_snat(B); to SNAT in the snat zone. If
- the NAT rule is of type dnat_and_snat and has
- stateless=true in the options, then the action
+ with an action ct_snat(B); to SNATed in the common
+ zone. If the NAT rule is of type dnat_and_snat and
+ has stateless=true in the options, then the action
would be ip4/6.src=(B).
If the NAT rule can be handled in a distributed manner,
@@ -3544,19 +3631,26 @@ LOGICAL FLOW TABLE STRUCTURE
If the NAT rule has allowed_ext_ips configured, then
there is an additional match ip4.dst == allowed_ext_ips .
- Similarly, for IPV6, match would be ip6.dst ==
- allowed_ext_ips.
-
- If the NAT rule has exempted_ext_ips set, then there is
- an additional flow configured at the priority P + 2 of
- corresponding NAT rule. The flow matches if destination
- ip is an exempted_ext_ip and the action is next; . This
- flow is used to bypass the ct_snat action for a flow
+ Similarly, for IPV6, match would be ip6.dst == al‐
+ lowed_ext_ips.
+
+ If the NAT rule has exempted_ext_ips set, then there is
+ an additional flow configured at the priority P + 2 of
+ corresponding NAT rule. The flow matches if destination
+ ip is an exempted_ext_ip and the action is next; . This
+ flow is used to bypass the ct_snat action for a flow
which is destinted to exempted_ext_ips.
- · A priority-0 logical flow with match 1 has actions next;.
+ • A priority-0 logical flow with match 1 has actions next;.
+
+ Egress Table 4: Post SNAT
+
+ Packets reaching this table are processed according to the flows below:
- Egress Table 4: Egress Loopback
+ • A priority-0 logical flow that matches all packets not
+ already handled (match 1) and action next;.
+
+ Egress Table 5: Egress Loopback
For distributed logical routers where one of the logical router ports
specifies a gateway chassis.
@@ -3564,15 +3658,15 @@ LOGICAL FLOW TABLE STRUCTURE
While UNDNAT and SNAT processing have already occurred by this point,
this traffic needs to be forced through egress loopback on this dis‐
tributed gateway port instance, in order for UNSNAT and DNAT processing
- to be applied, and also for IP routing and ARP resolution after all of
+ to be applied, and also for IP routing and ARP resolution after all of
the NAT processing, so that the packet can be forwarded to the destina‐
tion.
This table has the following flows:
- · For each NAT rule in the OVN Northbound database on a
+ • For each NAT rule in the OVN Northbound database on a
distributed router, a priority-100 logical flow with
- match ip4.dst == E && outport == GW && is_chassis_resi‐
+ match ip4.dst == E && outport == GW && is_chassis_resi‐
dent(P), where E is the external IP address specified in
the NAT rule, GW is the distributed gateway port corre‐
sponding to the NAT rule (specified or inferred). For
@@ -3587,7 +3681,6 @@ LOGICAL FLOW TABLE STRUCTURE
outport = "";
flags = 0;
flags.loopback = 1;
- flags.use_snat_zone = REGBIT_DST_NAT_IP_LOCAL;
reg0 = 0;
reg1 = 0;
...
@@ -3599,45 +3692,43 @@ LOGICAL FLOW TABLE STRUCTURE
flags.loopback is set since in_port is unchanged and the
packet may return back to that port after NAT processing.
- REGBIT_EGRESS_LOOPBACK is set to indicate that egress
- loopback has occurred, in order to skip the source IP
- address check against the router address.
+ REGBIT_EGRESS_LOOPBACK is set to indicate that egress
+ loopback has occurred, in order to skip the source IP ad‐
+ dress check against the router address.
- · A priority-0 logical flow with match 1 has actions next;.
+ • A priority-0 logical flow with match 1 has actions next;.
- Egress Table 5: Delivery
+ Egress Table 6: Delivery
Packets that reach this table are ready for delivery. It contains:
- · Priority-110 logical flows that match IP multicast pack‐
+ • Priority-110 logical flows that match IP multicast pack‐
ets on each enabled logical router port and modify the
Ethernet source address of the packets to the Ethernet
address of the port and then execute action output;.
- · Priority-100 logical flows that match packets on each
- enabled logical router port, with action output;.
+ • Priority-100 logical flows that match packets on each en‐
+ abled logical router port, with action output;.
- · A priority-0 logical flow that matches all packets not
+ • A priority-0 logical flow that matches all packets not
already handled (match 1) and drops them (action drop;).
DROP SAMPLING
- As described in the previous section, there are several places where
- ovn-northd might decided to drop a packet by explicitly creating a Log‐
+ As described in the previous section, there are several places where
+ ovn-northd might decided to drop a packet by explicitly creating a Log‐
ical_Flow with the drop; action.
When debug drop-sampling has been cofigured in the OVN Northbound data‐
- base, the ovn-northd will replace all the drop; actions with a sam‐
- ple(priority=65535, collector_set=id, obs_domain=obs_id,
+ base, the ovn-northd will replace all the drop; actions with a sam‐
+ ple(priority=65535, collector_set=id, obs_domain=obs_id,
obs_point=@cookie) action, where:
- · id is the value the debug_drop_collector_set option con‐
+ • id is the value the debug_drop_collector_set option con‐
figured in the OVN Northbound.
- · obs_id has it’s 8 most significant bits equal to the
- value of the debug_drop_domain_id option in the OVN
- Northbound and it’s 24 least significant bits equal to
+ • obs_id has it’s 8 most significant bits equal to the
+ value of the debug_drop_domain_id option in the OVN
+ Northbound and it’s 24 least significant bits equal to
the datapath’s tunnel key.
-
-
-OVN 22.12.90 ovn-northd ovn-northd(8)
+OVN 24.03.90 ovn-northd ovn-northd(8)
diff --git a/src/static/support/dist-docs/ovn-sb.5 b/src/static/support/dist-docs/ovn-sb.5
index dda9230e..a19c1ea2 100644
--- a/src/static/support/dist-docs/ovn-sb.5
+++ b/src/static/support/dist-docs/ovn-sb.5
@@ -1,6 +1,6 @@
'\" p
.\" -*- nroff -*-
-.TH "ovn-sb" 5 " DB Schema 20.27.0" "Open vSwitch 22.12.90" "Open vSwitch Manual"
+.TH "ovn-sb" 5 " DB Schema 20.33.0" "Open vSwitch 24.03.90" "Open vSwitch Manual"
.fp 5 L CR \\" Make fixed-width font available as \\fL.
.de TQ
. br
@@ -188,6 +188,232 @@ IP to MAC bindings
.TQ 1in
\fBChassis_Template_Var\fR
Chassis_Template_Var configuration\[char46]
+.\" check if in troff mode (TTY)
+.if t \{
+.bp
+.SH "TABLE RELATIONSHIPS"
+.PP
+The following diagram shows the relationship among tables in the
+database. Each node represents a table. Tables that are part of the
+``root set'' are shown with double borders. Each edge leads from the
+table that contains it and points to the table that its value
+represents. Edges are labeled with their column names, followed by a
+constraint on the number of allowed values: \fB?\fR for zero or one,
+\fB*\fR for zero or more, \fB+\fR for one or more. Thick lines
+represent strong references; thin lines represent weak references.
+.RS -1in
+.ps -3
+.PS
+linethick = 1;
+linethick = 0.500000;
+box at 0.165487,0.106006 wid 0.179040 height 0.084805 "SB_Global"
+box at 0.165487,0.106006 wid 0.123485 height 0.029249
+linethick = 1.000000;
+box at 0.825085,0.169610 wid 0.184332 height 0.084805 "Connection"
+linethick = 1.000000;
+box at 0.825085,0.042403 wid 0.127208 height 0.084805 "SSL"
+linethick = 0.500000;
+box at 2.590962,0.857480 wid 0.134864 height 0.084805 "Chassis"
+box at 2.590962,0.857480 wid 0.079308 height 0.029249
+linethick = 1.000000;
+box at 2.912882,1.479372 wid 0.127208 height 0.084805 "Encap"
+linethick = 0.500000;
+box at 2.206965,0.612479 wid 0.242644 height 0.084805 "Chassis_Private"
+box at 2.206965,0.612479 wid 0.187089 height 0.029249
+linethick = 0.500000;
+box at 0.165487,2.812643 wid 0.198461 height 0.084805 "Address_Set"
+box at 0.165487,2.812643 wid 0.142905 height 0.029249
+linethick = 0.500000;
+box at 0.165487,2.939850 wid 0.189641 height 0.084805 "Port_Group"
+box at 0.165487,2.939850 wid 0.134085 height 0.029249
+linethick = 0.500000;
+box at 0.165487,2.459345 wid 0.219662 height 0.084805 "Logical_Flow"
+box at 0.165487,2.459345 wid 0.164106 height 0.029249
+linethick = 0.500000;
+box at 1.458171,2.101298 wid 0.270901 height 0.084805 "Datapath_Binding"
+box at 1.458171,2.101298 wid 0.215346 height 0.029249
+linethick = 1.000000;
+box at 0.825085,2.683061 wid 0.290338 height 0.084805 "Logical_DP_Group"
+linethick = 0.500000;
+box at 0.165487,1.759704 wid 0.256773 height 0.084805 "Multicast_Group"
+box at 0.165487,1.759704 wid 0.201217 height 0.029249
+linethick = 0.500000;
+box at 0.825085,1.281505 wid 0.210842 height 0.084805 "Port_Binding"
+box at 0.825085,1.281505 wid 0.155287 height 0.029249
+linethick = 0.500000;
+box at 1.458171,1.281505 wid 0.127208 height 0.084805 "Mirror"
+box at 1.458171,1.281505 wid 0.071652 height 0.029249
+linethick = 0.500000;
+box at 0.165487,3.067058 wid 0.127208 height 0.084805 "Meter"
+box at 0.165487,3.067058 wid 0.071652 height 0.029249
+linethick = 1.000000;
+box at 0.825085,3.067058 wid 0.198461 height 0.084805 "Meter_Band"
+linethick = 1.000000;
+box at 1.841795,0.984688 wid 0.263845 height 0.084805 "Gateway_Chassis"
+linethick = 0.500000;
+box at 1.458171,0.857480 wid 0.295647 height 0.084805 "HA_Chassis_Group"
+box at 1.458171,0.857480 wid 0.240092 height 0.029249
+linethick = 0.500000;
+box at 0.825085,2.292110 wid 0.228499 height 0.084805 "MAC_Binding"
+box at 0.825085,2.292110 wid 0.172943 height 0.029249
+linethick = 0.500000;
+box at 0.165487,3.194265 wid 0.239099 height 0.084805 "DHCP_Options"
+box at 0.165487,3.194265 wid 0.183544 height 0.029249
+linethick = 0.500000;
+box at 0.165487,3.321473 wid 0.270901 height 0.084805 "DHCPv6_Options"
+box at 0.165487,3.321473 wid 0.215346 height 0.029249
+linethick = 0.500000;
+box at 0.825085,2.164902 wid 0.127208 height 0.084805 "DNS"
+box at 0.825085,2.164902 wid 0.071652 height 0.029249
+linethick = 0.500000;
+box at 0.165487,3.448680 wid 0.198461 height 0.084805 "RBAC_Role"
+box at 0.165487,3.448680 wid 0.142905 height 0.029249
+linethick = 0.500000;
+box at 0.825085,3.448680 wid 0.283266 height 0.084805 "RBAC_Permission"
+box at 0.825085,3.448680 wid 0.227710 height 0.029249
+linethick = 1.000000;
+box at 2.206965,0.857480 wid 0.198461 height 0.084805 "HA_Chassis"
+linethick = 0.500000;
+box at 2.206965,0.485271 wid 0.258537 height 0.084805 "Controller_Event"
+box at 2.206965,0.485271 wid 0.202981 height 0.029249
+linethick = 0.500000;
+box at 0.825085,2.037695 wid 0.203769 height 0.084805 "IP_Multicast"
+box at 0.825085,2.037695 wid 0.148214 height 0.029249
+linethick = 0.500000;
+box at 0.165487,1.281505 wid 0.216134 height 0.084805 "IGMP_Group"
+box at 0.165487,1.281505 wid 0.160578 height 0.029249
+linethick = 0.500000;
+box at 0.165487,3.575888 wid 0.256773 height 0.084805 "Service_Monitor"
+box at 0.165487,3.575888 wid 0.201217 height 0.029249
+linethick = 0.500000;
+box at 0.165487,2.685435 wid 0.233807 height 0.084805 "Load_Balancer"
+box at 0.165487,2.685435 wid 0.178252 height 0.029249
+linethick = 0.500000;
+box at 0.165487,3.703095 wid 0.127208 height 0.084805 "BFD"
+box at 0.165487,3.703095 wid 0.071652 height 0.029249
+linethick = 0.500000;
+box at 0.165487,3.830303 wid 0.127208 height 0.084805 "FDB"
+box at 0.165487,3.830303 wid 0.071652 height 0.029249
+linethick = 0.500000;
+box at 0.825085,1.910487 wid 0.316848 height 0.084805 "Static_MAC_Binding"
+box at 0.825085,1.910487 wid 0.261293 height 0.029249
+linethick = 0.500000;
+box at 0.165487,3.957510 wid 0.330977 height 0.084805 "Chassis_Template_Var"
+box at 0.165487,3.957510 wid 0.275421 height 0.029249
+linethick = 1.000000;
+spline -> from 0.256162,0.114583 to 0.256162,0.114583 to 0.380808,0.126690 to 0.607085,0.148667 to 0.732664,0.160863
+"connections*" at 0.498823,0.167549
+linethick = 1.000000;
+spline -> from 0.255840,0.096427 to 0.255840,0.096427 to 0.292204,0.092532 to 0.334810,0.088055 to 0.373379,0.084216 to 0.511764,0.070442 to 0.674268,0.055668 to 0.760921,0.047901
+"ssl?" at 0.498823,0.101590
+linethick = 1.000000;
+spline -> from 2.615047,0.900222 to 2.615047,0.900222 to 2.673054,1.013827 to 2.830452,1.322381 to 2.888458,1.436325
+"encaps+" at 2.753788,1.279436
+linethick = 0.500000;
+spline -> from 2.329085,0.618127 to 2.329085,0.618127 to 2.379968,0.625573 to 2.437465,0.641177 to 2.481055,0.673148 to 2.529055,0.708122 to 2.559076,0.771386 to 2.574849,0.813908
+"chassis?" at 2.429833,0.690516
+linethick = 1.000000;
+spline -> from 0.276481,2.467486 to 0.276481,2.467486 to 0.483338,2.477832 to 0.942234,2.476815 to 1.267953,2.296859 to 1.335526,2.259544 to 1.393618,2.189665 to 1.426658,2.144379
+"logical_datapath?" at 0.825085,2.473762
+linethick = 1.000000;
+spline -> from 0.275905,2.482751 to 0.275905,2.482751 to 0.369682,2.504631 to 0.508236,2.540588 to 0.624267,2.586044 to 0.643992,2.593676 to 0.647690,2.598256 to 0.666669,2.607754 to 0.687667,2.618270 to 0.710361,2.629294 to 0.731765,2.639640
+"logical_dp_group?" at 0.498823,2.600969
+linethick = 0.500000;
+spline -> from 0.970559,2.689845 to 0.970559,2.689845 to 1.065032,2.686622 to 1.186032,2.667287 to 1.267953,2.598256 to 1.409442,2.479189 to 1.444534,2.241735 to 1.453117,2.144379
+"datapaths*" at 1.146937,2.699852
+linethick = 1.000000;
+spline -> from 0.295037,1.754276 to 0.295037,1.754276 to 0.457353,1.750375 to 0.745606,1.754107 to 0.983501,1.813301 to 1.118001,1.846714 to 1.150838,1.867067 to 1.267953,1.941017 to 1.321567,1.974939 to 1.375978,2.023278 to 1.412342,2.057878
+"datapath" at 0.825085,1.830601
+linethick = 0.500000;
+spline -> from 0.227108,1.716453 to 0.227108,1.716453 to 0.351483,1.625610 to 0.638463,1.416057 to 0.763109,1.325027
+"ports*" at 0.498823,1.623371
+linethick = 0.500000;
+spline -> from 0.835109,1.238000 to 0.835109,1.238000 to 0.852901,1.149549 to 0.905022,0.947272 to 1.025903,0.831564 to 1.388360,0.484661 to 1.584632,0.514359 to 2.077723,0.421667 to 2.258866,0.387610 to 2.370300,0.370903 to 2.481055,0.518260 to 2.549747,0.609595 to 2.575358,0.746064 to 2.584178,0.814739
+"chassis?" at 1.841795,0.511476
+linethick = 0.500000;
+spline -> from 0.930989,1.306404 to 0.930989,1.306404 to 0.961417,1.312968 to 0.994864,1.319447 to 1.025903,1.323908 to 1.151397,1.341903 to 1.183674,1.340394 to 1.310356,1.345109 to 1.833993,1.364597 to 2.085355,1.549506 to 2.481055,1.206114 to 2.571627,1.127669 to 2.587061,0.975020 to 2.588927,0.900493
+"additional_chassis*" at 1.841795,1.430202
+linethick = 0.500000;
+spline -> from 0.930904,1.266512 to 0.930904,1.266512 to 1.028583,1.252689 to 1.179214,1.232200 to 1.310356,1.217902 to 1.829583,1.161269 to 2.059744,1.425131 to 2.481055,1.116594 to 2.551104,1.065388 to 2.575697,0.960111 to 2.584178,0.900714
+"requested_chassis?" at 1.841795,1.286509
+linethick = 0.500000;
+spline -> from 0.931549,1.243292 to 0.931549,1.243292 to 0.961706,1.233217 to 0.994847,1.223075 to 1.025903,1.215544 to 1.598744,1.076566 to 1.771576,1.179824 to 2.336208,1.010587 to 2.404052,0.990285 to 2.421013,0.981872 to 2.481055,0.944626 to 2.501578,0.931990 to 2.522440,0.915928 to 2.540249,0.901036
+"requested_additional_chassis*" at 1.841795,1.145156
+linethick = 0.500000;
+spline -> from 0.849271,1.324501 to 0.849271,1.324501 to 0.880072,1.379811 to 0.942014,1.473385 to 1.025903,1.512361 to 1.290003,1.635023 to 2.045157,1.524692 to 2.336208,1.521775 to 2.545507,1.519689 to 2.600461,1.546521 to 2.806876,1.512361 to 2.820614,1.510072 to 2.835031,1.506357 to 2.848770,1.502219
+"encap?" at 2.206965,1.555052
+linethick = 0.500000;
+spline -> from 0.909211,1.324925 to 0.909211,1.324925 to 1.026700,1.383170 to 1.251654,1.479372 to 1.455814,1.479372 to 1.455814,1.479372 to 1.455814,1.479372 to 2.593337,1.479372 to 2.682043,1.479372 to 2.784487,1.479372 to 2.848430,1.479372
+"additional_encap*" at 2.206965,1.496164
+linethick = 1.000000;
+spline -> from 0.843810,1.324518 to 0.843810,1.324518 to 0.871083,1.390124 to 0.932261,1.514295 to 1.025903,1.578323 to 1.116865,1.640502 to 1.183963,1.560599 to 1.267953,1.631903 to 1.400758,1.744608 to 1.440566,1.964762 to 1.451743,2.057878
+"datapath" at 1.146937,1.649288
+linethick = 0.500000;
+spline -> from 0.931210,1.281505 to 0.931210,1.281505 to 1.062963,1.281505 to 1.286119,1.281505 to 1.393906,1.281505
+"mirror_rules*" at 1.146937,1.298280
+linethick = 1.000000;
+spline -> from 0.845336,1.238119 to 0.845336,1.238119 to 0.873475,1.176313 to 0.934415,1.065083 to 1.025903,1.017066 to 1.243377,0.902919 to 1.540432,0.928801 to 1.708821,0.957211
+"gateway_chassis*" at 1.146937,1.034451
+linethick = 1.000000;
+spline -> from 0.836262,1.238136 to 0.836262,1.238136 to 0.855225,1.157215 to 0.908041,0.984162 to 1.025903,0.904004 to 1.108164,0.848050 to 1.220429,0.837551 to 1.309627,0.840451
+"ha_chassis_group?" at 1.146937,0.921372
+linethick = 1.000000;
+spline -> from 0.230042,3.067058 to 0.230042,3.067058 to 0.344342,3.067058 to 0.588564,3.067058 to 0.725151,3.067058
+"bands+" at 0.498823,3.083849
+linethick = 0.500000;
+spline -> from 1.974769,0.977106 to 1.974769,0.977106 to 2.104860,0.967286 to 2.309410,0.945644 to 2.481055,0.899883 to 2.495133,0.896151 to 2.509719,0.891165 to 2.523458,0.885941
+"chassis?" at 2.206965,0.984976
+linethick = 0.500000;
+spline -> from 1.607140,0.815061 to 1.607140,0.815061 to 1.781923,0.770538 to 2.082132,0.713057 to 2.336208,0.760294 to 2.402186,0.772574 to 2.473253,0.801458 to 2.523118,0.824559
+"ref_chassis*" at 2.206965,0.777679
+linethick = 1.000000;
+spline -> from 1.606648,0.857480 to 1.606648,0.857480 to 1.754785,0.857480 to 1.979858,0.857480 to 2.107404,0.857480
+"ha_chassis*" at 1.841795,0.874255
+linethick = 1.000000;
+spline -> from 0.939639,2.272265 to 0.939639,2.272265 to 1.029753,2.254795 to 1.158792,2.226131 to 1.267953,2.188478 to 1.302961,2.176266 to 1.340207,2.159814 to 1.372230,2.144549
+"datapath" at 1.146937,2.271248
+linethick = 1.000000;
+spline -> from 0.888841,2.158626 to 0.888841,2.158626 to 0.988589,2.148619 to 1.188135,2.128436 to 1.321856,2.114867
+"datapaths+" at 1.146937,2.162867
+linethick = 0.500000;
+spline -> from 0.265881,3.448680 to 0.265881,3.448680 to 0.376500,3.448680 to 0.557305,3.448680 to 0.682748,3.448680
+"permissions value*" at 0.498823,3.465472
+linethick = 0.500000;
+spline -> from 2.307035,0.857480 to 2.307035,0.857480 to 2.375049,0.857480 to 2.463924,0.857480 to 2.523458,0.857480
+"chassis?" at 2.429833,0.874255
+linethick = 0.500000;
+spline -> from 2.337226,0.510272 to 2.337226,0.510272 to 2.387261,0.525604 to 2.442045,0.549960 to 2.481055,0.588343 to 2.544659,0.650760 to 2.571796,0.755511 to 2.582312,0.814230
+"chassis?" at 2.429833,0.605711
+linethick = 0.500000;
+spline -> from 0.928106,2.046684 to 0.928106,2.046684 to 1.017423,2.054656 to 1.151448,2.067207 to 1.267953,2.079419 to 1.285593,2.081284 to 1.304131,2.083320 to 1.322432,2.085525
+"datapath" at 1.146937,2.096888
+linethick = 0.500000;
+spline -> from 0.174139,1.238373 to 0.174139,1.238373 to 0.204838,1.046290 to 0.356724,0.277974 to 0.822727,0.277974 to 0.822727,0.277974 to 0.822727,0.277974 to 2.209340,0.277974 to 2.345028,0.277974 to 2.397098,0.310505 to 2.481055,0.416952 to 2.576037,0.537087 to 2.588757,0.728967 to 2.589436,0.814213
+"chassis?" at 1.458171,0.294748
+linethick = 0.500000;
+spline -> from 0.264252,1.324807 to 0.264252,1.324807 to 0.517056,1.438869 to 1.185353,1.743760 to 1.267953,1.816184 to 1.347687,1.886233 to 1.407763,1.997667 to 1.436698,2.058387
+"datapath?" at 0.825085,1.670489
+linethick = 0.500000;
+spline -> from 0.274514,1.281505 to 0.274514,1.281505 to 0.397379,1.281505 to 0.597875,1.281505 to 0.719333,1.281505
+"ports*" at 0.498823,1.298280
+linethick = 1.000000;
+spline -> from 0.283469,2.645746 to 0.283469,2.645746 to 0.312608,2.636587 to 0.343986,2.627089 to 0.373379,2.619457 to 0.772014,2.516673 to 0.949935,2.640658 to 1.267953,2.379289 to 1.348043,2.313480 to 1.407576,2.204760 to 1.436427,2.144718
+"datapaths*" at 0.825085,2.589266
+linethick = 1.000000;
+spline -> from 0.283418,2.685096 to 0.283418,2.685096 to 0.393750,2.684757 to 0.560358,2.684078 to 0.679152,2.683569
+"datapath_group?" at 0.498823,2.699852
+linethick = 1.000000;
+spline -> from 0.283418,2.655414 to 0.283418,2.655414 to 0.312574,2.649139 to 0.343952,2.643372 to 0.373379,2.640149 to 0.484220,2.628107 to 0.513393,2.628277 to 0.624267,2.640149 to 0.642143,2.642015 to 0.660767,2.644898 to 0.679135,2.648291
+"ls_datapath_group?" at 0.498823,2.655245
+linethick = 1.000000;
+spline -> from 0.282502,2.711894 to 0.282502,2.711894 to 0.311947,2.717491 to 0.343698,2.722749 to 0.373379,2.725463 to 0.484372,2.736318 to 0.513376,2.737336 to 0.624267,2.725463 to 0.642126,2.723597 to 0.660750,2.720884 to 0.679135,2.717491
+"lr_datapath_group?" at 0.498823,2.749378
+linethick = 1.000000;
+spline -> from 0.984620,1.938982 to 0.984620,1.938982 to 1.069696,1.956451 to 1.175923,1.981723 to 1.267953,2.013610 to 1.302995,2.025652 to 1.340241,2.042274 to 1.372264,2.057709
+"datapath" at 1.146937,2.030910
+.ps +3
+.PE
+.RE\}
.bp
.SH "SB_Global TABLE"
.PP
@@ -247,6 +473,13 @@ optional string
\fBoptions : lb_hairpin_use_ct_mark\fR
optional string
.RE
+.TQ .25in
+\fIOptions for configuring ovn-sbctl:\fR
+.RS .25in
+.TQ 2.50in
+\fBoptions : sbctl_probe_interval\fR
+optional string
+.RE
.RE
.TQ .25in
\fIConnection Options:\fR
@@ -306,6 +539,17 @@ If set to a 32-bit number \fBovn\-controller\fR will add a \fBsample\fR action t
These options apply when \fBovn\-controller\fR configures load balancer related flows\[char46]
.IP "\fBoptions : lb_hairpin_use_ct_mark\fR: optional string"
By default this option is turned on (even if not present in the database) unless its value is explicitly set to \fBfalse\fR\[char46] This value is automatically set to \fBfalse\fR by \fBovn\-northd\fR when action \fBct_lb_mark\fR cannot be used for new load balancer sessions and action \fBct_lb\fR will be used instead\[char46] \fBovn\-controller\fR then knows that it should check \fBct_label\[char46]natted\fR to detect load balanced traffic\[char46]
+.ST "Options for configuring ovn-sbctl:"
+.PP
+.PP
+.PP
+These options apply when \fBovn\-sbctl\fR connects to OVN Southbound database\[char46]
+.IP "\fBoptions : sbctl_probe_interval\fR: optional string"
+The inactivity probe interval of the connection to the OVN Southbound database from \fBovn\-sbctl\fR utility, in milliseconds\[char46] If the value is zero, it disables the connection keepalive feature\[char46]
+.IP
+If the value is nonzero, then it will be forced to a value of at least 1000 ms\[char46]
+.IP
+If the value is less than zero, then the default inactivity probe interval for \fBovn\-sbctl\fR would be left intact (120000 ms)\[char46]
.ST "Connection Options:"
.PP
.IP "\fBconnections\fR: set of \fBConnection\fRs"
@@ -494,7 +738,7 @@ string
string
.SS "Details:
.IP "\fBtype\fR: string, one of \fBgeneve\fR, \fBstt\fR, or \fBvxlan\fR"
-The encapsulation to use to transmit packets to this chassis\[char46] Hypervisors must use either \fBgeneve\fR or \fBstt\fR\[char46] Gateways may use \fBvxlan\fR, \fBgeneve\fR, or \fBstt\fR\[char46]
+The encapsulation to use to transmit packets to this chassis\[char46] Hypervisors and gateways must use one of: \fBgeneve\fR, \fBvxlan\fR, or \fBstt\fR\[char46]
.IP "\fBoptions\fR: map of string-string pairs"
Options for configuring the encapsulation, which may be \fBtype\fR specific\[char46]
.IP "\fBoptions : csum\fR: optional string, either \fBtrue\fR or \fBfalse\fR"
@@ -1091,7 +1335,7 @@ Adds or updates the entry for Ethernet address \fIA\fR in fdb table, setting its
.IP
\fBResult\fR: stored to a 1-bit subfield \fIR\fR\[char46]
.IP
-Looks up \fIA\fR in fdb table\[char46] If an entry is found and the the logical port key is \fIP\fR, \fBP\fR, stores \fB1\fR in the 1-bit subfield \fIR\fR, else 0\[char46]
+Looks up \fIA\fR in fdb table\[char46] If an entry is found and the logical port key is \fIP\fR, \fBP\fR, stores \fB1\fR in the 1-bit subfield \fIR\fR, else 0\[char46] If \fBflags\[char46]localnet\fR is set then \fB1\fR is stored if an entry is found and the logical port key is \fIP\fR or if an entry is found and the entry port type is VIF\[char46]
.IP
\fBExample:\fR \fB
reg0[0] = lookup_fdb(inport, eth\[char46]src);
@@ -1565,6 +1809,9 @@ An unsigned 8-bit integer that identifies the sampling application\[char46] It w
\fBobs_point=\fR\fIid\fR
An unsigned 32-bit integer to be used as \fBObsservationPointID\fR or the string \fB@cookie\fR to indicate that the first 32 bits of the \fBLogical_Flow\fR\(cqs UUID shall be used instead\[char46]
.RE
+.TP
+\fBmac_cache_use;\fR
+This action resubmits to corresponding table which updates the use statistics of MAC cache\[char46]
.RE
.IP "\fBtags\fR: map of string-string pairs"
Key-value pairs that provide additional information to help ovn-controller processing the logical flow\[char46] Below are the tags used by ovn-controller\[char46]
@@ -1644,13 +1891,13 @@ Each row in this table represents a mirror that can be used for port mirroring\[
string (must be unique within table)
.TQ 3.00in
\fBfilter\fR
-string, either \fBfrom\-lport\fR or \fBto\-lport\fR
+string, one of \fBboth\fR, \fBfrom\-lport\fR, or \fBto\-lport\fR
.TQ 3.00in
\fBsink\fR
string
.TQ 3.00in
\fBtype\fR
-string, either \fBerspan\fR or \fBgre\fR
+string, one of \fBerspan\fR, \fBgre\fR, or \fBlocal\fR
.TQ 3.00in
\fBindex\fR
integer
@@ -1660,14 +1907,14 @@ map of string-string pairs
.SS "Details:
.IP "\fBname\fR: string (must be unique within table)"
Represents the name of the mirror\[char46]
-.IP "\fBfilter\fR: string, either \fBfrom\-lport\fR or \fBto\-lport\fR"
-The value of this field represents selection criteria of the mirror\[char46]
+.IP "\fBfilter\fR: string, one of \fBboth\fR, \fBfrom\-lport\fR, or \fBto\-lport\fR"
+The value of this field represents selection criteria of the mirror\[char46] \fBto\-lport\fR mirrors the packets coming into logical port\[char46] \fBfrom\-lport\fR mirrors the packets going out of logical port\[char46] \fBboth\fR mirrors for both directions\[char46]
.IP "\fBsink\fR: string"
-The value of this field represents the destination/sink of the mirror\[char46]
-.IP "\fBtype\fR: string, either \fBerspan\fR or \fBgre\fR"
-The value of this field represents the type of the tunnel used for sending the mirrored packets
+The value of this field represents the destination/sink of the mirror\[char46] If the \fItype\fR is \fBgre\fR or \fBerspan\fR, the value indicates the tunnel remote IP (either IPv4 or IPv6)\[char46] For a \fItype\fR of \fBlocal\fR, this field defines a local interface on the OVS integration bridge to be used as the mirror destination\[char46] The interface must possess external-ids:mirror-id that matches this string\[char46]
+.IP "\fBtype\fR: string, one of \fBerspan\fR, \fBgre\fR, or \fBlocal\fR"
+The value of this field specifies the mirror type - \fBgre\fR, \fBerspan\fR or \fBlocal\fR\[char46]
.IP "\fBindex\fR: integer"
-The value of this field represents the key/idx depending on the tunnel type configured
+The value of this field represents the tunnel ID\[char46] If the configured tunnel type is \fBgre\fR, this field represents the \fBGRE\fR key value and if the configured tunnel type is \fBerspan\fR it represents the \fBerspan_idx\fR value\[char46] It is ignored if the type is \fBlocal\fR\[char46]
.IP "\fBexternal_ids\fR: map of string-string pairs"
See \fBExternal IDs\fR at the beginning of this document\[char46]
.bp
@@ -1946,6 +2193,9 @@ optional string
\fBoptions : qos_burst\fR
optional string
.TQ 2.75in
+\fBoptions : qos_physical_network\fR
+optional string
+.TQ 2.75in
\fBoptions : qdisc_queue_id\fR
optional string, containing an integer, in range 1 to 61,440
.RE
@@ -2173,6 +2423,8 @@ If set, indicates the minimum guaranteed rate available for data sent from this
If set, indicates the maximum rate for data sent from this interface, in bit/s\[char46] The traffic will be shaped according to this limit\[char46]
.IP "\fBoptions : qos_burst\fR: optional string"
If set, indicates the maximum burst size for data sent from this interface, in bits\[char46]
+.IP "\fBoptions : qos_physical_network\fR: optional string"
+If set, indicates the name of the egress network name where traffic shaping will be applied\[char46]
.IP "\fBoptions : qdisc_queue_id\fR: optional string, containing an integer, in range 1 to 61,440"
Indicates the queue number on the physical device\[char46] This is same as the \fBqueue_id\fR used in OpenFlow in \fBstruct
ofp_action_enqueue\fR\[char46]
@@ -2383,7 +2635,7 @@ string
integer, in range 0 to 254
.TQ 3.00in
\fBtype\fR
-string, one of \fBipv6\fR, \fBmac\fR, or \fBstr\fR
+string, one of \fBdomain\fR, \fBipv6\fR, \fBmac\fR, or \fBstr\fR
.SS "Details:
.IP "\fBname\fR: string"
Name of the DHCPv6 option\[char46]
@@ -2393,7 +2645,7 @@ Example\[char46] name=\(dqia_addr\(dq
DHCPv6 option code for the DHCPv6 option as defined in the appropriate RFC\[char46]
.IP
Example\[char46] code=3
-.IP "\fBtype\fR: string, one of \fBipv6\fR, \fBmac\fR, or \fBstr\fR"
+.IP "\fBtype\fR: string, one of \fBdomain\fR, \fBipv6\fR, \fBmac\fR, or \fBstr\fR"
Data type of the DHCPv6 option code\[char46]
.RS
.TP
@@ -2662,6 +2914,9 @@ map of string-string pairs
.TQ 3.00in
\fBdatapaths\fR
set of 1 or more \fBDatapath_Binding\fRs
+.TQ 3.00in
+\fBoptions : ovn-owned\fR
+optional string
.TQ .25in
\fICommon Columns:\fR
.RS .25in
@@ -2676,6 +2931,8 @@ Key-value pair of DNS records with \fBDNS query name\fR as the key and a string
\fBExample: \fR \(dqvm1\[char46]ovn\[char46]org\(dq = \(dq10\[char46]0\[char46]0\[char46]4 aef0::4\(dq
.IP "\fBdatapaths\fR: set of 1 or more \fBDatapath_Binding\fRs"
The DNS records defined in the column \fBrecords\fR will be applied only to the DNS queries originating from the datapaths defined in this column\[char46]
+.IP "\fBoptions : ovn-owned\fR: optional string"
+This column indicates that all the \fBDomains\fR in this table are owned by OVN, and all \fBDNS queries\fR for those domains will be answered locally by either an IP address or \fBDNS rejection\fR\[char46]
.ST "Common Columns:"
.PP
.IP "\fBexternal_ids\fR: map of string-string pairs"
@@ -2949,6 +3206,9 @@ optional weak reference to \fBChassis\fR
.TQ 3.00in
\fBports\fR
set of weak reference to \fBPort_Binding\fRs
+.TQ 3.00in
+\fBchassis_name\fR
+string
.SS "Details:
.IP "\fBaddress\fR: string"
Destination IPv4 address for the IGMP group\[char46]
@@ -2958,6 +3218,8 @@ Datapath to which this IGMP group belongs\[char46]
Chassis to which this IGMP group belongs\[char46]
.IP "\fBports\fR: set of weak reference to \fBPort_Binding\fRs"
The destination port bindings for this IGMP group\[char46]
+.IP "\fBchassis_name\fR: string"
+The chassis that inserted this record\[char46] This column is used for RBAC purposes only\[char46]
.bp
.SH "Service_Monitor TABLE"
.PP
@@ -2990,6 +3252,9 @@ string
\fBsrc_ip\fR
string
.TQ 2.75in
+\fBchassis_name\fR
+string
+.TQ 2.75in
\fBoptions : interval\fR
optional string, containing an integer
.TQ 2.75in
@@ -3034,6 +3299,8 @@ The VIF of the logical port on which the service is running\[char46] The \fBovn\
Source Ethernet address to use in the service monitor packet\[char46]
.IP "\fBsrc_ip\fR: string"
Source IPv4 address to use in the service monitor packet\[char46]
+.IP "\fBchassis_name\fR: string"
+The name of the chassis where the logical port is bound\[char46]
.IP "\fBoptions : interval\fR: optional string, containing an integer"
The interval, in seconds, between service monitor checks\[char46]
.IP "\fBoptions : timeout\fR: optional string, containing an integer"
@@ -3077,6 +3344,12 @@ set of \fBDatapath_Binding\fRs
.TQ 3.00in
\fBdatapath_group\fR
optional \fBLogical_DP_Group\fR
+.TQ 3.00in
+\fBls_datapath_group\fR
+optional \fBLogical_DP_Group\fR
+.TQ 3.00in
+\fBlr_datapath_group\fR
+optional \fBLogical_DP_Group\fR
.TQ .25in
\fILoad_Balancer options:\fR
.RS .25in
@@ -3104,7 +3377,11 @@ Valid protocols are \fBtcp\fR, \fBudp\fR, or \fBsctp\fR\[char46] This column is
.IP "\fBdatapaths\fR: set of \fBDatapath_Binding\fRs"
Datapaths to which this load balancer applies to\[char46]
.IP "\fBdatapath_group\fR: optional \fBLogical_DP_Group\fR"
+Deprecated\[char46] The group of datapaths to which this load balancer applies to\[char46] This means that the same load balancer applies to all datapaths in a group\[char46]
+.IP "\fBls_datapath_group\fR: optional \fBLogical_DP_Group\fR"
The group of datapaths to which this load balancer applies to\[char46] This means that the same load balancer applies to all datapaths in a group\[char46]
+.IP "\fBlr_datapath_group\fR: optional \fBLogical_DP_Group\fR"
+The group of logical router datapaths to which this load balancer applies to\[char46] This means that the same load balancer applies to all datapaths in a group\[char46]
.ST "Load_Balancer options:"
.PP
.IP "\fBoptions : hairpin_snat_ip\fR: optional string"
@@ -3147,6 +3424,9 @@ integer
\fBdetect_mult\fR
integer
.TQ 2.75in
+\fBchassis_name\fR
+string
+.TQ 2.75in
\fBoptions\fR
map of string-string pairs
.TQ 2.75in
@@ -3177,6 +3457,8 @@ This is the minimum interval, in milliseconds, that the local system would like
This is the minimum interval, in milliseconds, between received BFD Control packets that this system is capable of supporting, less any jitter applied by the sender\[char46] If this value is zero, the transmitting system does not want the remote system to send any periodic BFD Control packets\[char46]
.IP "\fBdetect_mult\fR: integer"
Detection time multiplier\[char46] The negotiated transmit interval, multiplied by this value, provides the Detection Time for the receiving system in Asynchronous mode\[char46]
+.IP "\fBchassis_name\fR: string"
+The name of the chassis where the logical port is bound\[char46]
.IP "\fBoptions\fR: map of string-string pairs"
Reserved for future use\[char46]
.IP "\fBexternal_ids\fR: map of string-string pairs"
@@ -3211,6 +3493,9 @@ integer, in range 1 to 16,777,215
.TQ 3.00in
\fBport_key\fR
integer, in range 1 to 16,777,215
+.TQ 3.00in
+\fBtimestamp\fR
+integer
.SS "Details:
.IP "\fBmac\fR: string"
The learnt mac address\[char46]
@@ -3218,6 +3503,8 @@ The learnt mac address\[char46]
The key of the datapath on which this FDB was learnt\[char46]
.IP "\fBport_key\fR: integer, in range 1 to 16,777,215"
The key of the port binding on which this FDB was learnt\[char46]
+.IP "\fBtimestamp\fR: integer"
+The timestamp in msec when the FDB was added or updated\[char46] Records that existed before this column will have 0\[char46]
.bp
.SH "Static_MAC_Binding TABLE"
.PP
diff --git a/src/static/support/dist-docs/ovn-sb.5.html b/src/static/support/dist-docs/ovn-sb.5.html
index 45218900..df8ae710 100644
--- a/src/static/support/dist-docs/ovn-sb.5.html
+++ b/src/static/support/dist-docs/ovn-sb.5.html
@@ -1,52 +1,49 @@
-ovn-sb(5) Open vSwitch Manual ovn-sb(5)
-
-
+ovn-sb(5) Open vSwitch Manual ovn-sb(5)
NAME
ovn-sb - OVN_Southbound database schema
This database holds logical and physical configuration and state for
- the Open Virtual Network (OVN) system to support virtual network
- abstraction. For an introduction to OVN, please see ovn-architec‐
- ture(7).
+ the Open Virtual Network (OVN) system to support virtual network ab‐
+ straction. For an introduction to OVN, please see ovn-architecture(7).
The OVN Southbound database sits at the center of the OVN architecture.
It is the one component that speaks both southbound directly to all the
- hypervisors and gateways, via ovn-controller/ovn-controller-vtep, and
+ hypervisors and gateways, via ovn-controller/ovn-controller-vtep, and
northbound to the Cloud Management System, via ovn-northd:
Database Structure
- The OVN Southbound database contains classes of data with different
+ The OVN Southbound database contains classes of data with different
properties, as described in the sections below.
Physical network
- Physical network tables contain information about the chassis nodes in
- the system. This contains all the information necessary to wire the
- overlay, such as IP addresses, supported tunnel types, and security
+ Physical network tables contain information about the chassis nodes in
+ the system. This contains all the information necessary to wire the
+ overlay, such as IP addresses, supported tunnel types, and security
keys.
- The amount of physical network data is small (O(n) in the number of
- chassis) and it changes infrequently, so it can be replicated to every
+ The amount of physical network data is small (O(n) in the number of
+ chassis) and it changes infrequently, so it can be replicated to every
chassis.
The Chassis and Encap tables are the physical network tables.
Logical Network
- Logical network tables contain the topology of logical switches and
- routers, ACLs, firewall rules, and everything needed to describe how
- packets traverse a logical network, represented as logical datapath
+ Logical network tables contain the topology of logical switches and
+ routers, ACLs, firewall rules, and everything needed to describe how
+ packets traverse a logical network, represented as logical datapath
flows (see Logical Datapath Flows, below).
Logical network data may be large (O(n) in the number of logical ports,
ACL rules, etc.). Thus, to improve scaling, each chassis should receive
- only data related to logical networks in which that chassis partici‐
+ only data related to logical networks in which that chassis partici‐
pates.
- The logical network data is ultimately controlled by the cloud manage‐
- ment system (CMS) running northbound of OVN. That CMS determines the
+ The logical network data is ultimately controlled by the cloud manage‐
+ ment system (CMS) running northbound of OVN. That CMS determines the
entire OVN logical configuration and therefore the logical network data
at any given time is a deterministic function of the CMS’s configura‐
tion, although that happens indirectly via the OVN_Northbound database
@@ -67,12 +64,12 @@
sis, and map logical entities to the values that represent them in tun‐
nel encapsulations.
- These tables change frequently, at least every time a VM powers up or
- down or migrates, and especially quickly in a container environment.
+ These tables change frequently, at least every time a VM powers up or
+ down or migrates, and especially quickly in a container environment.
The amount of data per VM (or VIF) is small.
- Each chassis is authoritative about the VMs and VIFs that it hosts at
- any given time and can efficiently flood that state to a central loca‐
+ Each chassis is authoritative about the VMs and VIFs that it hosts at
+ any given time and can efficiently flood that state to a central loca‐
tion, so the consistency needs are minimal.
The Port_Binding and Datapath_Binding tables contain binding data.
@@ -88,12 +85,12 @@
Common Columns
Some tables contain a special column named external_ids. This column
- has the same form and purpose each place that it appears, so we
- describe it here to save space later.
+ has the same form and purpose each place that it appears, so we de‐
+ scribe it here to save space later.
external_ids: map of string-string pairs
Key-value pairs for use by the software that manages the
- OVN Southbound database rather than by ovn-con‐
+ OVN Southbound database rather than by ovn-con‐‐
troller/ovn-controller-vtep. In particular, ovn-northd
can use key-value pairs in this column to relate entities
in the southbound database to higher-level entities (such
@@ -169,8 +166,8 @@
Chassis_Template_Var configuration.
SB_Global TABLE
- Southbound configuration for an OVN system. This table must have
- exactly one row.
+ Southbound configuration for an OVN system. This table must have ex‐
+ actly one row.
Summary:
Status:
@@ -193,6 +190,9 @@
Options for configuring Load Balancers:
options : lb_hairpin_use_ct_mark
optional string
+ Options for configuring ovn-sbctl:
+ options : sbctl_probe_interval
+ optional string
Connection Options:
connections set of Connections
ssl optional SSL
@@ -228,8 +228,8 @@
Options for configuring BFD:
- These options apply when ovn-controller configures BFD on tunnels
- interfaces.
+ These options apply when ovn-controller configures BFD on tunnels in‐
+ terfaces.
options : bfd-min-rx: optional string
BFD option min-rx value to use when configuring BFD on tunnel
@@ -244,48 +244,62 @@
interfaces.
options : bfd-mult: optional string
- BFD option mult value to use when configuring BFD on tunnel
- interfaces.
+ BFD option mult value to use when configuring BFD on tunnel in‐
+ terfaces.
options : debug_drop_domain_id: optional string
If set to a 8-bit number and if debug_drop_collector_set is also
- configured, ovn-controller will add a sample action to every
- flow that does not come from a logical flow that contains a
- ’drop’ action. The 8 most significant bits of the observa‐
- tion_domain_id field will be those specified in the
- debug_drop_domain_id. The 24 least significant bits of the
- observation_domain_id field will be zero.
-
- The observation_point_id will be set to the OpenFlow table num‐
+ configured, ovn-controller will add a sample action to every
+ flow that does not come from a logical flow that contains a
+ ’drop’ action. The 8 most significant bits of the observa‐
+ tion_domain_id field will be those specified in the de‐‐
+ bug_drop_domain_id. The 24 least significant bits of the obser‐
+ vation_domain_id field will be zero.
+
+ The observation_point_id will be set to the OpenFlow table num‐
ber.
options : debug_drop_collector_set: optional string
- If set to a 32-bit number ovn-controller will add a sample
- action to every flow that does not come from a logical flow that
+ If set to a 32-bit number ovn-controller will add a sample ac‐
+ tion to every flow that does not come from a logical flow that
contains a ’drop’ action. The sample action will have the speci‐
fied collector_set_id. The value must match that of the local
OVS configuration as described in ovs-actions(7).
Options for configuring Load Balancers:
- These options apply when ovn-controller configures load balancer
- related flows.
+ These options apply when ovn-controller configures load balancer re‐
+ lated flows.
options : lb_hairpin_use_ct_mark: optional string
By default this option is turned on (even if not present in the
database) unless its value is explicitly set to false. This
value is automatically set to false by ovn-northd when action
- ct_lb_mark cannot be used for new load balancer sessions and
- action ct_lb will be used instead. ovn-controller then knows
- that it should check ct_label.natted to detect load balanced
- traffic.
+ ct_lb_mark cannot be used for new load balancer sessions and ac‐
+ tion ct_lb will be used instead. ovn-controller then knows that
+ it should check ct_label.natted to detect load balanced traffic.
+
+ Options for configuring ovn-sbctl:
+
+ These options apply when ovn-sbctl connects to OVN Southbound database.
+
+ options : sbctl_probe_interval: optional string
+ The inactivity probe interval of the connection to the OVN
+ Southbound database from ovn-sbctl utility, in milliseconds. If
+ the value is zero, it disables the connection keepalive feature.
+
+ If the value is nonzero, then it will be forced to a value of at
+ least 1000 ms.
+
+ If the value is less than zero, then the default inactivity
+ probe interval for ovn-sbctl would be left intact (120000 ms).
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 Connec‐
+ 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 Connec‐‐
tion table for more information.
ssl: optional SSL
@@ -294,14 +308,14 @@
Security Configurations:
ipsec: boolean
- Tunnel encryption configuration. If this column is set to be
+ Tunnel encryption configuration. If this column is set to be
true, all OVN tunnels will be encrypted with IPsec.
Chassis TABLE
- Each row in this table represents a hypervisor or gateway (a chassis)
- in the physical network. Each chassis, via ovn-controller/ovn-con‐
- troller-vtep, adds and updates its own row, and keeps a copy of the
- remaining rows to determine how to reach other hypervisors.
+ Each row in this table represents a hypervisor or gateway (a chassis)
+ in the physical network. Each chassis, via ovn-controller/ovn-con‐‐
+ troller-vtep, adds and updates its own row, and keeps a copy of the re‐
+ maining rows to determine how to reach other hypervisors.
When a chassis shuts down gracefully, it should remove its own row.
(This is not critical because resources hosted on the chassis are
@@ -347,14 +361,14 @@
on. ovn-controller-vtep will leave this column empty.
nb_cfg: integer
- Deprecated. This column is replaced by the nb_cfg column of the
+ Deprecated. This column is replaced by the nb_cfg column of the
Chassis_Private table.
other_config : ovn-bridge-mappings: optional string
- ovn-controller populates this key with the set of bridge map‐
- pings it has been configured to use. Other applications should
- treat this key as read-only. See ovn-controller(8) for more
- information.
+ ovn-controller populates this key with the set of bridge map‐
+ pings it has been configured to use. Other applications should
+ treat this key as read-only. See ovn-controller(8) for more in‐
+ formation.
other_config : datapath-type: optional string
ovn-controller populates this key with the datapath type config‐
@@ -365,13 +379,13 @@
other_config : iface-types: optional string
ovn-controller populates this key with the interface types con‐
figured in the iface_types column of the Open_vSwitch database’s
- Open_vSwitch table. Other applications should treat this key as
+ Open_vSwitch table. Other applications should treat this key as
read-only. See ovn-controller(8) for more information.
other_config : ovn-cms-options: optional string
- ovn-controller populates this key with the set of options con‐
- figured in the external_ids:ovn-cms-options column of the
- Open_vSwitch database’s Open_vSwitch table. See ovn-con‐
+ ovn-controller populates this key with the set of options con‐
+ figured in the external_ids:ovn-cms-options column of the
+ Open_vSwitch database’s Open_vSwitch table. See ovn-con‐‐
troller(8) for more information.
other_config : is-interconn: optional string
@@ -389,13 +403,13 @@
transport_zones: set of strings
ovn-controller populates this key with the transport zones con‐
figured in the external_ids:ovn-transport-zones column of the
- Open_vSwitch database’s Open_vSwitch table. See ovn-con‐
+ Open_vSwitch database’s Open_vSwitch table. See ovn-con‐‐
troller(8) for more information.
other_config : ovn-chassis-mac-mappings: optional string
ovn-controller populates this key with the set of options con‐
figured in the external_ids:ovn-chassis-mac-mappings column of
- the Open_vSwitch database’s Open_vSwitch table. See ovn-con‐
+ the Open_vSwitch database’s Open_vSwitch table. See ovn-con‐‐
troller(8) for more information.
other_config : port-up-notif: optional string
@@ -421,26 +435,26 @@
Gateway Configuration:
- A gateway is a chassis that forwards traffic between the OVN-managed
+ A gateway is a chassis that forwards traffic between the OVN-managed
part of a logical network and a physical VLAN, extending a tunnel-based
logical network into a physical network. Gateways are typically dedi‐
- cated nodes that do not host VMs and will be controlled by ovn-con‐
+ cated nodes that do not host VMs and will be controlled by ovn-con‐‐
troller-vtep.
vtep_logical_switches: set of strings
Stores all VTEP logical switch names connected by this gateway
- chassis. The Port_Binding table entry with options:vtep-physi‐
+ chassis. The Port_Binding table entry with options:vtep-physi‐‐
cal-switch equal Chassis name, and options:vtep-logical-switch
value in Chassis vtep_logical_switches, will be associated with
this Chassis.
Chassis_Private TABLE
- Each row in this table maintains per chassis private data that are
- accessed only by the owning chassis (write only) and ovn-northd, not by
+ Each row in this table maintains per chassis private data that are ac‐
+ cessed only by the owning chassis (write only) and ovn-northd, not by
any other chassis. These data are stored in this separate table instead
- of the Chassis table for performance considerations: the rows in this
- table can be conditionally monitored by chassises so that each chassis
- only get update notifications for its own row, to avoid unnecessary
+ of the Chassis table for performance considerations: the rows in this
+ table can be conditionally monitored by chassises so that each chassis
+ only get update notifications for its own row, to avoid unnecessary
chassis private data update flooding in a large scale deployment.
Summary:
@@ -456,13 +470,13 @@
The name of the chassis that owns these chassis-private data.
chassis: optional weak reference to Chassis
- The reference to Chassis table for the chassis that owns these
+ The reference to Chassis table for the chassis that owns these
chassis-private data.
nb_cfg: integer
- Sequence number for the configuration. When ovn-controller
- updates the configuration of a chassis from the contents of the
- southbound database, it copies nb_cfg from the SB_Global table
+ Sequence number for the configuration. When ovn-controller up‐
+ dates the configuration of a chassis from the contents of the
+ southbound database, it copies nb_cfg from the SB_Global table
into this column.
nb_cfg_timestamp: integer
@@ -475,7 +489,6 @@
at the beginning of this document.
external_ids: map of string-string pairs
-
Encap TABLE
The encaps column in the Chassis table refers to rows in this table to
identify how OVN may transmit logical dataplane packets to this chas‐
@@ -493,9 +506,8 @@
Details:
type: string, one of geneve, stt, or vxlan
- The encapsulation to use to transmit packets to this chassis.
- Hypervisors must use either geneve or stt. Gateways may use
- vxlan, geneve, or stt.
+ The encapsulation to use to transmit packets to this chassis.
+ Hypervisors and gateways must use one of: geneve, vxlan, or stt.
options: map of string-string pairs
Options for configuring the encapsulation, which may be type
@@ -511,27 +523,26 @@
table. Other applications should treat this key as read-only.
See ovn-controller(8) for more information.
- In terms of performance, checksumming actually significantly
- increases throughput in most common cases when running on Linux
- based hosts without NICs supporting encapsulation hardware off‐
- load (around 60% for bulk traffic). The reason is that generally
- all NICs are capable of offloading transmitted and received
+ In terms of performance, checksumming actually significantly in‐
+ creases throughput in most common cases when running on Linux
+ based hosts without NICs supporting encapsulation hardware of‐
+ fload (around 60% for bulk traffic). The reason is that gener‐
+ ally all NICs are capable of offloading transmitted and received
TCP/UDP checksums (viewed as ordinary data packets and not as
tunnels). The benefit comes on the receive side where the vali‐
- dated outer checksum can be used to additionally validate an
- inner checksum (such as TCP), which in turn allows aggregation
- of packets to be more efficiently handled by the rest of the
- stack.
+ dated outer checksum can be used to additionally validate an in‐
+ ner checksum (such as TCP), which in turn allows aggregation of
+ packets to be more efficiently handled by the rest of the stack.
Not all devices see such a benefit. The most notable exception
- is hardware VTEPs. These devices are designed to not buffer
- entire packets in their switching engines and are therefore
- unable to efficiently compute or validate full packet checksums.
- In addition certain versions of the Linux kernel are not able to
+ is hardware VTEPs. These devices are designed to not buffer en‐
+ tire packets in their switching engines and are therefore unable
+ to efficiently compute or validate full packet checksums. In ad‐
+ dition certain versions of the Linux kernel are not able to
fully take advantage of encapsulation NIC offloads in the pres‐
ence of checksums. (This is actually a pretty narrow corner case
- though: earlier versions of Linux don’t support encapsulation
- offloads at all and later versions support both offloads and
+ though: earlier versions of Linux don’t support encapsulation
+ offloads at all and later versions support both offloads and
checksums well.)
csum defaults to false for hardware VTEPs and true for all other
@@ -565,10 +576,9 @@
name: string (must be unique within table)
addresses: set of strings
-
Port_Group TABLE
This table contains names for the logical switch ports in the
- OVN_Northbound database that belongs to the same group that is defined
+ OVN_Northbound database that belongs to the same group that is defined
in Port_Group in the OVN_Northbound database.
Summary:
@@ -579,57 +589,56 @@
name: string (must be unique within table)
ports: set of strings
-
Logical_Flow TABLE
- Each row in this table represents one logical flow. ovn-northd popu‐
- lates this table with logical flows that implement the L2 and L3
- topologies specified in the OVN_Northbound database. Each hypervisor,
- via ovn-controller, translates the logical flows into OpenFlow flows
+ Each row in this table represents one logical flow. ovn-northd popu‐
+ lates this table with logical flows that implement the L2 and L3
+ topologies specified in the OVN_Northbound database. Each hypervisor,
+ via ovn-controller, translates the logical flows into OpenFlow flows
specific to its hypervisor and installs them into Open vSwitch.
- Logical flows are expressed in an OVN-specific format, described here.
- A logical datapath flow is much like an OpenFlow flow, except that the
- flows are written in terms of logical ports and logical datapaths
- instead of physical ports and physical datapaths. Translation between
- logical and physical flows helps to ensure isolation between logical
- datapaths. (The logical flow abstraction also allows the OVN central‐
- ized components to do less work, since they do not have to separately
+ Logical flows are expressed in an OVN-specific format, described here.
+ A logical datapath flow is much like an OpenFlow flow, except that the
+ flows are written in terms of logical ports and logical datapaths in‐
+ stead of physical ports and physical datapaths. Translation between
+ logical and physical flows helps to ensure isolation between logical
+ datapaths. (The logical flow abstraction also allows the OVN central‐
+ ized components to do less work, since they do not have to separately
compute and push out physical flows to each chassis.)
The default action when no flow matches is to drop packets.
Architectural Logical Life Cycle of a Packet
- This following description focuses on the life cycle of a packet
- through a logical datapath, ignoring physical details of the implemen‐
- tation. Please refer to Architectural Physical Life Cycle of a Packet
+ This following description focuses on the life cycle of a packet
+ through a logical datapath, ignoring physical details of the implemen‐
+ tation. Please refer to Architectural Physical Life Cycle of a Packet
in ovn-architecture(7) for the physical information.
- The description here is written as if OVN itself executes these steps,
- but in fact OVN (that is, ovn-controller) programs Open vSwitch, via
+ The description here is written as if OVN itself executes these steps,
+ but in fact OVN (that is, ovn-controller) programs Open vSwitch, via
OpenFlow and OVSDB, to execute them on its behalf.
- At a high level, OVN passes each packet through the logical datapath’s
- logical ingress pipeline, which may output the packet to one or more
- logical port or logical multicast groups. For each such logical output
- port, OVN passes the packet through the datapath’s logical egress pipe‐
- line, which may either drop the packet or deliver it to the destina‐
- tion. Between the two pipelines, outputs to logical multicast groups
- are expanded into logical ports, so that the egress pipeline only pro‐
- cesses a single logical output port at a time. Between the two pipe‐
- lines is also where, when necessary, OVN encapsulates a packet in a
+ At a high level, OVN passes each packet through the logical datapath’s
+ logical ingress pipeline, which may output the packet to one or more
+ logical port or logical multicast groups. For each such logical output
+ port, OVN passes the packet through the datapath’s logical egress
+ pipeline, which may either drop the packet or deliver it to the desti‐
+ nation. Between the two pipelines, outputs to logical multicast groups
+ are expanded into logical ports, so that the egress pipeline only
+ processes a single logical output port at a time. Between the two
+ pipelines is also where, when necessary, OVN encapsulates a packet in a
tunnel (or tunnels) to transmit to remote hypervisors.
In more detail, to start, OVN searches the Logical_Flow table for a row
- with correct logical_datapath or a logical_dp_group, a pipeline of
- ingress, a table_id of 0, and a match that is true for the packet. If
- none is found, OVN drops the packet. If OVN finds more than one, it
- chooses the match with the highest priority. Then OVN executes each of
- the actions specified in the row’s actions column, in the order speci‐
- fied. Some actions, such as those to modify packet headers, require no
+ with correct logical_datapath or a logical_dp_group, a pipeline of
+ ingress, a table_id of 0, and a match that is true for the packet. If
+ none is found, OVN drops the packet. If OVN finds more than one, it
+ chooses the match with the highest priority. Then OVN executes each of
+ the actions specified in the row’s actions column, in the order speci‐
+ fied. Some actions, such as those to modify packet headers, require no
further details. The next and output actions are special.
- The next action causes the above process to be repeated recursively,
+ The next action causes the above process to be repeated recursively,
except that OVN searches for table_id of 1 instead of 0. Similarly, any
next action in a row found in that table would cause a further search
for a table_id of 2, and so on. When recursive processing completes,
@@ -639,10 +648,10 @@
current value of the outport field. Suppose outport designates a logi‐
cal port. First, OVN compares inport to outport; if they are equal, it
treats the output as a no-op by default. In the common case, where they
- are different, the packet enters the egress pipeline. This transition
- to the egress pipeline discards register data, e.g. reg0 ... reg9 and
- connection tracking state, to achieve uniform behavior regardless of
- whether the egress pipeline is on a different hypervisor (because reg‐
+ are different, the packet enters the egress pipeline. This transition
+ to the egress pipeline discards register data, e.g. reg0 ... reg9 and
+ connection tracking state, to achieve uniform behavior regardless of
+ whether the egress pipeline is on a different hypervisor (because reg‐
isters aren’t preserve across tunnel encapsulation).
To execute the egress pipeline, OVN again searches the Logical_Flow ta‐
@@ -652,23 +661,22 @@
no-op. Otherwise, OVN executes the actions for the matching flow (which
is chosen from multiple, if necessary, as already described).
- In the egress pipeline, the next action acts as already described,
- except that it, of course, searches for egress flows. The output
- action, however, now directly outputs the packet to the output port
- (which is now fixed, because outport is read-only within the egress
- pipeline).
+ In the egress pipeline, the next action acts as already described, ex‐
+ cept that it, of course, searches for egress flows. The output action,
+ however, now directly outputs the packet to the output port (which is
+ now fixed, because outport is read-only within the egress pipeline).
The description earlier assumed that outport referred to a logical
- port. If it instead designates a logical multicast group, then the
- description above still applies, with the addition of fan-out from the
+ port. If it instead designates a logical multicast group, then the de‐
+ scription above still applies, with the addition of fan-out from the
logical multicast group to each logical port in the group. For each
member of the group, OVN executes the logical pipeline as described,
with the logical output port replaced by the group member.
Pipeline Stages
- ovn-northd populates the Logical_Flow table with the logical flows
- described in detail in ovn-northd(8).
+ ovn-northd populates the Logical_Flow table with the logical flows de‐
+ scribed in detail in ovn-northd(8).
Summary:
logical_datapath optional Datapath_Binding
@@ -691,17 +699,17 @@
The logical datapath to which the logical flow belongs.
logical_dp_group: optional Logical_DP_Group
- The group of logical datapaths to which the logical flow
- belongs. This means that the same logical flow belongs to all
+ The group of logical datapaths to which the logical flow be‐
+ longs. This means that the same logical flow belongs to all
datapaths in a group.
pipeline: string, either egress or ingress
The primary flows used for deciding on a packet’s destination
- are the ingress flows. The egress flows implement ACLs. See Log‐
+ are the ingress flows. The egress flows implement ACLs. See Log‐‐
ical Life Cycle of a Packet, above, for details.
table_id: integer, in range 0 to 32
- The stage in the logical pipeline, analogous to an OpenFlow ta‐
+ The stage in the logical pipeline, analogous to an OpenFlow ta‐
ble number.
priority: integer, in range 0 to 65,535
@@ -711,11 +719,11 @@
to the packet is undefined.
match: string
- A matching expression. OVN provides a superset of OpenFlow
+ A matching expression. OVN provides a superset of OpenFlow
matching capabilities, using a syntax similar to Boolean expres‐
sions in a programming language.
- The most important components of match expression are compar‐
+ The most important components of match expression are compar
isons between symbols and constants, e.g. ip4.dst ==
192.168.0.1, ip.proto == 6, arp.op == 1, eth.type == 0x800. The
logical AND operator &&&& and logical OR operator || can combine
@@ -723,48 +731,48 @@
Matching expressions also support parentheses for grouping, the
logical NOT prefix operator !, and literals 0 and 1 to express
- ``false’’ or ``true,’’ respectively. The latter is useful by
- itself as a catch-all expression that matches every packet.
+ ``false’’ or ``true,’’ respectively. The latter is useful by it‐
+ self as a catch-all expression that matches every packet.
- Match expressions also support a kind of function syntax. The
+ Match expressions also support a kind of function syntax. The
following functions are supported:
is_chassis_resident(lport)
- Evaluates to true on a chassis on which logical port
- lport (a quoted string) resides, and to false elsewhere.
+ Evaluates to true on a chassis on which logical port
+ lport (a quoted string) resides, and to false elsewhere.
This function was introduced in OVN 2.7.
Symbols
- Type. Symbols have integer or string type. Integer symbols have
+ Type. Symbols have integer or string type. Integer symbols have
a width in bits.
Kinds. There are three kinds of symbols:
- · Fields. A field symbol represents a packet header or
+ • Fields. A field symbol represents a packet header or
metadata field. For example, a field named vlan.tci might
represent the VLAN TCI field in a packet.
A field symbol can have integer or string type. Integer
- fields can be nominal or ordinal (see Level of Measure‐
+ fields can be nominal or ordinal (see Level of Measure‐‐
ment, below).
- · Subfields. A subfield represents a subset of bits from a
- larger field. For example, a field vlan.vid might be
- defined as an alias for vlan.tci[0..11]. Subfields are
- provided for syntactic convenience, because it is always
- possible to instead refer to a subset of bits from a
+ • Subfields. A subfield represents a subset of bits from a
+ larger field. For example, a field vlan.vid might be de‐
+ fined as an alias for vlan.tci[0..11]. Subfields are pro‐
+ vided for syntactic convenience, because it is always
+ possible to instead refer to a subset of bits from a
field directly.
Only ordinal fields (see Level of Measurement, below) may
have subfields. Subfields are always ordinal.
- · Predicates. A predicate is shorthand for a Boolean
- expression. Predicates may be used much like 1-bit
- fields. For example, ip4 might expand to eth.type ==
- 0x800. Predicates are provided for syntactic convenience,
- because it is always possible to instead specify the
- underlying expression directly.
+ • Predicates. A predicate is shorthand for a Boolean ex‐
+ pression. Predicates may be used much like 1-bit fields.
+ For example, ip4 might expand to eth.type == 0x800. Pred‐
+ icates are provided for syntactic convenience, because it
+ is always possible to instead specify the underlying ex‐
+ pression directly.
A predicate whose expansion refers to any nominal field
or predicate (see Level of Measurement, below) is nomi‐
@@ -775,7 +783,7 @@
tistical concept on which this classification is based. There
are three levels:
- · Ordinal. In statistics, ordinal values can be ordered on
+ • Ordinal. In statistics, ordinal values can be ordered on
a scale. OVN considers a field (or subfield) to be ordi‐
nal if its bits can be examined individually. This is
true for the OpenFlow fields that OpenFlow or Open
@@ -791,16 +799,16 @@
because OVN can implement these in OpenFlow and Open
vSwitch as collections of bitwise tests.
- · Nominal. In statistics, nominal values cannot be usefully
- compared except for equality. This is true of OpenFlow
- port numbers, Ethernet types, and IP protocols are exam‐
- ples: all of these are just identifiers assigned arbi‐
- trarily with no deeper meaning. In OpenFlow and Open
- vSwitch, bits in these fields generally aren’t individu‐
+ • Nominal. In statistics, nominal values cannot be usefully
+ compared except for equality. This is true of OpenFlow
+ port numbers, Ethernet types, and IP protocols are exam‐
+ ples: all of these are just identifiers assigned arbi‐
+ trarily with no deeper meaning. In OpenFlow and Open
+ vSwitch, bits in these fields generally aren’t individu‐
ally addressable.
- OVN only supports arithmetic tests for equality on nomi‐
- nal fields, because OpenFlow and Open vSwitch provide no
+ OVN only supports arithmetic tests for equality on nomi‐
+ nal fields, because OpenFlow and Open vSwitch provide no
way for a flow to efficiently implement other comparisons
on them. (A test for inequality can be sort of built out
of two flows with different priorities, but OVN matching
@@ -809,45 +817,45 @@
String fields are always nominal.
- · Boolean. A nominal field that has only two values, 0 and
+ • Boolean. A nominal field that has only two values, 0 and
1, is somewhat exceptional, since it is easy to support
- both equality and inequality tests on such a field:
- either one can be implemented as a test for 0 or 1.
+ both equality and inequality tests on such a field: ei‐
+ ther one can be implemented as a test for 0 or 1.
Only predicates (see above) have a Boolean level of mea‐
surement.
This isn’t a standard level of measurement.
- Prerequisites. Any symbol can have prerequisites, which are
- additional condition implied by the use of the symbol. For exam‐
+ Prerequisites. Any symbol can have prerequisites, which are ad‐
+ ditional condition implied by the use of the symbol. For exam‐
ple, For example, icmp4.type symbol might have prerequisite
- icmp4, which would cause an expression icmp4.type == 0 to be
- interpreted as icmp4.type == 0 &&&& icmp4, which would in turn
- expand to icmp4.type == 0 &&&& eth.type == 0x800 &&&& ip4.proto == 1
- (assuming icmp4 is a predicate defined as suggested under Types
+ icmp4, which would cause an expression icmp4.type == 0 to be in‐
+ terpreted as icmp4.type == 0 &&&& icmp4, which would in turn ex‐
+ pand to icmp4.type == 0 &&&& eth.type == 0x800 &&&& ip4.proto == 1
+ (assuming icmp4 is a predicate defined as suggested under Types
above).
Relational operators
- All of the standard relational operators ==, !=, =, >gt;>gt;, and
- >gt;>gt;= are supported. Nominal fields support only == and !=, and
- only in a positive sense when outer ! are taken into account,
+ All of the standard relational operators ==, !=, =, >gt;>gt;, and
+ >gt;>gt;= are supported. Nominal fields support only == and !=, and
+ only in a positive sense when outer ! are taken into account,
e.g. given string field inport, inport == "eth0" and !(inport !=
"eth0") are acceptable, but not inport != "eth0".
- The implementation of == (or != when it is negated), is more
- efficient than that of the other relational operators.
+ The implementation of == (or != when it is negated), is more ef‐
+ ficient than that of the other relational operators.
Constants
- Integer constants may be expressed in decimal, hexadecimal pre‐
+ Integer constants may be expressed in decimal, hexadecimal pre‐
fixed by 0x, or as dotted-quad IPv4 addresses, IPv6 addresses in
their standard forms, or Ethernet addresses as colon-separated
hex digits. A constant in any of these forms may be followed by
a slash and a second constant (the mask) in the same form, to
- form a masked constant. IPv4 and IPv6 masks may be given as
- integers, to express CIDR prefixes.
+ form a masked constant. IPv4 and IPv6 masks may be given as in‐
+ tegers, to express CIDR prefixes.
String constants have the same syntax as quoted strings in JSON
(thus, they are Unicode strings).
@@ -857,58 +865,58 @@
last elements, are optional. With ==, ``field == { constant1,
constant2, ... }’’ is syntactic sugar for ``field == constant1
|| field == constant2 || .... Similarly, ``field != { constant1,
- constant2, ... }’’ is equivalent to ``field != constant1 &&&&
+ constant2, ... }’’ is equivalent to ``field != constant1 &&&&
field != constant2 &&&& ...’’.
You may refer to a set of IPv4, IPv6, or MAC addresses stored in
the Address_Set table by its name. An Address_Set with a name of
set1 can be referred to as $set1.
- You may refer to a group of logical switch ports stored in the
- Port_Group table by its name. An Port_Group with a name of
+ You may refer to a group of logical switch ports stored in the
+ Port_Group table by its name. An Port_Group with a name of
port_group1 can be referred to as @port_group1.
Additionally, you may refer to the set of addresses belonging to
a group of logical switch ports stored in the Port_Group table
by its name followed by a suffix ’_ip4’/’_ip6’. The IPv4 address
- set of a Port_Group with a name of port_group1 can be referred
- to as $port_group1_ip4, and the IPv6 address set of the same
+ set of a Port_Group with a name of port_group1 can be referred
+ to as $port_group1_ip4, and the IPv6 address set of the same
Port_Group can be referred to as $port_group1_ip6
Miscellaneous
- Comparisons may name the symbol or the constant first, e.g.
+ Comparisons may name the symbol or the constant first, e.g.
tcp.src == 80 and 80 == tcp.src are both acceptable.
- Tests for a range may be expressed using a syntax like 1024 =
- tcp.src = 49151, which is equivalent to 1024 = tcp.src &&&&
+ Tests for a range may be expressed using a syntax like 1024 =
+ tcp.src = 49151, which is equivalent to 1024 = tcp.src &&&&
tcp.src = 49151.
- For a one-bit field or predicate, a mention of its name is
- equivalent to symobl == 1, e.g. vlan.present is equivalent to
- vlan.present == 1. The same is true for one-bit subfields, e.g.
- vlan.tci[12]. There is no technical limitation to implementing
- the same for ordinal fields of all widths, but the implementa‐
+ For a one-bit field or predicate, a mention of its name is
+ equivalent to symobl == 1, e.g. vlan.present is equivalent to
+ vlan.present == 1. The same is true for one-bit subfields, e.g.
+ vlan.tci[12]. There is no technical limitation to implementing
+ the same for ordinal fields of all widths, but the implementa‐
tion is expensive enough that the syntax parser requires writing
an explicit comparison against zero to make mistakes less
- likely, e.g. in tcp.src != 0 the comparison against 0 is
- required.
+ likely, e.g. in tcp.src != 0 the comparison against 0 is re‐
+ quired.
Operator precedence is as shown below, from highest to lowest.
There are two exceptions where parentheses are required even
- though the table would suggest that they are not: &&&& and ||
- require parentheses when used together, and ! requires parenthe‐
- ses when applied to a relational expression. Thus, in (eth.type
- == 0x800 || eth.type == 0x86dd) &&&& ip.proto == 6 or !(arp.op ==
- 1), the parentheses are mandatory.
+ though the table would suggest that they are not: &&&& and || re‐
+ quire parentheses when used together, and ! requires parentheses
+ when applied to a relational expression. Thus, in (eth.type ==
+ 0x800 || eth.type == 0x86dd) &&&& ip.proto == 6 or !(arp.op == 1),
+ the parentheses are mandatory.
- · ()
+ • ()
- · == != = >gt;>gt; >gt;>gt;=
+ • == != = >gt;>gt; >gt;>gt;=
- · !
+ • !
- · &&&& ||
+ • &&&& ||
Comments may be introduced by //, which extends to the next new-
line. Comments within a line may be bracketed by /* and */. Mul‐
@@ -918,143 +926,143 @@
Most of the symbols below have integer type. Only inport and
outport have string type. inport names a logical port. Thus, its
- value is a logical_port name from the Port_Binding table. out‐
- port may name a logical port, as inport, or a logical multicast
- group defined in the Multicast_Group table. For both symbols,
+ value is a logical_port name from the Port_Binding table. out‐‐
+ port may name a logical port, as inport, or a logical multicast
+ group defined in the Multicast_Group table. For both symbols,
only names within the flow’s logical datapath may be used.
- The regX symbols are 32-bit integers. The xxregX symbols are
- 128-bit integers, which overlay four of the 32-bit registers:
+ The regX symbols are 32-bit integers. The xxregX symbols are
+ 128-bit integers, which overlay four of the 32-bit registers:
xxreg0 overlays reg0 through reg3, with reg0 supplying the most-
significant bits of xxreg0 and reg3 the least-significant.
xxreg1 similarly overlays reg4 through reg7.
- · reg0...reg9
+ • reg0...reg9
- · xxreg0 xxreg1
+ • xxreg0 xxreg1
- · inport outport
+ • inport outport
- · flags.loopback
+ • flags.loopback
- · pkt.mark
+ • pkt.mark
- · eth.src eth.dst eth.type
+ • eth.src eth.dst eth.type
- · vlan.tci vlan.vid vlan.pcp vlan.present
+ • vlan.tci vlan.vid vlan.pcp vlan.present
- · ip.proto ip.dscp ip.ecn ip.ttl ip.frag
+ • ip.proto ip.dscp ip.ecn ip.ttl ip.frag
- · ip4.src ip4.dst
+ • ip4.src ip4.dst
- · ip6.src ip6.dst ip6.label
+ • ip6.src ip6.dst ip6.label
- · arp.op arp.spa arp.tpa arp.sha arp.tha
+ • arp.op arp.spa arp.tpa arp.sha arp.tha
- · rarp.op rarp.spa rarp.tpa rarp.sha rarp.tha
+ • rarp.op rarp.spa rarp.tpa rarp.sha rarp.tha
- · tcp.src tcp.dst tcp.flags
+ • tcp.src tcp.dst tcp.flags
- · udp.src udp.dst
+ • udp.src udp.dst
- · sctp.src sctp.dst
+ • sctp.src sctp.dst
- · icmp4.type icmp4.code
+ • icmp4.type icmp4.code
- · icmp6.type icmp6.code
+ • icmp6.type icmp6.code
- · nd.target nd.sll nd.tll
+ • nd.target nd.sll nd.tll
- · ct_mark ct_label
+ • ct_mark ct_label
- · ct_state, which has several Boolean subfields. The
+ • ct_state, which has several Boolean subfields. The
ct_next action initializes the following subfields:
- · ct.trk: Always set to true by ct_next to indicate
+ • ct.trk: Always set to true by ct_next to indicate
that connection tracking has taken place. All
other ct subfields have ct.trk as a prerequisite.
- · ct.new: True for a new flow
+ • ct.new: True for a new flow
- · ct.est: True for an established flow
+ • ct.est: True for an established flow
- · ct.rel: True for a related flow
+ • ct.rel: True for a related flow
- · ct.rpl: True for a reply flow
+ • ct.rpl: True for a reply flow
- · ct.inv: True for a connection entry in a bad state
+ • ct.inv: True for a connection entry in a bad state
The ct_dnat, ct_snat, and ct_lb actions initialize the
following subfields:
- · ct.dnat: True for a packet whose destination IP
+ • ct.dnat: True for a packet whose destination IP
address has been changed.
- · ct.snat: True for a packet whose source IP address
+ • ct.snat: True for a packet whose source IP address
has been changed.
The following predicates are supported:
- · eth.bcast expands to eth.dst == ff:ff:ff:ff:ff:ff
+ • eth.bcast expands to eth.dst == ff:ff:ff:ff:ff:ff
- · eth.mcast expands to eth.dst[40]
+ • eth.mcast expands to eth.dst[40]
- · vlan.present expands to vlan.tci[12]
+ • vlan.present expands to vlan.tci[12]
- · ip4 expands to eth.type == 0x800
+ • ip4 expands to eth.type == 0x800
- · ip4.src_mcast expands to ip4.src[28..31] == 0xe
+ • ip4.src_mcast expands to ip4.src[28..31] == 0xe
- · ip4.mcast expands to ip4.dst[28..31] == 0xe
+ • ip4.mcast expands to ip4.dst[28..31] == 0xe
- · ip6 expands to eth.type == 0x86dd
+ • ip6 expands to eth.type == 0x86dd
- · ip expands to ip4 || ip6
+ • ip expands to ip4 || ip6
- · icmp4 expands to ip4 &&&& ip.proto == 1
+ • icmp4 expands to ip4 &&&& ip.proto == 1
- · icmp6 expands to ip6 &&&& ip.proto == 58
+ • icmp6 expands to ip6 &&&& ip.proto == 58
- · icmp expands to icmp4 || icmp6
+ • icmp expands to icmp4 || icmp6
- · ip.is_frag expands to ip.frag[0]
+ • ip.is_frag expands to ip.frag[0]
- · ip.later_frag expands to ip.frag[1]
+ • ip.later_frag expands to ip.frag[1]
- · ip.first_frag expands to ip.is_frag &&&& !ip.later_frag
+ • ip.first_frag expands to ip.is_frag &&&& !ip.later_frag
- · arp expands to eth.type == 0x806
+ • arp expands to eth.type == 0x806
- · rarp expands to eth.type == 0x8035
+ • rarp expands to eth.type == 0x8035
- · nd expands to icmp6.type == {135, 136} &&&& icmp6.code == 0
+ • nd expands to icmp6.type == {135, 136} &&&& icmp6.code == 0
&&&& ip.ttl == 255
- · nd_ns expands to icmp6.type == 135 &&&& icmp6.code == 0 &&&&
+ • nd_ns expands to icmp6.type == 135 &&&& icmp6.code == 0 &&&&
ip.ttl == 255
- · nd_na expands to icmp6.type == 136 &&&& icmp6.code == 0 &&&&
+ • nd_na expands to icmp6.type == 136 &&&& icmp6.code == 0 &&&&
ip.ttl == 255
- · nd_rs expands to icmp6.type == 133 &&&& icmp6.code == 0 &&&&
+ • nd_rs expands to icmp6.type == 133 &&&& icmp6.code == 0 &&&&
ip.ttl == 255
- · nd_ra expands to icmp6.type == 134 &&&& icmp6.code == 0 &&&&
+ • nd_ra expands to icmp6.type == 134 &&&& icmp6.code == 0 &&&&
ip.ttl == 255
- · tcp expands to ip.proto == 6
+ • tcp expands to ip.proto == 6
- · udp expands to ip.proto == 17
+ • udp expands to ip.proto == 17
- · sctp expands to ip.proto == 132
+ • sctp expands to ip.proto == 132
actions: string
Logical datapath actions, to be executed when the logical flow
represented by this row is the highest-priority match.
Actions share lexical syntax with the match column. An empty set
- of actions (or one that contains just white space or comments),
- or a set of actions that consists of just drop;, causes the
+ of actions (or one that contains just white space or comments),
+ or a set of actions that consists of just drop;, causes the
matched packets to be dropped. Otherwise, the column should con‐
tain a sequence of actions, each terminated by a semicolon.
@@ -1067,13 +1075,13 @@
ticast group, the egress pipeline runs once for each log‐
ical port in the group.
- In the egress pipeline, this action performs the actual
- output to the outport logical port. (In the egress pipe‐
- line, outport never names a multicast group.)
+ In the egress pipeline, this action performs the actual
+ output to the outport logical port. (In the egress
+ pipeline, outport never names a multicast group.)
- By default, output to the input port is implicitly
- dropped, that is, output becomes a no-op if outport ==
- inport. Occasionally it may be useful to override this
+ By default, output to the input port is implicitly
+ dropped, that is, output becomes a no-op if outport ==
+ inport. Occasionally it may be useful to override this
behavior, e.g. to send an ARP reply to an ARP request; to
do so, use flags.loopback = 1 to allow the packet to
"hair-pin" back to the input port.
@@ -1084,19 +1092,19 @@
Executes the given logical datapath table in pipeline as a
subroutine. The default table is just after the current
one. If pipeline is specified, it may be ingress or egress;
- the default pipeline is the one currently executing.
- Actions in the both ingress and egress pipeline can use
- next to jump across the other pipeline. Actions in the
- ingress pipeline should use next to jump into the specific
- table of egress pipeline only if it is certain that the
- packets are local and not tunnelled and wants to skip cer‐
- tain stages in the packet processing.
+ the default pipeline is the one currently executing. Ac‐
+ tions in the both ingress and egress pipeline can use next
+ to jump across the other pipeline. Actions in the ingress
+ pipeline should use next to jump into the specific table of
+ egress pipeline only if it is certain that the packets are
+ local and not tunnelled and wants to skip certain stages in
+ the packet processing.
field = constant;
- Sets data or metadata field field to constant value con‐
- stant, e.g. outport = "vif0"; to set the logical output
- port. To set only a subset of bits in a field, specify a
- subfield for field or a masked constant, e.g. one may use
+ Sets data or metadata field field to constant value con
+ stant, e.g. outport = "vif0"; to set the logical output
+ port. To set only a subset of bits in a field, specify a
+ subfield for field or a masked constant, e.g. one may use
vlan.pcp[2] = 1; or vlan.pcp = 4/4; to set the most signif‐
icant bit of the VLAN PCP.
@@ -1119,30 +1127,30 @@
Below are the supported OVN fields:
- · icmp4.frag_mtu icmp6.frag_mtu
+ • icmp4.frag_mtu icmp6.frag_mtu
This field sets the low-order 16 bits of the
- ICMP{4,6} header field that is labelled "unused" in
- the ICMP specification as defined in the RFC 1191
+ ICMP{4,6} header field that is labelled "unused" in
+ the ICMP specification as defined in the RFC 1191
with the value specified in constant.
Eg. icmp4.frag_mtu = 1500;
field1 = field2;
- Sets data or metadata field field1 to the value of data or
- metadata field field2, e.g. reg0 = ip4.src; copies ip4.src
+ Sets data or metadata field field1 to the value of data or
+ metadata field field2, e.g. reg0 = ip4.src; copies ip4.src
into reg0. To modify only a subset of a field’s bits, spec‐
ify a subfield for field1 or field2 or both, e.g. vlan.pcp
= reg0[0..2]; copies the least-significant bits of reg0
into the VLAN PCP.
field1 and field2 must be the same type, either both string
- or both integer fields. If they are both integer fields,
+ or both integer fields. If they are both integer fields,
they must have the same width.
- If field1 or field2 has prerequisites, they are added
- implicitly to match. It is possible to write an assignment
- with contradictory prerequisites, such as ip4.src =
+ If field1 or field2 has prerequisites, they are added im‐
+ plicitly to match. It is possible to write an assignment
+ with contradictory prerequisites, such as ip4.src =
ip6.src[0..31];, but the contradiction means that a logical
flow with such an assignment will never be matched.
@@ -1160,8 +1168,8 @@
ip.ttl--;
Decrements the IPv4 or IPv6 TTL. If this would make the TTL
- zero or negative, then processing of the packet halts; no
- further actions are processed. (To properly handle such
+ zero or negative, then processing of the packet halts; no
+ further actions are processed. (To properly handle such
cases, a higher-priority flow should match on ip.ttl == {0,
1};.)
@@ -1174,16 +1182,16 @@
As a side effect, IP fragments will be reassembled for
matching. If a fragmented packet is output, then it will be
- sent with any overlapping fragments squashed. The connec‐
- tion tracking state is scoped by the logical port when the
- action is used in a flow for a logical switch, so overlap‐
+ sent with any overlapping fragments squashed. The connec‐
+ tion tracking state is scoped by the logical port when the
+ action is used in a flow for a logical switch, so overlap‐
ping addresses may be used. To allow traffic related to the
matched flow, execute ct_commit . Connection tracking state
- is scoped by the logical topology when the action is used
+ is scoped by the logical topology when the action is used
in a flow for a router.
- It is possible to have actions follow ct_next, but they
- will not have access to any of its side-effects and is not
+ It is possible to have actions follow ct_next, but they
+ will not have access to any of its side-effects and is not
generally useful.
ct_commit { };
@@ -1198,8 +1206,8 @@
ct_mark is a 32-bit field. ct_label is a 128-bit field. The
value[/mask] should be specified in hex string if more than
64bits are to be used. Registers and other named fields can
- be used for value. ct_mark and ct_label may be sub-
- addressed in order to have specific bits set.
+ be used for value. ct_mark and ct_label may be sub-ad‐
+ dressed in order to have specific bits set.
Note that if you want processing to continue in the next
table, you must execute the next action after ct_commit.
@@ -1212,29 +1220,29 @@
ct_dnat(IP);
ct_dnat sends the packet through the DNAT zone in connec‐
tion tracking table to unDNAT any packet that was DNATed in
- the opposite direction. The packet is then automatically
- sent to to the next tables as if followed by next; action.
- The next tables will see the changes in the packet caused
+ the opposite direction. The packet is then automatically
+ sent to to the next tables as if followed by next; action.
+ The next tables will see the changes in the packet caused
by the connection tracker.
- ct_dnat(IP) sends the packet through the DNAT zone to
- change the destination IP address of the packet to the one
+ ct_dnat(IP) sends the packet through the DNAT zone to
+ change the destination IP address of the packet to the one
provided inside the parentheses and commits the connection.
The packet is then automatically sent to the next tables as
- if followed by next; action. The next tables will see the
+ if followed by next; action. The next tables will see the
changes in the packet caused by the connection tracker.
ct_snat;
ct_snat(IP);
- ct_snat sends the packet through the SNAT zone to unSNAT
- any packet that was SNATed in the opposite direction. The
- packet is automatically sent to the next tables as if fol‐
- lowed by the next; action. The next tables will see the
+ ct_snat sends the packet through the SNAT zone to unSNAT
+ any packet that was SNATed in the opposite direction. The
+ packet is automatically sent to the next tables as if fol‐
+ lowed by the next; action. The next tables will see the
changes in the packet caused by the connection tracker.
- ct_snat(IP) sends the packet through the SNAT zone to
- change the source IP address of the packet to the one pro‐
- vided inside the parenthesis and commits the connection.
+ ct_snat(IP) sends the packet through the SNAT zone to
+ change the source IP address of the packet to the one pro‐
+ vided inside the parenthesis and commits the connection.
The packet is then automatically sent to the next tables as
if followed by next; action. The next tables will see the
changes in the packet caused by the connection tracker.
@@ -1251,25 +1259,25 @@
ct_dnat_in_czone(IP) sends the packet through the common
NAT zone to change the destination IP address of the packet
- to the one provided inside the parentheses and commits the
- connection. The packet is then automatically sent to the
+ to the one provided inside the parentheses and commits the
+ connection. The packet is then automatically sent to the
next tables as if followed by next; action. The next tables
will see the changes in the packet caused by the connection
tracker.
ct_snat_in_czone;
ct_snat_in_czone(IP);
- ct_snat_in_czone sends the packet through the common NAT
- zone to unSNAT any packet that was SNATed in the opposite
- direction. The packet is automatically sent to the next
- tables as if followed by the next; action. The next tables
+ ct_snat_in_czone sends the packet through the common NAT
+ zone to unSNAT any packet that was SNATed in the opposite
+ direction. The packet is automatically sent to the next ta‐
+ bles as if followed by the next; action. The next tables
will see the changes in the packet caused by the connection
tracker.
- ct_snat_in_czone(IP) sends the packet\ through the common
- NAT zone to change the source IP address of the packet to
- the one provided inside the parenthesis and commits the
- connection. The packet is then automatically sent to the
+ ct_snat_in_czone(IP) sends the packet\ through the common
+ NAT zone to change the source IP address of the packet to
+ the one provided inside the parenthesis and commits the
+ connection. The packet is then automatically sent to the
next tables as if followed by next; action. The next tables
will see the changes in the packet caused by the connection
tracker.
@@ -1286,8 +1294,8 @@
clone { action; ... };
Makes a copy of the packet being processed and executes
- each action on the copy. Actions following the clone
- action, if any, apply to the original, unmodified packet.
+ each action on the copy. Actions following the clone ac‐
+ tion, if any, apply to the original, unmodified packet.
This can be used as a way to ``save and restore’’ the
packet around a set of actions that may modify it and
should not persist.
@@ -1300,67 +1308,67 @@
The ARP packet that this action operates on is initialized
based on the IPv4 packet being processed, as follows. These
- are default values that the nested actions will probably
+ are default values that the nested actions will probably
want to change:
- · eth.src unchanged
+ • eth.src unchanged
- · eth.dst unchanged
+ • eth.dst unchanged
- · eth.type = 0x0806
+ • eth.type = 0x0806
- · arp.op = 1 (ARP request)
+ • arp.op = 1 (ARP request)
- · arp.sha copied from eth.src
+ • arp.sha copied from eth.src
- · arp.spa copied from ip4.src
+ • arp.spa copied from ip4.src
- · arp.tha = 00:00:00:00:00:00
+ • arp.tha = 00:00:00:00:00:00
- · arp.tpa copied from ip4.dst
+ • arp.tpa copied from ip4.dst
- The ARP packet has the same VLAN header, if any, as the IP
+ The ARP packet has the same VLAN header, if any, as the IP
packet it replaces.
Prerequisite: ip4
get_arp(P, A);
- Parameters: logical port string field P, 32-bit IP address
+ Parameters: logical port string field P, 32-bit IP address
field A.
- Looks up A in P’s mac binding table. If an entry is found,
- stores its Ethernet address in eth.dst, otherwise stores
+ Looks up A in P’s mac binding table. If an entry is found,
+ stores its Ethernet address in eth.dst, otherwise stores
00:00:00:00:00:00 in eth.dst.
Example: get_arp(outport, ip4.dst);
put_arp(P, A, E);
- Parameters: logical port string field P, 32-bit IP address
+ Parameters: logical port string field P, 32-bit IP address
field A, 48-bit Ethernet address field E.
- Adds or updates the entry for IP address A in logical port
+ Adds or updates the entry for IP address A in logical port
P’s mac binding table, setting its Ethernet address to E.
Example: put_arp(inport, arp.spa, arp.sha);
R = lookup_arp(P, A, M);
- Parameters: logical port string field P, 32-bit IP address
+ Parameters: logical port string field P, 32-bit IP address
field A, 48-bit MAC address field M.
Result: stored to a 1-bit subfield R.
- Looks up A and M in P’s mac binding table. If an entry is
+ Looks up A and M in P’s mac binding table. If an entry is
found, stores 1 in the 1-bit subfield R, else 0.
Example: reg0[0] = lookup_arp(inport, arp.spa, arp.sha);
R = lookup_arp_ip(P, A);
- Parameters: logical port string field P, 32-bit IP address
+ Parameters: logical port string field P, 32-bit IP address
field A.
Result: stored to a 1-bit subfield R.
- Looks up A in P’s mac binding table. If an entry is found,
+ Looks up A in P’s mac binding table. If an entry is found,
stores 1 in the 1-bit subfield R, else 0.
Example: reg0[0] = lookup_arp_ip(inport, arp.spa);
@@ -1368,7 +1376,7 @@
P = get_fdb(A);
Parameters:48-bit MAC address field A.
- Looks up A in fdb table. If an entry is found, stores the
+ Looks up A in fdb table. If an entry is found, stores the
logical port key to the out parameter P.
Example: outport = get_fdb(eth.src);
@@ -1388,9 +1396,11 @@
Result: stored to a 1-bit subfield R.
- Looks up A in fdb table. If an entry is found and the the
- logical port key is P, P, stores 1 in the 1-bit subfield R,
- else 0.
+ Looks up A in fdb table. If an entry is found and the logi‐
+ cal port key is P, P, stores 1 in the 1-bit subfield R,
+ else 0. If flags.localnet is set then 1 is stored if an en‐
+ try is found and the logical port key is P or if an entry
+ is found and the entry port type is VIF.
Example: reg0[0] = lookup_fdb(inport, eth.src);
@@ -1401,23 +1411,23 @@
action, if any, apply to the original, unmodified packet.
The IPv6 NS packet that this action operates on is initial‐
- ized based on the IPv6 packet being processed, as follows.
+ ized based on the IPv6 packet being processed, as follows.
These are default values that the nested actions will prob‐
ably want to change:
- · eth.src unchanged
+ • eth.src unchanged
- · eth.dst set to IPv6 multicast MAC address
+ • eth.dst set to IPv6 multicast MAC address
- · eth.type = 0x86dd
+ • eth.type = 0x86dd
- · ip6.src copied from ip6.src
+ • ip6.src copied from ip6.src
- · ip6.dst set to IPv6 Solicited-Node multicast address
+ • ip6.dst set to IPv6 Solicited-Node multicast address
- · icmp6.type = 135 (Neighbor Solicitation)
+ • icmp6.type = 135 (Neighbor Solicitation)
- · nd.target copied from ip6.dst
+ • nd.target copied from ip6.dst
The IPv6 NS packet has the same VLAN header, if any, as the
IP packet it replaces.
@@ -1425,32 +1435,32 @@
Prerequisite: ip6
nd_na { action; ... };
- Temporarily replaces the IPv6 neighbor solicitation packet
- being processed by an IPv6 neighbor advertisement (NA)
- packet and executes each nested action on the NA packet.
- Actions following the nd_na action, if any, apply to the
+ Temporarily replaces the IPv6 neighbor solicitation packet
+ being processed by an IPv6 neighbor advertisement (NA)
+ packet and executes each nested action on the NA packet.
+ Actions following the nd_na action, if any, apply to the
original, unmodified packet.
- The NA packet that this action operates on is initialized
+ The NA packet that this action operates on is initialized
based on the IPv6 packet being processed, as follows. These
are default values that the nested actions will probably
want to change:
- · eth.dst exchanged with eth.src
+ • eth.dst exchanged with eth.src
- · eth.type = 0x86dd
+ • eth.type = 0x86dd
- · ip6.dst copied from ip6.src
+ • ip6.dst copied from ip6.src
- · ip6.src copied from nd.target
+ • ip6.src copied from nd.target
- · icmp6.type = 136 (Neighbor Advertisement)
+ • icmp6.type = 136 (Neighbor Advertisement)
- · nd.target unchanged
+ • nd.target unchanged
- · nd.sll = 00:00:00:00:00:00
+ • nd.sll = 00:00:00:00:00:00
- · nd.tll copied from eth.dst
+ • nd.tll copied from eth.dst
The ND packet has the same VLAN header, if any, as the IPv6
packet it replaces.
@@ -1458,33 +1468,33 @@
Prerequisite: nd_ns
nd_na_router { action; ... };
- Temporarily replaces the IPv6 neighbor solicitation packet
- being processed by an IPv6 neighbor advertisement (NA)
- packet, sets ND_NSO_ROUTER in the RSO flags and executes
- each nested action on the NA packet. Actions following the
+ Temporarily replaces the IPv6 neighbor solicitation packet
+ being processed by an IPv6 neighbor advertisement (NA)
+ packet, sets ND_NSO_ROUTER in the RSO flags and executes
+ each nested action on the NA packet. Actions following the
nd_na_router action, if any, apply to the original, unmodi‐
fied packet.
The NA packet that this action operates on is initialized
based on the IPv6 packet being processed, as follows. These
- are default values that the nested actions will probably
+ are default values that the nested actions will probably
want to change:
- · eth.dst exchanged with eth.src
+ • eth.dst exchanged with eth.src
- · eth.type = 0x86dd
+ • eth.type = 0x86dd
- · ip6.dst copied from ip6.src
+ • ip6.dst copied from ip6.src
- · ip6.src copied from nd.target
+ • ip6.src copied from nd.target
- · icmp6.type = 136 (Neighbor Advertisement)
+ • icmp6.type = 136 (Neighbor Advertisement)
- · nd.target unchanged
+ • nd.target unchanged
- · nd.sll = 00:00:00:00:00:00
+ • nd.sll = 00:00:00:00:00:00
- · nd.tll copied from eth.dst
+ • nd.tll copied from eth.dst
The ND packet has the same VLAN header, if any, as the IPv6
packet it replaces.
@@ -1492,8 +1502,8 @@
Prerequisite: nd_ns
get_nd(P, A);
- Parameters: logical port string field P, 128-bit IPv6
- address field A.
+ Parameters: logical port string field P, 128-bit IPv6 ad‐
+ dress field A.
Looks up A in P’s mac binding table. If an entry is found,
stores its Ethernet address in eth.dst, otherwise stores
@@ -1502,8 +1512,8 @@
Example: get_nd(outport, ip6.dst);
put_nd(P, A, E);
- Parameters: logical port string field P, 128-bit IPv6
- address field A, 48-bit Ethernet address field E.
+ Parameters: logical port string field P, 128-bit IPv6 ad‐
+ dress field A, 48-bit Ethernet address field E.
Adds or updates the entry for IPv6 address A in logical
port P’s mac binding table, setting its Ethernet address to
@@ -1528,7 +1538,7 @@
Result: stored to a 1-bit subfield R.
- Looks up A in P’s mac binding table. If an entry is found,
+ Looks up A in P’s mac binding table. If an entry is found,
stores 1 in the 1-bit subfield R, else 0.
Example: reg0[0] = lookup_nd_ip(inport, ip6.src);
@@ -1543,16 +1553,16 @@
When this action is applied to a DHCP request packet
(DHCPDISCOVER or DHCPREQUEST), it changes the packet into a
- DHCP reply (DHCPOFFER or DHCPACK, respectively), replaces
- the options by those specified as parameters, and stores 1
+ DHCP reply (DHCPOFFER or DHCPACK, respectively), replaces
+ the options by those specified as parameters, and stores 1
in R.
- When this action is applied to a non-DHCP packet or a DHCP
- packet that is not DHCPDISCOVER or DHCPREQUEST, it leaves
+ When this action is applied to a non-DHCP packet or a DHCP
+ packet that is not DHCPDISCOVER or DHCPREQUEST, it leaves
the packet unchanged and stores 0 in R.
- The contents of the DHCP_Option table control the DHCP
- option names and values that this action supports.
+ The contents of the DHCP_Option table control the DHCP op‐
+ tion names and values that this action supports.
Example: reg0[0] = put_dhcp_opts(offerip = 10.0.0.2, router
= 10.0.0.1, netmask = 255.255.255.0, dns_server = {8.8.8.8,
@@ -1565,32 +1575,31 @@
Valid only in the ingress pipeline.
- When this action is applied to a DHCPv6 request packet, it
- changes the packet into a DHCPv6 reply, replaces the
- options by those specified as parameters, and stores 1 in
- R.
+ When this action is applied to a DHCPv6 request packet, it
+ changes the packet into a DHCPv6 reply, replaces the op‐
+ tions by those specified as parameters, and stores 1 in R.
When this action is applied to a non-DHCPv6 packet or an
- invalid DHCPv6 request packet , it leaves the packet
- unchanged and stores 0 in R.
+ invalid DHCPv6 request packet , it leaves the packet un‐
+ changed and stores 0 in R.
The contents of the DHCPv6_Options table control the DHCPv6
option names and values that this action supports.
- Example: reg0[3] = put_dhcpv6_opts(ia_addr = aef0::4,
- server_id = 00:00:00:00:10:02,
+ Example: reg0[3] = put_dhcpv6_opts(ia_addr = aef0::4,
+ server_id = 00:00:00:00:10:02,
dns_server={ae70::1,ae70::2});
set_queue(queue_number);
- Parameters: Queue number queue_number, in the range 0 to
+ Parameters: Queue number queue_number, in the range 0 to
61440.
- This is a logical equivalent of the OpenFlow set_queue
- action. It affects packets that egress a hypervisor through
- a physical interface. For nonzero queue_number, it config‐
- ures packet queuing to match the settings configured for
- the Port_Binding with options:qdisc_queue_id matching
- queue_number. When queue_number is zero, it resets queuing
+ This is a logical equivalent of the OpenFlow set_queue ac‐
+ tion. It affects packets that egress a hypervisor through a
+ physical interface. For nonzero queue_number, it configures
+ packet queuing to match the settings configured for the
+ Port_Binding with options:qdisc_queue_id matching
+ queue_number. When queue_number is zero, it resets queuing
to the default strategy.
Example: set_queue(10);
@@ -1599,28 +1608,28 @@
ct_lb(backends=ip[:port][,...][;
hash_fields=field1,field2,...][; ct_flag]);
With arguments, ct_lb commits the packet to the connection
- tracking table and DNATs the packet’s destination IP
- address (and port) to the IP address or addresses (and
- optional ports) specified in the backends. If multiple
- comma-separated IP addresses are specified, each is given
- equal weight for picking the DNAT address. By default,
- dp_hash is used as the OpenFlow group selection method, but
- if hash_fields is specified, hash is used as the selection
+ tracking table and DNATs the packet’s destination IP ad‐
+ dress (and port) to the IP address or addresses (and op‐
+ tional ports) specified in the backends. If multiple comma-
+ separated IP addresses are specified, each is given equal
+ weight for picking the DNAT address. By default, dp_hash is
+ used as the OpenFlow group selection method, but if
+ hash_fields is specified, hash is used as the selection
method, and the fields listed are used as the hash fields.
The ct_flag field represents one of supported flag:
- skip_snat or force_snat, this flag will be stored in
- ct_label register.
+ skip_snat or force_snat, this flag will be stored in ct_la‐‐
+ bel register.
Without arguments, ct_lb sends the packet to the connection
tracking table to NAT the packets. If the packet is part of
- an established connection that was previously committed to
- the connection tracker via ct_lb(...), it will automati‐
+ an established connection that was previously committed to
+ the connection tracker via ct_lb(...), it will automati‐
cally get DNATed to the same IP address as the first packet
in that connection.
Processing automatically moves on to the next table, as if
next; were specified, and later tables act on the packet as
- modified by the connection tracker. Connection tracking
+ modified by the connection tracker. Connection tracking
state is scoped by the logical port when the action is used
in a flow for a logical switch, so overlapping addresses
may be used. Connection tracking state is scoped by the
@@ -1630,8 +1639,8 @@
ct_lb_mark;
ct_lb_mark(backends=ip[:port][,...][;
hash_fields=field1,field2,...][; ct_flag]);
- Same as ct_lb, except that it internally uses ct_mark to
- store the NAT flag, while ct_lb uses ct_label for the same
+ Same as ct_lb, except that it internally uses ct_mark to
+ store the NAT flag, while ct_lb uses ct_label for the same
purpose.
R = dns_lookup();
@@ -1641,18 +1650,18 @@
Valid only in the ingress pipeline.
- When this action is applied to a valid DNS request (a UDP
- packet typically directed to port 53), it attempts to
- resolve the query using the contents of the DNS table. If
- it is successful, it changes the packet into a DNS reply
- and stores 1 in R. If the action is applied to a non-DNS
- packet, an invalid DNS request packet, or a valid DNS
- request for which the DNS table does not supply an answer,
- it leaves the packet unchanged and stores 0 in R.
+ When this action is applied to a valid DNS request (a UDP
+ packet typically directed to port 53), it attempts to re‐
+ solve the query using the contents of the DNS table. If it
+ is successful, it changes the packet into a DNS reply and
+ stores 1 in R. If the action is applied to a non-DNS
+ packet, an invalid DNS request packet, or a valid DNS re‐
+ quest for which the DNS table does not supply an answer, it
+ leaves the packet unchanged and stores 0 in R.
Regardless of success, the action does not make any of the
changes to the flow that are necessary to direct the packet
- back to the requester. The logical pipeline can implement
+ back to the requester. The logical pipeline can implement
this behavior with matches and actions in later tables.
Example: reg0[3] = dns_lookup();
@@ -1660,10 +1669,10 @@
Prerequisite: udp
R = put_nd_ra_opts(D1 = V1, D2 = V2, ..., Dn = Vn);
- Parameters: The following IPv6 ND Router Advertisement
- option/value pairs as defined in RFC 4861.
+ Parameters: The following IPv6 ND Router Advertisement op‐
+ tion/value pairs as defined in RFC 4861.
- · addr_mode
+ • addr_mode
Mandatory parameter which specifies the address mode
flag to be set in the RA flag options field. The
@@ -1671,23 +1680,23 @@
values can be defined - "slaac", "dhcpv6_stateful"
and "dhcpv6_stateless".
- · slla
+ • slla
Mandatory parameter which specifies the link-layer
- address of the interface from which the Router
- Advertisement is sent.
+ address of the interface from which the Router Ad‐
+ vertisement is sent.
- · mtu
+ • mtu
Optional parameter which specifies the MTU.
- · prefix
+ • prefix
Optional parameter which should be specified if the
addr_mode is "slaac" or "dhcpv6_stateless". The
value should be an IPv6 prefix which will be used
- for stateless IPv6 address configuration. This
- option can be defined multiple times.
+ for stateless IPv6 address configuration. This op‐
+ tion can be defined multiple times.
Result: stored to a 1-bit subfield R.
@@ -1707,7 +1716,7 @@
set_meter(rate);
set_meter(rate, burst);
- Parameters: rate limit int field rate in kbps, burst rate
+ Parameters: rate limit int field rate in kbps, burst rate
limits int field burst in kbps.
This action sets the rate limit for a flow.
@@ -1719,47 +1728,47 @@
Result: stored to a 1-bit subfield R.
- This is a logical equivalent of the OpenFlow
- check_pkt_larger action. If the packet is larger than the
+ This is a logical equivalent of the OpenFlow
+ check_pkt_larger action. If the packet is larger than the
length specified in L, it stores 1 in the subfield R.
Example: reg0[6] = check_pkt_larger(1000);
log(key=value, ...);
- Causes ovn-controller to log the packet on the chassis
+ Causes ovn-controller to log the packet on the chassis
that processes it. Packet logging currently uses the same
logging mechanism as other Open vSwitch and OVN messages,
- which means that whether and where log messages appear
- depends on the local logging configuration that can be
+ which means that whether and where log messages appear
+ depends on the local logging configuration that can be
configured with ovs-appctl, etc.
- The log action takes zero or more of the following key-
+ The log action takes zero or more of the following key-
value pair arguments that control what is logged:
name=string
- An optional name for the ACL. The string is cur‐
+ An optional name for the ACL. The string is cur‐
rently limited to 64 bytes.
severity=level
- Indicates the severity of the event. The level is
- one of following (from more to less serious):
- alert, warning, notice, info, or debug. If a
+ Indicates the severity of the event. The level is
+ one of following (from more to less serious):
+ alert, warning, notice, info, or debug. If a
severity is not provided, the default is info.
verdict=value
- The verdict for packets matching the flow. The
+ The verdict for packets matching the flow. The
value must be one of allow, deny, or reject.
meter=string
- An optional rate-limiting meter to be applied to
+ An optional rate-limiting meter to be applied to
the logs. The string should reference a name entry
from the Meter table. The only meter action that
is appropriate is drop.
fwd_group(liveness=bool, childports=port, ...);
- Parameters: optional liveness, either true or false,
- defaulting to false; childports, a comma-delimited list
- of strings denoting logical ports to load balance across.
+ Parameters: optional liveness, either true or false, de‐
+ faulting to false; childports, a comma-delimited list of
+ strings denoting logical ports to load balance across.
Load balance traffic to one or more child ports in a log‐
ical switch. ovn-controller translates the fwd_group into
@@ -1774,24 +1783,24 @@
icmp4_error { action; ... };
Temporarily replaces the IPv4 packet being processed by an
ICMPv4 packet and executes each nested action on the ICMPv4
- packet. Actions following these actions, if any, apply to
+ packet. Actions following these actions, if any, apply to
the original, unmodified packet.
- The ICMPv4 packet that these actions operates on is ini‐
- tialized based on the IPv4 packet being processed, as fol‐
+ The ICMPv4 packet that these actions operates on is ini‐
+ tialized based on the IPv4 packet being processed, as fol‐
lows. These are default values that the nested actions will
probably want to change. Ethernet and IPv4 fields not
listed here are not changed:
- · ip.proto = 1 (ICMPv4)
+ • ip.proto = 1 (ICMPv4)
- · ip.frag = 0 (not a fragment)
+ • ip.frag = 0 (not a fragment)
- · ip.ttl = 255
+ • ip.ttl = 255
- · icmp4.type = 3 (destination unreachable)
+ • icmp4.type = 3 (destination unreachable)
- · icmp4.code = 1 (host unreachable)
+ • icmp4.code = 1 (host unreachable)
icmp4_error action is expected to be used to generate an
ICMPv4 packet in response to an error in original IP
@@ -1805,22 +1814,22 @@
icmp6_error { action; ... };
Temporarily replaces the IPv6 packet being processed by an
ICMPv6 packet and executes each nested action on the ICMPv6
- packet. Actions following the icmp6 action, if any, apply
+ packet. Actions following the icmp6 action, if any, apply
to the original, unmodified packet.
- The ICMPv6 packet that this action operates on is initial‐
- ized based on the IPv6 packet being processed, as follows.
+ The ICMPv6 packet that this action operates on is initial‐
+ ized based on the IPv6 packet being processed, as follows.
These are default values that the nested actions will prob‐
ably want to change. Ethernet and IPv6 fields not listed
here are not changed:
- · ip.proto = 58 (ICMPv6)
+ • ip.proto = 58 (ICMPv6)
- · ip.ttl = 255
+ • ip.ttl = 255
- · icmp6.type = 1 (destination unreachable)
+ • icmp6.type = 1 (destination unreachable)
- · icmp6.code = 1 (administratively prohibited)
+ • icmp6.code = 1 (administratively prohibited)
icmp6_error action is expected to be used to generate an
ICMPv6 packet in response to an error in original IPv6
@@ -1846,27 +1855,27 @@
Prerequisite: tcp
reject { action; ... };
- If the original packet is IPv4 or IPv6 TCP packet, it
- replaces it with IPv4 or IPv6 TCP RST packet and executes
- the inner actions. Otherwise it replaces it with an ICMPv4
- or ICMPv6 packet and executes the inner actions.
+ If the original packet is IPv4 or IPv6 TCP packet, it re‐
+ places it with IPv4 or IPv6 TCP RST packet and executes the
+ inner actions. Otherwise it replaces it with an ICMPv4 or
+ ICMPv6 packet and executes the inner actions.
- The inner actions should not attempt to swap eth source
- with eth destination and IP source with IP destination as
+ The inner actions should not attempt to swap eth source
+ with eth destination and IP source with IP destination as
this action implicitly does that.
trigger_event;
- This action is used to allow ovs-vswitchd to report CMS
- related events writing them in Controller_Event table. It
- is possible to associate a meter to a each event in order
- to not overload pinctrl thread under heavy load; each meter
- is identified though a defined naming convention. Supported
+ This action is used to allow ovs-vswitchd to report CMS re‐
+ lated events writing them in Controller_Event table. It is
+ possible to associate a meter to a each event in order to
+ not overload pinctrl thread under heavy load; each meter is
+ identified though a defined naming convention. Supported
events:
- · empty_lb_backends. This event is raised if a
- received packet is destined for a load balancer VIP
- that has no configured backend destinations. For
- this event, the event info includes the load bal‐
+ • empty_lb_backends. This event is raised if a re‐
+ ceived packet is destined for a load balancer VIP
+ that has no configured backend destinations. For
+ this event, the event info includes the load bal‐
ancer VIP, the load balancer UUID, and the transport
protocol. Associated meter: event-elb
@@ -1881,7 +1890,7 @@
logical port string field P.
Binds the virtual logical port V and sets the chassis col‐
- umn and virtual_parent of the table Port_Binding. vir‐
+ umn and virtual_parent of the table Port_Binding. vir‐‐
tual_parent is set to P.
handle_svc_check(P);
@@ -1897,9 +1906,9 @@
handle_dhcpv6_reply;
Handle DHCPv6 prefix delegation advertisements/replies from
- a IPv6 delegation server. ovn-controller will add an entry
- ipv6_ra_pd_list in the options table for each prefix
- received from the delegation server
+ a IPv6 delegation server. ovn-controller will add an entry
+ ipv6_ra_pd_list in the options table for each prefix re‐
+ ceived from the delegation server
R = select(N1[=W1], N2[=W2], ...);
Parameters: Integer N1, N2..., with optional weight W1, W2,
@@ -1909,26 +1918,26 @@
Select from a list of integers N1, N2..., each within the
range 0 ~ 65535, and store the selected one in the field R.
- There must be 2 or more integers listed, each with an
- optional weight, which is an integer within the range 1 ~
- 65535. If weight is not specified, it defaults to 100. The
- selection method is based on the 5-tuple hash of packet
+ There must be 2 or more integers listed, each with an op‐
+ tional weight, which is an integer within the range 1 ~
+ 65535. If weight is not specified, it defaults to 100. The
+ selection method is based on the 5-tuple hash of packet
header.
- Processing automatically moves on to the next table, as if
- next; were specified. The select action must be put as the
- last action of the logical flow when there are multiple
- actions (actions put after select will not take effect).
+ Processing automatically moves on to the next table, as if
+ next; were specified. The select action must be put as the
+ last action of the logical flow when there are multiple ac‐
+ tions (actions put after select will not take effect).
Example: reg8[16..31] = select(1=20, 2=30, 3=50);
handle_dhcpv6_reply;
This action is used to parse DHCPv6 replies from IPv6 Dele‐
- gation Router and managed IPv6 Prefix delegation state
- machine
+ gation Router and managed IPv6 Prefix delegation state ma‐
+ chine
R = chk_lb_hairpin();
- This action checks if the packet under consideration was
+ This action checks if the packet under consideration was
destined to a load balancer VIP and it is hairpinned, i.e.,
after load balancing the destination IP matches the source
IP. If it is so, then the 1-bit destination register R is
@@ -1943,13 +1952,13 @@
R = ct_snat_to_vip;
This action sends the packet through the SNAT zone to
change the source IP address of the packet to the load bal‐
- ancer VIP if the original destination IP was load balancer
- VIP and commits the connection. This action applies suc‐
+ ancer VIP if the original destination IP was load balancer
+ VIP and commits the connection. This action applies suc‐
cessfully only for the hairpinned traffic i.e if the action
chk_lb_hairpin returned success. This action doesn’t take
any arguments and it determines the SNAT IP internally. The
- packet is not automatically sent to the next table. The
- caller has to execute the next; action explicitly after
+ packet is not automatically sent to the next table. The
+ caller has to execute the next; action explicitly after
this action to advance the packet to the next stage.
R = check_in_port_sec();
@@ -1966,12 +1975,12 @@
R = check_out_port_sec();
This action checks if the packet under consideration passes
- the outport port security checks. If the packet fails the
- port security checks, then 1 is stored in the destination
- register R. Else 0 is stored. The port security values to
+ the outport port security checks. If the packet fails the
+ port security checks, then 1 is stored in the destination
+ register R. Else 0 is stored. The port security values to
check are retrieved from the the outport logical port.
- This action should be used in the egress logical switch
+ This action should be used in the egress logical switch
pipeline.
Example: reg8[0..7] = check_out_port_sec();
@@ -1979,15 +1988,15 @@
commit_ecmp_nh(ipv6);
Parameters: IPv4/IPv6 traffic.
- This action translates to an openflow "learn" action that
+ This action translates to an openflow "learn" action that
inserts two new flows in tables 76 and 77.
- · Match on the the 5-tuple and the expected next-hop
- mac address in table 76: nw_src=ip0, nw_dst=ip1,
+ • Match on the the 5-tuple and the expected next-hop
+ mac address in table 76: nw_src=ip0, nw_dst=ip1,
ip_proto,tp_src=l4_port0,
tp_dst=l4_port1,dl_src=ethaddr and set reg9[5].
- · Match on the 5-tuple in table 77: nw_src=ip1,
+ • Match on the 5-tuple in table 77: nw_src=ip1,
nw_dst=ip0, ip_proto, tp_src=l4_port1,
tp_dst=l4_port0 and set reg9[5] to 1
@@ -1996,87 +2005,91 @@
R = check_ecmp_nh_mac();
This action checks if the packet under consideration
- matches any flow in table 76. If it is so, then the 1-bit
+ matches any flow in table 76. If it is so, then the 1-bit
destination register R is set to 1.
R = check_ecmp_nh();
This action checks if the packet under consideration
- matches the any flow in table 77. If it is so, then the
+ matches the any flow in table 77. If it is so, then the
1-bit destination register R is set to 1.
- commit_lb_aff(vip, backend, proto, timeout); Parameters:
- load-balancer virtual ip:port vip, load-balancer backend
- ip:port backend, load-balancer protocol proto, affinity
+ commit_lb_aff(vip, backend, proto, timeout); Parameters:
+ load-balancer virtual ip:port vip, load-balancer backend
+ ip:port backend, load-balancer protocol proto, affinity
timeout timeout.
- This action translates to an openflow "learn" action that
+ This action translates to an openflow "learn" action that
inserts a new flow in table 78.
- · Match on the 4-tuple in table 78: nw_src=ip client,
- nw_dst=vip ip, ip_proto, tp_dst=vip port and set
- reg9[6] to 1, reg4 and reg8 to backend ip and port
- respectively. For IPv6 register xxreg1 is used to
+ • Match on the 4-tuple in table 78: nw_src=ip client,
+ nw_dst=vip ip, ip_proto, tp_dst=vip port and set
+ reg9[6] to 1, reg4 and reg8 to backend ip and port
+ respectively. For IPv6 register xxreg1 is used to
store the backend ip.
- This action is applied for new connections received by a
+ This action is applied for new connections received by a
specific load-balacer with affinity timeout configured.
R = chk_lb_aff();
This action checks if the packet under consideration
- matches any flow in table 78. If it is so, then the 1-bit
+ matches any flow in table 78. If it is so, then the 1-bit
destination register R is set to 1.
sample(probability=packets, ...)
- This action causes the matched traffic to be sampled using
- IPFIX protocol. More information about how per-flow IPFIX
- sampling works in OVS can be found in ovs-actions(7) and
+ This action causes the matched traffic to be sampled using
+ IPFIX protocol. More information about how per-flow IPFIX
+ sampling works in OVS can be found in ovs-actions(7) and
ovs-vswitchd.conf.db(5).
- In order to reliably identify each sampled packet when it
- is received by the IPFIX collector, this action sets the
- content of the ObservationDomainID and ObservationPointID
+ In order to reliably identify each sampled packet when it
+ is received by the IPFIX collector, this action sets the
+ content of the ObservationDomainID and ObservationPointID
IPFIX fields (see argument description below).
The following key-value arguments are supported:
probability=packets
- The number of sampled packets out of 65535. It must
+ The number of sampled packets out of 65535. It must
be greater or equal to 1.
collector_set=id
The unsigned 32-bit integer identifier of the sample
collector to send sampled packets to. It must match
- the value configured in the Flow_Sample_Collec‐
+ the value configured in the Flow_Sample_Collec‐‐
tor_Set Table in OVS. Defaults to 0.
obs_domain=id
An unsigned 8-bit integer that identifies the sam‐
pling application. It will be placed in the 8 most
significant bits of the ObservationDomainID field of
- IPFIX samples. The 24 less significant bits will be
- automatically filled in with the datapath key.
- Defaults to 0.
+ IPFIX samples. The 24 less significant bits will be
+ automatically filled in with the datapath key. De‐
+ faults to 0.
obs_point=id
- An unsigned 32-bit integer to be used as Obsserva‐
- tionPointID or the string @cookie to indicate that
- the first 32 bits of the Logical_Flow’s UUID shall
+ An unsigned 32-bit integer to be used as Obsserva‐‐
+ tionPointID or the string @cookie to indicate that
+ the first 32 bits of the Logical_Flow’s UUID shall
be used instead.
+ mac_cache_use;
+ This action resubmits to corresponding table which updates
+ the use statistics of MAC cache.
+
tags: map of string-string pairs
Key-value pairs that provide additional information to help ovn-
- controller processing the logical flow. Below are the tags used
+ controller processing the logical flow. Below are the tags used
by ovn-controller.
in_out_port
In the logical flow’s "match" column, if a logical port P
is compared with "inport" and the logical flow is on a
logical switch ingress pipeline, or if P is compared with
- "outport" and the logical flow is on a logical switch
- egress pipeline, and the expression is combined with
- other expressions (if any) using the operator &&, then
- the port P should be added as the value in this tag. If
- there are multiple logical ports meeting this criteria,
+ "outport" and the logical flow is on a logical switch
+ egress pipeline, and the expression is combined with
+ other expressions (if any) using the operator &&, then
+ the port P should be added as the value in this tag. If
+ there are multiple logical ports meeting this criteria,
one of them can be added. ovn-controller uses this infor‐
mation to skip parsing flows that are not needed on the
chassis. Failing to add the tag will affect efficiency,
@@ -2091,26 +2104,25 @@
external_ids : stage-hint: optional string, containing an uuid
UUID of a OVN_Northbound record that caused this logical flow to
- be created. Currently used only for attribute of logical flows
+ be created. Currently used only for attribute of logical flows
to northbound ACL records.
external_ids : source: optional string
- Source file and line number of the code that added this flow to
+ Source file and line number of the code that added this flow to
the pipeline.
Common Columns:
- The overall purpose of these columns is described under Common Columns
+ The overall purpose of these columns is described under Common Columns
at the beginning of this document.
external_ids: map of string-string pairs
-
Logical_DP_Group TABLE
- Each row in this table represents a group of logical datapaths refer‐
+ Each row in this table represents a group of logical datapaths refer‐
enced by the logical_dp_group column in the Logical_Flow table.
Summary:
- datapaths set of weak reference to Datapath_Bind‐
+ datapaths set of weak reference to Datapath_Bind‐‐
ings
Details:
@@ -2120,11 +2132,11 @@
Multicast_Group TABLE
The rows in this table define multicast groups of logical ports. Multi‐
cast groups allow a single packet transmitted over a tunnel to a hyper‐
- visor to be delivered to multiple VMs on that hypervisor, which uses
+ visor to be delivered to multiple VMs on that hypervisor, which uses
bandwidth more efficiently.
- Each row in this table defines a logical multicast group numbered tun‐
- nel_key within datapath, whose logical ports are listed in the ports
+ Each row in this table defines a logical multicast group numbered tun‐‐
+ nel_key within datapath, whose logical ports are listed in the ports
column.
Summary:
@@ -2138,15 +2150,15 @@
The logical datapath in which the multicast group resides.
tunnel_key: integer, in range 32,768 to 65,535
- The value used to designate this logical egress port in tunnel
- encapsulations. An index forces the key to be unique within the
- datapath. The unusual range ensures that multicast group IDs do
+ The value used to designate this logical egress port in tunnel
+ encapsulations. An index forces the key to be unique within the
+ datapath. The unusual range ensures that multicast group IDs do
not overlap with logical port IDs.
name: string
- The logical multicast group’s name. An index forces the name to
- be unique within the datapath. Logical flows in the ingress
- pipeline may output to the group just as for individual logical
+ The logical multicast group’s name. An index forces the name to
+ be unique within the datapath. Logical flows in the ingress
+ pipeline may output to the group just as for individual logical
ports, by assigning the group’s name to outport and executing an
output action.
@@ -2156,7 +2168,7 @@
names that begin with _MC_.
ports: set of weak reference to Port_Bindings
- The logical ports included in the multicast group. All of these
+ The logical ports included in the multicast group. All of these
ports must be in the datapath logical datapath (but the database
schema cannot enforce this).
@@ -2167,9 +2179,10 @@
Summary:
name string (must be unique within table)
- filter string, either from-lport or to-lport
+ filter string, one of both, from-lport, or
+ to-lport
sink string
- type string, either erspan or gre
+ type string, one of erspan, gre, or local
index integer
external_ids map of string-string pairs
@@ -2177,27 +2190,35 @@
name: string (must be unique within table)
Represents the name of the mirror.
- filter: string, either from-lport or to-lport
- The value of this field represents selection criteria of the
- mirror.
+ filter: string, one of both, from-lport, or to-lport
+ The value of this field represents selection criteria of the
+ mirror. to-lport mirrors the packets coming into logical port.
+ from-lport mirrors the packets going out of logical port. both
+ mirrors for both directions.
sink: string
- The value of this field represents the destination/sink of the
- mirror.
+ The value of this field represents the destination/sink of the
+ mirror. If the type is gre or erspan, the value indicates the
+ tunnel remote IP (either IPv4 or IPv6). For a type of local,
+ this field defines a local interface on the OVS integration
+ bridge to be used as the mirror destination. The interface must
+ possess external-ids:mirror-id that matches this string.
- type: string, either erspan or gre
- The value of this field represents the type of the tunnel used
- for sending the mirrored packets
+ type: string, one of erspan, gre, or local
+ The value of this field specifies the mirror type - gre, erspan
+ or local.
index: integer
- The value of this field represents the key/idx depending on the
- tunnel type configured
+ The value of this field represents the tunnel ID. If the config‐
+ ured tunnel type is gre, this field represents the GRE key value
+ and if the configured tunnel type is erspan it represents the
+ erspan_idx value. It is ignored if the type is local.
external_ids: map of string-string pairs
See External IDs at the beginning of this document.
Meter TABLE
- Each row in this table represents a meter that can be used for QoS or
+ Each row in this table represents a meter that can be used for QoS or
rate-limiting.
Summary:
@@ -2209,12 +2230,12 @@
name: string (must be unique within table)
A name for this meter.
- Names that begin with "__" (two underscores) are reserved for
+ Names that begin with "__" (two underscores) are reserved for
OVN internal use and should not be added manually.
unit: string, either kbps or pktps
- The unit for rate and burst_rate parameters in the bands entry.
- kbps specifies kilobits per second, and pktps specifies packets
+ The unit for rate and burst_rate parameters in the bands entry.
+ kbps specifies kilobits per second, and pktps specifies packets
per second.
bands: set of 1 or more Meter_Bands
@@ -2225,7 +2246,7 @@
Meter_Band TABLE
Each row in this table represents a meter band which specifies the rate
- above which the configured action should be applied. These bands are
+ above which the configured action should be applied. These bands are
referenced by the bands column in the Meter table.
Summary:
@@ -2240,30 +2261,29 @@
rate: integer, in range 1 to 4,294,967,295
The rate limit for this band, in kilobits per second or bits per
- second, depending on whether the parent Meter entry’s unit col‐
+ second, depending on whether the parent Meter entry’s unit col‐
umn specified kbps or pktps.
burst_size: integer, in range 0 to 4,294,967,295
- The maximum burst allowed for the band in kilobits or packets,
- depending on whether kbps or pktps was selected in the parent
- Meter entry’s unit column. If the size is zero, the switch is
+ The maximum burst allowed for the band in kilobits or packets,
+ depending on whether kbps or pktps was selected in the parent
+ Meter entry’s unit column. If the size is zero, the switch is
free to select some reasonable value depending on its configura‐
tion.
-
Datapath_Binding TABLE
Each row in this table represents a logical datapath, which implements
a logical pipeline among the ports in the Port_Binding table associated
- with it. In practice, the pipeline in a given logical datapath imple‐
+ with it. In practice, the pipeline in a given logical datapath imple‐
ments either a logical switch or a logical router.
- The main purpose of a row in this table is provide a physical binding
- for a logical datapath. A logical datapath does not have a physical
- location, so its physical binding information is limited: just tun‐
+ The main purpose of a row in this table is provide a physical binding
+ for a logical datapath. A logical datapath does not have a physical lo‐
+ cation, so its physical binding information is limited: just tun‐‐
nel_key. The rest of the data in this table does not affect packet for‐
warding.
Summary:
- tunnel_key integer, in range 1 to 16,777,215 (must
+ tunnel_key integer, in range 1 to 16,777,215 (must
be unique within table)
load_balancers set of uuids
OVN_Northbound Relationship:
@@ -2280,36 +2300,36 @@
external_ids map of string-string pairs
Details:
- tunnel_key: integer, in range 1 to 16,777,215 (must be unique within
+ tunnel_key: integer, in range 1 to 16,777,215 (must be unique within
table)
The tunnel key value to which the logical datapath is bound. The
- Tunnel Encapsulation section in ovn-architecture(7) describes
- how tunnel keys are constructed for each supported encapsula‐
+ Tunnel Encapsulation section in ovn-architecture(7) describes
+ how tunnel keys are constructed for each supported encapsula‐
tion.
load_balancers: set of uuids
- Not used anymore; kept for backwards compatibility of the
+ Not used anymore; kept for backwards compatibility of the
schema.
OVN_Northbound Relationship:
- Each row in Datapath_Binding is associated with some logical datapath.
- ovn-northd uses these keys to track the association of a logical data‐
+ Each row in Datapath_Binding is associated with some logical datapath.
+ ovn-northd uses these keys to track the association of a logical data‐
path with concepts in the OVN_Northbound database.
external_ids : logical-switch: optional string, containing an uuid
For a logical datapath that represents a logical switch,
- ovn-northd stores in this key the UUID of the corresponding Log‐
+ ovn-northd stores in this key the UUID of the corresponding Log‐‐
ical_Switch row in the OVN_Northbound database.
external_ids : logical-router: optional string, containing an uuid
For a logical datapath that represents a logical router,
- ovn-northd stores in this key the UUID of the corresponding Log‐
+ ovn-northd stores in this key the UUID of the corresponding Log‐‐
ical_Router row in the OVN_Northbound database.
external_ids : interconn-ts: optional string
- For a logical datapath that represents a logical switch that
- represents a transit switch for interconnection, ovn-northd
+ For a logical datapath that represents a logical switch that
+ represents a transit switch for interconnection, ovn-northd
stores in this key the value of the same interconn-ts key of the
external_ids column of the corresponding Logical_Switch row in
the OVN_Northbound database.
@@ -2329,32 +2349,31 @@
Common Columns:
- The overall purpose of these columns is described under Common Columns
+ The overall purpose of these columns is described under Common Columns
at the beginning of this document.
external_ids: map of string-string pairs
-
Port_Binding TABLE
- Each row in this table binds a logical port to a realization. For most
- logical ports, this means binding to some physical location, for exam‐
- ple by binding a logical port to a VIF that belongs to a VM running on
- a particular hypervisor. Other logical ports, such as logical patch
- ports, can be realized without a specific physical location, but their
+ Each row in this table binds a logical port to a realization. For most
+ logical ports, this means binding to some physical location, for exam‐
+ ple by binding a logical port to a VIF that belongs to a VM running on
+ a particular hypervisor. Other logical ports, such as logical patch
+ ports, can be realized without a specific physical location, but their
bindings are still expressed through rows in this table.
- For every Logical_Switch_Port record in OVN_Northbound database,
- ovn-northd creates a record in this table. ovn-northd populates and
- maintains every column except the chassis and virtual_parent columns,
+ For every Logical_Switch_Port record in OVN_Northbound database,
+ ovn-northd creates a record in this table. ovn-northd populates and
+ maintains every column except the chassis and virtual_parent columns,
which it leaves empty in new records.
ovn-controller/ovn-controller-vtep populates the chassis column for the
records that identify the logical ports that are located on its hyper‐
visor/gateway, which ovn-controller/ovn-controller-vtep in turn finds
out by monitoring the local hypervisor’s Open_vSwitch database, which
- identifies logical ports via the conventions described in Integra‐
+ identifies logical ports via the conventions described in Integra‐‐
tionGuide.rst. (The exceptions are for Port_Binding records with type
- of l3gateway, whose locations are identified by ovn-northd via the
- options:l3gateway-chassis column in this table. ovn-controller is still
+ of l3gateway, whose locations are identified by ovn-northd via the op‐‐
+ tions:l3gateway-chassis column in this table. ovn-controller is still
responsible to populate the chassis column.)
ovn-controller also populates the virtual_parent column of records
@@ -2365,7 +2384,7 @@
resources hosted on the chassis are equally unreachable regardless of
whether their rows are present.) To handle the case where a VM is shut
down abruptly on one chassis, then brought up again on a different one,
- ovn-controller/ovn-controller-vtep must overwrite the chassis column
+ ovn-controller/ovn-controller-vtep must overwrite the chassis column
with new information.
Summary:
@@ -2419,7 +2438,9 @@
options : qos_min_rate optional string
options : qos_max_rate optional string
options : qos_burst optional string
- options : qdisc_queue_id optional string, containing an integer,
+ options : qos_physical_network
+ optional string
+ options : qdisc_queue_id optional string, containing an integer,
in range 1 to 61,440
Distributed Gateway Port Options:
options : chassis-redirect-port
@@ -2445,17 +2466,17 @@
The logical datapath to which the logical port belongs.
logical_port: string (must be unique within table)
- A logical port. For a logical switch port, this is taken from
+ A logical port. For a logical switch port, this is taken from
name in the OVN_Northbound database’s Logical_Switch_Port table.
For a logical router port, this is taken from name in the
OVN_Northbound database’s Logical_Router_port table. (This means
- that logical switch ports and router port names must not share
+ that logical switch ports and router port names must not share
names in an OVN deployment.) OVN does not prescribe a particular
format for the logical port ID.
encap: optional weak reference to Encap
Points to preferred encapsulation configuration to transmit log‐
- ical dataplane packets to this chassis. The entry is reference
+ ical dataplane packets to this chassis. The entry is reference
to a Encap record.
additional_encap: set of weak reference to Encaps
@@ -2468,25 +2489,25 @@
umn. This is the meaning for each type
(empty string)
- The physical location of the logical port. To success‐
- fully identify a chassis, this column must be a Chassis
+ The physical location of the logical port. To success‐
+ fully identify a chassis, this column must be a Chassis
record. This is populated by ovn-controller.
- vtep The physical location of the hardware_vtep gateway. To
- successfully identify a chassis, this column must be a
+ vtep The physical location of the hardware_vtep gateway. To
+ successfully identify a chassis, this column must be a
Chassis record. This is populated by ovn-controller-vtep.
localnet
- Always empty. A localnet port is realized on every chas‐
- sis that has connectivity to the corresponding physical
+ Always empty. A localnet port is realized on every chas‐
+ sis that has connectivity to the corresponding physical
network.
localport
- Always empty. A localport port is present on every chas‐
+ Always empty. A localport port is present on every chas‐
sis.
l3gateway
- The physical location of the L3 gateway. To successfully
+ The physical location of the L3 gateway. To successfully
identify a chassis, this column must be a Chassis record.
This is populated by ovn-controller based on the value of
the options:l3gateway-chassis column in this table.
@@ -2505,19 +2526,19 @@
gateway_chassis: set of Gateway_Chassises
A list of Gateway_Chassis.
- This should only be populated for ports with type set to chas‐
+ This should only be populated for ports with type set to chas‐‐
sisredirect. This column defines the list of chassis used as
gateways where traffic will be redirected through.
ha_chassis_group: optional HA_Chassis_Group
- This should only be populated for ports with type set to chas‐
+ This should only be populated for ports with type set to chas‐‐
sisredirect. This column defines the HA chassis group with a
list of HA chassis used as gateways where traffic will be redi‐
rected through.
up: optional boolean
This is set to true whenever all OVS flows required by this
- Port_Binding have been installed. This is populated by ovn-con‐
+ Port_Binding have been installed. This is populated by ovn-con‐‐
troller.
tunnel_key: integer, in range 1 to 32,767
@@ -2529,17 +2550,17 @@
mac: set of strings
This column is a misnomer as it may contain MAC addresses and IP
- addresses. It is copied from the addresses column in the Logi‐
+ addresses. It is copied from the addresses column in the Logi‐‐
cal_Switch_Port table in the Northbound database. It follows the
same format as that column.
port_security: set of strings
- This column controls the addresses from which the host attached
- to the logical port (``the host’’) is allowed to send packets
+ This column controls the addresses from which the host attached
+ to the logical port (``the host’’) is allowed to send packets
and to which it is allowed to receive packets. If this column is
empty, all addresses are permitted.
- It is copied from the port_security column in the Logi‐
+ It is copied from the port_security column in the Logi‐‐
cal_Switch_Port table in the Northbound database. It follows the
same format as that column.
@@ -2551,7 +2572,7 @@
(empty string)
VM (or VIF) interface.
- patch One of a pair of logical ports that act as if connected
+ patch One of a pair of logical ports that act as if connected
by a patch cable. Useful for connecting two logical data‐
paths, e.g. to connect a logical router to a logical
switch or to another logical router.
@@ -2559,79 +2580,79 @@
l3gateway
One of a pair of logical ports that act as if connected
by a patch cable across multiple chassis. Useful for con‐
- necting a logical switch with a Gateway router (which is
+ necting a logical switch with a Gateway router (which is
only resident on a particular chassis).
localnet
- A connection to a locally accessible network from
+ A connection to a locally accessible network from
ovn-controller instances that have a corresponding bridge
mapping. A logical switch can have multiple localnet
ports attached. This type is used to model direct connec‐
- tivity to existing networks. In this case, each chassis
- should have a mapping for one of the physical networks
- only. Note: nothing said above implies that a chassis
- cannot be plugged to multiple physical networks as long
+ tivity to existing networks. In this case, each chassis
+ should have a mapping for one of the physical networks
+ only. Note: nothing said above implies that a chassis
+ cannot be plugged to multiple physical networks as long
as they belong to different switches.
localport
- A connection to a local VIF. Traffic that arrives on a
- localport is never forwarded over a tunnel to another
- chassis. These ports are present on every chassis and
- have the same address in all of them. This is used to
- model connectivity to local services that run on every
+ A connection to a local VIF. Traffic that arrives on a
+ localport is never forwarded over a tunnel to another
+ chassis. These ports are present on every chassis and
+ have the same address in all of them. This is used to
+ model connectivity to local services that run on every
hypervisor.
l2gateway
- An L2 connection to a physical network. The chassis this
- Port_Binding is bound to will serve as an L2 gateway to
+ An L2 connection to a physical network. The chassis this
+ Port_Binding is bound to will serve as an L2 gateway to
the network named by options:network_name.
- vtep A port to a logical switch on a VTEP gateway chassis. In
- order to get this port correctly recognized by the OVN
- controller, the options:vtep-physical-switch and
- options:vtep-logical-switch must also be defined.
+ vtep A port to a logical switch on a VTEP gateway chassis. In
+ order to get this port correctly recognized by the OVN
+ controller, the options:vtep-physical-switch and op‐‐
+ tions:vtep-logical-switch must also be defined.
chassisredirect
- A logical port that represents a particular instance,
- bound to a specific chassis, of an otherwise distributed
- parent port (e.g. of type patch). A chassisredirect port
- should never be used as an inport. When an ingress pipe‐
- line sets the outport, it may set the value to a logical
- port of type chassisredirect. This will cause the packet
- to be directed to a specific chassis to carry out the
- egress pipeline. At the beginning of the egress pipeline,
- the outport will be reset to the value of the distributed
- port.
+ A logical port that represents a particular instance,
+ bound to a specific chassis, of an otherwise distributed
+ parent port (e.g. of type patch). A chassisredirect port
+ should never be used as an inport. When an ingress
+ pipeline sets the outport, it may set the value to a log‐
+ ical port of type chassisredirect. This will cause the
+ packet to be directed to a specific chassis to carry out
+ the egress pipeline. At the beginning of the egress
+ pipeline, the outport will be reset to the value of the
+ distributed port.
virtual
- Represents a logical port with an virtual ip. This vir‐
- tual ip can be configured on a logical port (which is
- referred as virtual parent).
+ Represents a logical port with an virtual ip. This vir‐‐
+ tual ip can be configured on a logical port (which is re‐
+ ferred as virtual parent).
requested_chassis: optional weak reference to Chassis
- This column exists so that the ovn-controller can effectively
- monitor all Port_Binding records destined for it, and is a sup‐
- plement to the options:requested-chassis option. The option is
- still required so that the ovn-controller can check the CMS
- intent when the chassis pointed to does not currently exist,
- which for example occurs when the ovn-controller is stopped
- without passing the -restart argument. This column must be a
- Chassis record. This is populated by ovn-northd when the
- options:requested-chassis is defined and contains a string
- matching the name or hostname of an existing chassis. See also
- requested_additional_chassis.
+ This column exists so that the ovn-controller can effectively
+ monitor all Port_Binding records destined for it, and is a sup‐
+ plement to the options:requested-chassis option. The option is
+ still required so that the ovn-controller can check the CMS in‐
+ tent when the chassis pointed to does not currently exist, which
+ for example occurs when the ovn-controller is stopped without
+ passing the -restart argument. This column must be a Chassis
+ record. This is populated by ovn-northd when the options:re‐‐
+ quested-chassis is defined and contains a string matching the
+ name or hostname of an existing chassis. See also requested_ad‐‐
+ ditional_chassis.
requested_additional_chassis: set of weak reference to Chassis
This column exists so that the ovn-controller can effectively
monitor all Port_Binding records destined for it, and is a sup‐
plement to the options:requested-chassis option when multiple
chassis are listed. This column must be a list of Chassis
- records. This is populated by ovn-northd when the
- options:requested-chassis is defined as a list of chassis names
- or hostnames. See also requested_chassis.
+ records. This is populated by ovn-northd when the options:re‐‐
+ quested-chassis is defined as a list of chassis names or host‐
+ names. See also requested_chassis.
mirror_rules: set of weak reference to Mirrors
- Mirror rules that apply to the port binding. Please see the Mir‐
+ Mirror rules that apply to the port binding. Please see the Mir‐‐
ror table.
Patch Options:
@@ -2639,14 +2660,14 @@
These options apply to logical ports with type of patch.
options : peer: optional string
- The logical_port in the Port_Binding record for the other side
- of the patch. The named logical_port must specify this logi‐
- cal_port in its own peer option. That is, the two patch logical
+ The logical_port in the Port_Binding record for the other side
+ of the patch. The named logical_port must specify this logi‐‐
+ cal_port in its own peer option. That is, the two patch logical
ports must have reversed logical_port and peer values.
nat_addresses: set of strings
- MAC address followed by a list of SNAT and DNAT external IP
- addresses, followed by is_chassis_resident("lport"), where lport
+ MAC address followed by a list of SNAT and DNAT external IP ad‐
+ dresses, followed by is_chassis_resident("lport"), where lport
is the name of a logical port on the same chassis where the cor‐
responding NAT rules are applied. This is used to send gratu‐
itous ARPs for SNAT and DNAT external IP addresses via localnet,
@@ -2662,10 +2683,10 @@
These options apply to logical ports with type of l3gateway.
options : peer: optional string
- The logical_port in the Port_Binding record for the other side
- of the ’l3gateway’ port. The named logical_port must specify
- this logical_port in its own peer option. That is, the two
- ’l3gateway’ logical ports must have reversed logical_port and
+ The logical_port in the Port_Binding record for the other side
+ of the ’l3gateway’ port. The named logical_port must specify
+ this logical_port in its own peer option. That is, the two
+ ’l3gateway’ logical ports must have reversed logical_port and
peer values.
options : l3gateway-chassis: optional string
@@ -2674,10 +2695,10 @@
nat_addresses: set of strings
MAC address of the l3gateway port followed by a list of SNAT and
DNAT external IP addresses. This is used to send gratuitous ARPs
- for SNAT and DNAT external IP addresses via localnet. Example:
- 80:fa:5b:06:72:b7 158.36.44.22 158.36.44.24. This would result
- in generation of gratuitous ARPs for IP addresses 158.36.44.22
- and 158.36.44.24 with a MAC address of 80:fa:5b:06:72:b7. This
+ for SNAT and DNAT external IP addresses via localnet. Example:
+ 80:fa:5b:06:72:b7 158.36.44.22 158.36.44.24. This would result
+ in generation of gratuitous ARPs for IP addresses 158.36.44.22
+ and 158.36.44.24 with a MAC address of 80:fa:5b:06:72:b7. This
is used in OVS version 2.8 and later versions.
Localnet Options:
@@ -2685,29 +2706,29 @@
These options apply to logical ports with type of localnet.
options : network_name: optional string
- Required. ovn-controller uses the configuration entry
+ Required. ovn-controller uses the configuration entry
ovn-bridge-mappings to determine how to connect to this network.
ovn-bridge-mappings is a list of network names mapped to a local
- OVS bridge that provides access to that network. An example of
+ OVS bridge that provides access to that network. An example of
configuring ovn-bridge-mappings would be: .IP
$ ovs-vsctl set open . external-ids:ovn-bridge-mappings=physnet1:br-eth0,physnet2:br-eth1
- When a logical switch has a localnet port attached, every chas‐
- sis that may have a local vif attached to that logical switch
- must have a bridge mapping configured to reach that localnet.
- Traffic that arrives on a localnet port is never forwarded over
- a tunnel to another chassis. If there are multiple localnet
- ports in a logical switch, each chassis should only have a sin‐
- gle bridge mapping for one of the physical networks. Note: In
- case of multiple localnet ports, to provide interconnectivity
- between all VIFs located on different chassis with different
- fabric connectivity, the fabric should implement some form of
+ When a logical switch has a localnet port attached, every chas‐
+ sis that may have a local vif attached to that logical switch
+ must have a bridge mapping configured to reach that localnet.
+ Traffic that arrives on a localnet port is never forwarded over
+ a tunnel to another chassis. If there are multiple localnet
+ ports in a logical switch, each chassis should only have a sin‐
+ gle bridge mapping for one of the physical networks. Note: In
+ case of multiple localnet ports, to provide interconnectivity
+ between all VIFs located on different chassis with different
+ fabric connectivity, the fabric should implement some form of
routing between the segments.
tag: optional integer, in range 1 to 4,095
- If set, indicates that the port represents a connection to a
- specific VLAN on a locally accessible network. The VLAN ID is
- used to match incoming traffic and is also added to outgoing
+ If set, indicates that the port represents a connection to a
+ specific VLAN on a locally accessible network. The VLAN ID is
+ used to match incoming traffic and is also added to outgoing
traffic.
L2 Gateway Options:
@@ -2715,10 +2736,10 @@
These options apply to logical ports with type of l2gateway.
options : network_name: optional string
- Required. ovn-controller uses the configuration entry
+ Required. ovn-controller uses the configuration entry
ovn-bridge-mappings to determine how to connect to this network.
ovn-bridge-mappings is a list of network names mapped to a local
- OVS bridge that provides access to that network. An example of
+ OVS bridge that provides access to that network. An example of
configuring ovn-bridge-mappings would be: .IP
$ ovs-vsctl set open . external-ids:ovn-bridge-mappings=physnet1:br-eth0,physnet2:br-eth1
@@ -2731,8 +2752,8 @@
tag: optional integer, in range 1 to 4,095
If set, indicates that the gateway is connected to a specific
- VLAN on the physical network. The VLAN ID is used to match
- incoming traffic and is also added to outgoing traffic.
+ VLAN on the physical network. The VLAN ID is used to match in‐
+ coming traffic and is also added to outgoing traffic.
VTEP Options:
@@ -2751,10 +2772,10 @@
options : requested-chassis: optional string
If set, identifies a specific chassis (by name or hostname) that
- is allowed to bind this port. Using this option will prevent
- thrashing between two chassis trying to bind the same port dur‐
- ing a live migration. It can also prevent similar thrashing due
- to a mis-configuration, if a port is accidentally created on
+ is allowed to bind this port. Using this option will prevent
+ thrashing between two chassis trying to bind the same port dur‐
+ ing a live migration. It can also prevent similar thrashing due
+ to a mis-configuration, if a port is accidentally created on
more than one chassis.
If set to a comma separated list, the first entry identifies the
@@ -2770,8 +2791,8 @@
options : activation-strategy: optional string
If used with multiple chassis set in requested-chassis, speci‐
- fies an activation strategy for all additional chassis. By
- default, no activation strategy is used, meaning additional port
+ fies an activation strategy for all additional chassis. By de‐
+ fault, no activation strategy is used, meaning additional port
locations are immediately available for use. When set to "rarp",
the port is blocked for ingress and egress communication until a
RARP packet is sent from a new location. The "rarp" strategy is
@@ -2791,15 +2812,19 @@
sent from this interface, in bit/s.
options : qos_max_rate: optional string
- If set, indicates the maximum rate for data sent from this
- interface, in bit/s. The traffic will be shaped according to
- this limit.
+ If set, indicates the maximum rate for data sent from this in‐
+ terface, in bit/s. The traffic will be shaped according to this
+ limit.
options : qos_burst: optional string
If set, indicates the maximum burst size for data sent from this
interface, in bits.
- options : qdisc_queue_id: optional string, containing an integer, in
+ options : qos_physical_network: optional string
+ If set, indicates the name of the egress network name where
+ traffic shaping will be applied.
+
+ options : qdisc_queue_id: optional string, containing an integer, in
range 1 to 61,440
Indicates the queue number on the physical device. This is same
as the queue_id used in OpenFlow in struct ofp_action_enqueue.
@@ -2846,7 +2871,7 @@
Identifies the VLAN tag in the network traffic associated with
that container’s network interface.
- This column is used for a different purpose when type is local‐
+ This column is used for a different purpose when type is local‐‐
net (see Localnet Options, above) or l2gateway (see L2 Gateway
Options, above).
@@ -2856,7 +2881,7 @@
This column is set by ovn-controller with one of the value from
the options:virtual-parents in the OVN_Northbound database’s
Logical_Switch_Port table when the OVN action bind_vport is exe‐
- cuted. ovn-controller also sets the chassis column when it exe‐
+ cuted. ovn-controller also sets the chassis column when it exe‐
cutes this action with its chassis id.
ovn-controller sets this column only if the type is "virtual".
@@ -2864,11 +2889,11 @@
Naming:
external_ids : name: optional string
- For a logical switch port, ovn-northd copies this from exter‐
- nal_ids:neutron:port_name in the Logical_Switch_Port table in
+ For a logical switch port, ovn-northd copies this from exter‐‐
+ nal_ids:neutron:port_name in the Logical_Switch_Port table in
the OVN_Northbound database, if it is a nonempty string.
- For a logical switch port, ovn-northd does not currently set
+ For a logical switch port, ovn-northd does not currently set
this key.
Common Columns:
@@ -2876,54 +2901,54 @@
external_ids: map of string-string pairs
See External IDs at the beginning of this document.
- The ovn-northd program populates this column with all entries
- into the external_ids column of the Logical_Switch_Port and Log‐
+ The ovn-northd program populates this column with all entries
+ into the external_ids column of the Logical_Switch_Port and Log‐‐
ical_Router_Port tables of the OVN_Northbound database.
MAC_Binding TABLE
Each row in this table specifies a binding from an IP address to an
Ethernet address that has been discovered through ARP (for IPv4) or
neighbor discovery (for IPv6). This table is primarily used to discover
- bindings on physical networks, because IP-to-MAC bindings for virtual
+ bindings on physical networks, because IP-to-MAC bindings for virtual
machines are usually populated statically into the Port_Binding table.
- This table expresses a functional relationship: MAC_Binding(logi‐
+ This table expresses a functional relationship: MAC_Binding(logi‐‐
cal_port, ip) = mac.
- In outline, the lifetime of a logical router’s MAC binding looks like
+ In outline, the lifetime of a logical router’s MAC binding looks like
this:
- 1. On hypervisor 1, a logical router determines that a packet
- should be forwarded to IP address A on one of its router
- ports. It uses its logical flow table to determine that A
- lacks a static IP-to-MAC binding and the get_arp action to
+ 1. On hypervisor 1, a logical router determines that a packet
+ should be forwarded to IP address A on one of its router
+ ports. It uses its logical flow table to determine that A
+ lacks a static IP-to-MAC binding and the get_arp action to
determine that it lacks a dynamic IP-to-MAC binding.
- 2. Using an OVN logical arp action, the logical router gener‐
- ates and sends a broadcast ARP request to the router port.
+ 2. Using an OVN logical arp action, the logical router gener‐
+ ates and sends a broadcast ARP request to the router port.
It drops the IP packet.
- 3. The logical switch attached to the router port delivers the
- ARP request to all of its ports. (It might make sense to
- deliver it only to ports that have no static IP-to-MAC bind‐
+ 3. The logical switch attached to the router port delivers the
+ ARP request to all of its ports. (It might make sense to de‐
+ liver it only to ports that have no static IP-to-MAC bind‐
ings, but this could also be surprising behavior.)
- 4. A host or VM on hypervisor 2 (which might be the same as
- hypervisor 1) attached to the logical switch owns the IP
- address in question. It composes an ARP reply and unicasts
- it to the logical router port’s Ethernet address.
+ 4. A host or VM on hypervisor 2 (which might be the same as hy‐
+ pervisor 1) attached to the logical switch owns the IP ad‐
+ dress in question. It composes an ARP reply and unicasts it
+ to the logical router port’s Ethernet address.
- 5. The logical switch delivers the ARP reply to the logical
+ 5. The logical switch delivers the ARP reply to the logical
router port.
- 6. The logical router flow table executes a put_arp action. To
- record the IP-to-MAC binding, ovn-controller adds a row to
+ 6. The logical router flow table executes a put_arp action. To
+ record the IP-to-MAC binding, ovn-controller adds a row to
the MAC_Binding table.
- 7. On hypervisor 1, ovn-controller receives the updated
+ 7. On hypervisor 1, ovn-controller receives the updated
MAC_Binding table from the OVN southbound database. The next
- packet destined to A through the logical router is sent
- directly to the bound Ethernet address.
+ packet destined to A through the logical router is sent di‐
+ rectly to the bound Ethernet address.
Summary:
logical_port string
@@ -2950,17 +2975,17 @@
The logical datapath to which the logical port belongs.
DHCP_Options TABLE
- Each row in this table stores the DHCP Options supported by native OVN
- DHCP. ovn-northd populates this table with the supported DHCP options.
- ovn-controller looks up this table to get the DHCP codes of the DHCP
- options defined in the "put_dhcp_opts" action. Please refer to the RFC
- 2132 "https://tools.ietf.org/html/rfc2132" for the possible list of
+ Each row in this table stores the DHCP Options supported by native OVN
+ DHCP. ovn-northd populates this table with the supported DHCP options.
+ ovn-controller looks up this table to get the DHCP codes of the DHCP
+ options defined in the "put_dhcp_opts" action. Please refer to the RFC
+ 2132 "https://tools.ietf.org/html/rfc2132" for the possible list of
DHCP options that can be defined here.
Summary:
name string
code integer, in range 0 to 254
- type string, one of bool, domains, host_id,
+ type string, one of bool, domains, host_id,
ipv4, static_routes, str, uint16, uint32,
or uint8
@@ -2975,12 +3000,12 @@
Example. code=3
- type: string, one of bool, domains, host_id, ipv4, static_routes, str,
+ type: string, one of bool, domains, host_id, ipv4, static_routes, str,
uint16, uint32, or uint8
Data type of the DHCP option code.
value: bool
- This indicates that the value of the DHCP option is a
+ This indicates that the value of the DHCP option is a
bool.
Example. "name=ip_forward_enable", "code=19",
@@ -2989,7 +3014,7 @@
put_dhcp_opts(..., ip_forward_enable = 1,...)
value: uint8
- This indicates that the value of the DHCP option is an
+ This indicates that the value of the DHCP option is an
unsigned int8 (8 bits)
Example. "name=default_ttl", "code=23", "type=uint8".
@@ -2997,7 +3022,7 @@
put_dhcp_opts(..., default_ttl = 50,...)
value: uint16
- This indicates that the value of the DHCP option is an
+ This indicates that the value of the DHCP option is an
unsigned int16 (16 bits).
Example. "name=mtu", "code=26", "type=uint16".
@@ -3005,7 +3030,7 @@
put_dhcp_opts(..., mtu = 1450,...)
value: uint32
- This indicates that the value of the DHCP option is an
+ This indicates that the value of the DHCP option is an
unsigned int32 (32 bits).
Example. "name=lease_time", "code=51", "type=uint32".
@@ -3013,7 +3038,7 @@
put_dhcp_opts(..., lease_time = 86400,...)
value: ipv4
- This indicates that the value of the DHCP option is an
+ This indicates that the value of the DHCP option is an
IPv4 address or addresses.
Example. "name=router", "code=3", "type=ipv4".
@@ -3047,24 +3072,23 @@
Example. "name=tftp_server", "code=66", "type=host_id".
value: domains
- This indicates that the value of the DHCP option is a
- domain name or a comma separated list of domain names.
-
- Example. "name=domain_search_list", "code=119",
- "type=domains".
+ This indicates that the value of the DHCP option is a do‐
+ main name or a comma separated list of domain names.
+ Example. "name=domain_search_list", "code=119", "type=do‐
+ mains".
DHCPv6_Options TABLE
Each row in this table stores the DHCPv6 Options supported by native
OVN DHCPv6. ovn-northd populates this table with the supported DHCPv6
options. ovn-controller looks up this table to get the DHCPv6 codes of
the DHCPv6 options defined in the put_dhcpv6_opts action. Please refer
- to RFC 3315 and RFC 3646 for the list of DHCPv6 options that can be
- defined here.
+ to RFC 3315 and RFC 3646 for the list of DHCPv6 options that can be de‐
+ fined here.
Summary:
name string
code integer, in range 0 to 254
- type string, one of ipv6, mac, or str
+ type string, one of domain, ipv6, mac, or str
Details:
name: string
@@ -3073,16 +3097,16 @@
Example. name="ia_addr"
code: integer, in range 0 to 254
- DHCPv6 option code for the DHCPv6 option as defined in the
- appropriate RFC.
+ DHCPv6 option code for the DHCPv6 option as defined in the ap‐
+ propriate RFC.
Example. code=3
- type: string, one of ipv6, mac, or str
+ type: string, one of domain, ipv6, mac, or str
Data type of the DHCPv6 option code.
value: ipv6
- This indicates that the value of the DHCPv6 option is an
+ This indicates that the value of the DHCPv6 option is an
IPv6 address(es).
Example. "name=ia_addr", "code=5", "type=ipv6".
@@ -3090,7 +3114,7 @@
put_dhcpv6_opts(..., ia_addr = ae70::4,...)
value: str
- This indicates that the value of the DHCPv6 option is a
+ This indicates that the value of the DHCPv6 option is a
string.
Example. "name=domain_search", "code=24", "type=str".
@@ -3098,22 +3122,21 @@
put_dhcpv6_opts(..., domain_search = ovn.domain,...)
value: mac
- This indicates that the value of the DHCPv6 option is a
+ This indicates that the value of the DHCPv6 option is a
MAC address.
Example. "name=server_id", "code=2", "type=mac".
put_dhcpv6_opts(..., server_id = 01:02:03:04L05:06,...)
-
Connection TABLE
- Configuration for a database connection to an Open vSwitch database
+ Configuration for a database connection to an Open vSwitch database
(OVSDB) client.
- This table primarily configures the Open vSwitch database server
+ This table primarily configures the Open vSwitch database server
(ovsdb-server).
- The Open vSwitch database server can initiate and maintain active con‐
- nections to remote clients. It can also listen for database connec‐
+ The Open vSwitch database server can initiate and maintain active con‐
+ nections to remote clients. It can also listen for database connec‐
tions.
Summary:
@@ -3127,17 +3150,17 @@
Status:
is_connected boolean
status : last_error optional string
- status : state optional string, one of ACTIVE, BACKOFF,
+ status : state optional string, one of ACTIVE, BACKOFF,
CONNECTING, IDLE, or VOID
- status : sec_since_connect optional string, containing an integer,
+ status : sec_since_connect optional string, containing an integer,
at least 0
status : sec_since_disconnect
- optional string, containing an integer,
+ 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,
+ status : n_connections optional string, containing an integer,
at least 2
status : bound_port optional string, containing an integer
Common Columns:
@@ -3153,38 +3176,38 @@
The following connection methods are currently supported:
ssl:host[:port]
- The specified SSL port on the given host, which can
- either be a DNS name (if built with unbound library) or
- an IP address. A valid SSL configuration must be provided
- when this form is used, this configuration can be speci‐
+ The specified SSL port on the given host, which can ei‐
+ ther 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 speci‐
fied 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
+ 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 given host, which can
- either be a DNS name (if built with unbound library) or
- an IP address (IPv4 or IPv6). If host is an IPv6 address,
+ The specified TCP port on the given host, which can ei‐
+ ther be a DNS name (if built with unbound library) or an
+ IP address (IPv4 or IPv6). If host is an IPv6 address,
wrap it in square brackets, e.g. tcp:[::1]:6640.
If port is not specified, it defaults to 6640.
pssl:[port][:host]
- Listens for SSL connections on the specified TCP port.
- Specify 0 for port to have the kernel automatically
- choose an available port. If host, which can either be a
- DNS name (if built with unbound library) or an IP
- address, is specified, then connections are restricted to
- the resolved or specified local IP address (either IPv4
- or IPv6 address). If host is an IPv6 address, wrap in
- square brackets, e.g. pssl:6640:[::1]. If host is not
- specified then it listens only on IPv4 (but not IPv6)
- addresses. A valid SSL configuration must be provided
- when this form is used, this can be specified either via
- command-line options or the SSL table.
+ 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 ad‐
+ dress, is specified, then connections are restricted to
+ the resolved or specified local IP address (either IPv4
+ or IPv6 address). If host is an IPv6 address, wrap in
+ square brackets, e.g. pssl:6640:[::1]. If host is not
+ specified then it listens only on IPv4 (but not IPv6) ad‐
+ dresses. A valid SSL configuration must be provided when
+ this form is used, this can be specified either via com‐
+ mand-line options or the SSL table.
If port is not specified, it defaults to 6640.
@@ -3194,13 +3217,13 @@
ptcp:[port][:host]
Listens for connections on the specified TCP port. Spec‐
ify 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.
+ 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 re‐
+ solved 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.
@@ -3217,17 +3240,17 @@
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.
+ Maximum number of milliseconds to wait between connection at‐
+ tempts. 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 recon‐
- nect. Default is implementation-specific. A value of 0 disables
+ 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 recon‐
+ nect. Default is implementation-specific. A value of 0 disables
inactivity probes.
Status:
@@ -3236,12 +3259,12 @@
in the status columns may be updated depends on the target type.
When target specifies a connection method that listens for inbound con‐
- nections (e.g. ptcp: or punix:), both n_connections and is_connected
+ nections (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 omit‐
+ 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 omit‐
ted.
is_connected: boolean
@@ -3252,7 +3275,7 @@
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,
+ status : state: optional string, one of ACTIVE, BACKOFF, CONNECTING,
IDLE, or VOID
The state of the connection to the manager:
@@ -3268,58 +3291,57 @@
IDLE Connection is idle. Waiting for response to keep-alive.
- These values may change in the future. They are provided only
+ These values may change in the future. They are provided only
for human consumption.
- status : sec_since_connect: optional string, containing an integer, at
+ 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,
+ 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 dis‐
+ The amount of time since this client last disconnected from the
+ database (in seconds). Value is empty if client has never dis‐
connected.
status : locks_held: optional string
- Space-separated list of the names of OVSDB locks that the con‐
- nection holds. Omitted if the connection does not hold any
+ Space-separated list of the names of OVSDB locks that the con‐
+ nection 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 con‐
- nection is currently waiting to acquire. Omitted if the connec‐
+ Space-separated list of the names of OVSDB locks that the con‐
+ nection is currently waiting to acquire. Omitted if the connec‐
tion is not waiting for any locks.
status : locks_lost: optional string
- Space-separated list of the names of OVSDB locks that the con‐
- nection has had stolen by another OVSDB client. Omitted if no
+ Space-separated list of the names of OVSDB locks that the con‐
+ nection 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
+ 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 con‐
+ When target specifies a connection method that listens for in‐
+ bound connections (e.g. ptcp: or pssl:) and more than one con‐
nection 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
+ 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
+ The overall purpose of these columns is described under Common Columns
at the beginning of this document.
external_ids: map of string-string pairs
other_config: map of string-string pairs
-
SSL TABLE
SSL configuration for ovn-sb database access.
@@ -3335,11 +3357,11 @@
Details:
private_key: string
- Name of a PEM file containing the private key used as the
+ 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 cer‐
+ Name of a PEM file containing a certificate, signed by the cer‐
tificate authority (CA) used by the controller and manager, that
certifies the switch’s private key, identifying a trustworthy
switch.
@@ -3351,8 +3373,8 @@
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
+ save it to the named PEM file. If it is successful, it will im‐
+ mediately 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
@@ -3360,28 +3382,28 @@
ping.
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.
+ List of SSL protocols to be enabled for SSL connections. The de‐
+ fault when this option is omitted is TLSv1,TLSv1.1,TLSv1.2.
ssl_ciphers: string
- List of ciphers (in OpenSSL cipher string format) to be sup‐
- ported for SSL connections. The default when this option is
+ List of ciphers (in OpenSSL cipher string format) to be sup‐
+ ported 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
+ The overall purpose of these columns is described under Common Columns
at the beginning of this document.
external_ids: map of string-string pairs
-
DNS TABLE
- Each row in this table stores the DNS records. The OVN action
+ Each row in this table stores the DNS records. The OVN action
dns_lookup uses this table for DNS resolution.
Summary:
records map of string-string pairs
datapaths set of 1 or more Datapath_Bindings
+ options : ovn-owned optional string
Common Columns:
external_ids map of string-string pairs
@@ -3399,6 +3421,11 @@
only to the DNS queries originating from the datapaths defined
in this column.
+ options : ovn-owned: optional string
+ This column indicates that all the Domains in this table are
+ owned by OVN, and all DNS queries for those domains will be an‐
+ swered locally by either an IP address or DNS rejection.
+
Common Columns:
external_ids: map of string-string pairs
@@ -3409,12 +3436,12 @@
Summary:
name string
- permissions map of string-weak reference to RBAC_Per‐
+ permissions map of string-weak reference to RBAC_Per‐‐
mission pairs
Details:
name: string
- The role name, corresponding to the role column in the Connec‐
+ The role name, corresponding to the role column in the Connec‐‐
tion table.
permissions: map of string-weak reference to RBAC_Permission pairs
@@ -3434,7 +3461,7 @@
Name of table to which this row applies.
authorization: set of strings
- Set of strings identifying columns and column:key pairs to be
+ Set of strings identifying columns and column:key pairs to be
compared with client ID. At least one match is required in order
to be authorized. A zero-length string is treated as a special
value indicating all clients should be considered authorized.
@@ -3444,12 +3471,12 @@
permitted.
update: set of strings
- Set of strings identifying columns and column:key pairs that
- authorized clients are allowed to modify.
+ Set of strings identifying columns and column:key pairs that au‐
+ thorized clients are allowed to modify.
Gateway_Chassis TABLE
- Association of Port_Binding rows of type chassisredirect to a Chassis.
- The traffic going out through a specific chassisredirect port will be
+ Association of Port_Binding rows of type chassisredirect to a Chassis.
+ The traffic going out through a specific chassisredirect port will be
redirected to a chassis, or a set of them in high availability configu‐
rations.
@@ -3484,7 +3511,6 @@
at the beginning of this document.
external_ids: map of string-string pairs
-
HA_Chassis TABLE
Summary:
chassis optional weak reference to Chassis
@@ -3507,13 +3533,13 @@
HA_Chassis_Group TABLE
Table representing a group of chassis which can provide High availabil‐
- ity services. Each chassis in the group is represented by the table
- HA_Chassis. The HA chassis with highest priority will be the master of
- this group. If the master chassis failover is detected, the HA chassis
- with the next higher priority takes over the responsibility of provid‐
+ ity services. Each chassis in the group is represented by the table
+ HA_Chassis. The HA chassis with highest priority will be the master of
+ this group. If the master chassis failover is detected, the HA chassis
+ with the next higher priority takes over the responsibility of provid‐
ing the HA. If ha_chassis_group column of the table Port_Binding refer‐
ences this table, then this HA chassis group provides the gateway func‐
- tionality and redirects the gateway traffic to the master of this
+ tionality and redirects the gateway traffic to the master of this
group.
Summary:
@@ -3531,14 +3557,14 @@
A list of HA_Chassis which belongs to this group.
ref_chassis: set of weak reference to Chassis
- The set of Chassis that reference this HA chassis group. To
- determine the correct Chassis, find the chassisredirect type
- Port_Binding that references this HA_Chassis_Group. This
- Port_Binding is derived from some particular logical router.
- Starting from that LR, find the set of all logical switches and
- routers connected to it, directly or indirectly, across router
- ports that link one LRP to another or to a LSP. For each LSP in
- these logical switches, find the corresponding Port_Binding and
+ The set of Chassis that reference this HA chassis group. To de‐
+ termine the correct Chassis, find the chassisredirect type
+ Port_Binding that references this HA_Chassis_Group. This
+ Port_Binding is derived from some particular logical router.
+ Starting from that LR, find the set of all logical switches and
+ routers connected to it, directly or indirectly, across router
+ ports that link one LRP to another or to a LSP. For each LSP in
+ these logical switches, find the corresponding Port_Binding and
add its bound Chassis (if any) to ref_chassis.
Common Columns:
@@ -3547,7 +3573,7 @@
See External IDs at the beginning of this document.
Controller_Event TABLE
- Database table used by ovn-controller to report CMS related events.
+ Database table used by ovn-controller to report CMS related events.
Please note there is no guarantee a given event is written exactly once
in the db. It is CMS responsibility to squash duplicated lines or to
filter out duplicated events
@@ -3566,12 +3592,12 @@
Key-value pairs used to specify event info to the CMS. Possible
values are:
- · vip: VIP reported for the empty_lb_backends event
+ • vip: VIP reported for the empty_lb_backends event
- · protocol: Transport protocol reported for the
+ • protocol: Transport protocol reported for the
empty_lb_backends event
- · load_balancer: UUID of the load balancer reported for the
+ • load_balancer: UUID of the load balancer reported for the
empty_lb_backends event
chassis: optional weak reference to Chassis
@@ -3587,7 +3613,7 @@
IP Multicast configuration options. For now only applicable to IGMP.
Summary:
- datapath weak reference to Datapath_Binding (must
+ datapath weak reference to Datapath_Binding (must
be unique within table)
enabled optional boolean
querier optional boolean
@@ -3611,12 +3637,12 @@
Enables/disables multicast snooping. Default: disabled.
querier: optional boolean
- Enables/disables multicast querying. If enabled then multicast
+ Enables/disables multicast querying. If enabled then multicast
querying is enabled by default.
table_size: optional integer
- Limits the number of multicast groups that can be learned.
- Default: 2048 groups per datapath.
+ Limits the number of multicast groups that can be learned. De‐
+ fault: 2048 groups per datapath.
idle_timeout: optional integer
Configures the idle timeout (in seconds) for IP multicast groups
@@ -3624,16 +3650,16 @@
query_interval: optional integer
Configures the interval (in seconds) for sending multicast
- queries if snooping and querier are enabled. Default: idle_time‐
+ queries if snooping and querier are enabled. Default: idle_time‐‐
out/2 seconds.
seq_no: integer
- ovn-controller reads this value and flushes all learned multi‐
+ ovn-controller reads this value and flushes all learned multi‐
cast groups when it detects that seq_no was changed.
Querier configuration options:
- The ovn-controller process that runs on OVN hypervisor nodes uses the
+ The ovn-controller process that runs on OVN hypervisor nodes uses the
following columns to determine field values in IGMP/MLD queries that it
originates:
@@ -3655,10 +3681,11 @@
Summary:
address string
- datapath optional weak reference to Datapath_Bind‐
+ datapath optional weak reference to Datapath_Bind‐‐
ing
chassis optional weak reference to Chassis
ports set of weak reference to Port_Bindings
+ chassis_name string
Details:
address: string
@@ -3673,13 +3700,17 @@
ports: set of weak reference to Port_Bindings
The destination port bindings for this IGMP group.
+ chassis_name: string
+ The chassis that inserted this record. This column is used for
+ RBAC purposes only.
+
Service_Monitor TABLE
Each row in this table configures monitoring a service for its live‐
- ness. The service can be an IPv4 TCP or UDP service. ovn-controller
- periodically sends out service monitor packets and updates the status
- of the service. Service monitoring for IPv6 services is not supported.
+ ness. The service can be an IPv4 TCP or UDP service. ovn-controller pe‐
+ riodically sends out service monitor packets and updates the status of
+ the service. Service monitoring for IPv6 services is not supported.
- ovn-northd uses this feature to implement the load balancer health
+ ovn-northd uses this feature to implement the load balancer health
check feature offered to the CMS through the northbound database.
Summary:
@@ -3690,12 +3721,13 @@
logical_port string
src_mac string
src_ip string
+ chassis_name string
options : interval optional string, containing an integer
options : timeout optional string, containing an integer
options : success_count optional string, containing an integer
options : failure_count optional string, containing an integer
Status Reporting:
- status optional string, one of error, offline,
+ status optional string, one of error, offline,
or online
Common Columns:
external_ids map of string-string pairs
@@ -3726,6 +3758,9 @@
src_ip: string
Source IPv4 address to use in the service monitor packet.
+ chassis_name: string
+ The name of the chassis where the logical port is bound.
+
options : interval: optional string, containing an integer
The interval, in seconds, between service monitor checks.
@@ -3768,6 +3803,8 @@
protocol optional string, one of sctp, tcp, or udp
datapaths set of Datapath_Bindings
datapath_group optional Logical_DP_Group
+ ls_datapath_group optional Logical_DP_Group
+ lr_datapath_group optional Logical_DP_Group
Load_Balancer options:
options : hairpin_snat_ip optional string
options : hairpin_orig_tuple
@@ -3777,30 +3814,40 @@
Details:
name: string
- A name for the load balancer. This name has no special meaning
- or purpose other than to provide convenience for human interac‐
+ A name for the load balancer. This name has no special meaning
+ or purpose other than to provide convenience for human interac‐
tion with the ovn-nb database.
vips: map of string-string pairs
- A map of virtual IP addresses (and an optional port number with
- : as a separator) associated with this load balancer and their
- corresponding endpoint IP addresses (and optional port numbers
+ A map of virtual IP addresses (and an optional port number with
+ : as a separator) associated with this load balancer and their
+ corresponding endpoint IP addresses (and optional port numbers
with : as separators) separated by commas.
protocol: optional string, one of sctp, tcp, or udp
- Valid protocols are tcp, udp, or sctp. This column is useful
- when a port number is provided as part of the vips column. If
- this column is empty and a port number is provided as part of
+ Valid protocols are tcp, udp, or sctp. This column is useful
+ when a port number is provided as part of the vips column. If
+ this column is empty and a port number is provided as part of
vips column, OVN assumes the protocol to be tcp.
datapaths: set of Datapath_Bindings
Datapaths to which this load balancer applies to.
datapath_group: optional Logical_DP_Group
- The group of datapaths to which this load balancer applies to.
- This means that the same load balancer applies to all datapaths
+ Deprecated. The group of datapaths to which this load balancer
+ applies to. This means that the same load balancer applies to
+ all datapaths in a group.
+
+ ls_datapath_group: optional Logical_DP_Group
+ The group of datapaths to which this load balancer applies to.
+ This means that the same load balancer applies to all datapaths
in a group.
+ lr_datapath_group: optional Logical_DP_Group
+ The group of logical router datapaths to which this load bal‐
+ ancer applies to. This means that the same load balancer applies
+ to all datapaths in a group.
+
Load_Balancer options:
options : hairpin_snat_ip: optional string
@@ -3810,7 +3857,7 @@
options : hairpin_orig_tuple: optional string, either true or false
This value is automatically set to true by ovn-northd when orig‐
- inal destination IP and transport port of the load balanced
+ inal destination IP and transport port of the load balanced
packets are stored in registers reg1, reg2, xxreg1.
Common Columns:
@@ -3830,6 +3877,7 @@
min_tx integer
min_rx integer
detect_mult integer
+ chassis_name string
options map of string-string pairs
external_ids map of string-string pairs
Status Reporting:
@@ -3845,7 +3893,7 @@
disc: integer
A unique, nonzero discriminator value generated by the transmit‐
- ting system, used to demultiplex multiple BFD sessions between
+ ting system, used to demultiplex multiple BFD sessions between
the same pair of systems.
logical_port: string
@@ -3855,22 +3903,25 @@
BFD peer IP address.
min_tx: integer
- This is the minimum interval, in milliseconds, that the local
- system would like to use when transmitting BFD Control packets,
+ This is the minimum interval, in milliseconds, that the local
+ system would like to use when transmitting BFD Control packets,
less any jitter applied. The value zero is reserved.
min_rx: integer
- This is the minimum interval, in milliseconds, between received
- BFD Control packets that this system is capable of supporting,
- less any jitter applied by the sender. If this value is zero,
- the transmitting system does not want the remote system to send
+ This is the minimum interval, in milliseconds, between received
+ BFD Control packets that this system is capable of supporting,
+ less any jitter applied by the sender. If this value is zero,
+ the transmitting system does not want the remote system to send
any periodic BFD Control packets.
detect_mult: integer
- Detection time multiplier. The negotiated transmit interval,
- multiplied by this value, provides the Detection Time for the
+ Detection time multiplier. The negotiated transmit interval,
+ multiplied by this value, provides the Detection Time for the
receiving system in Asynchronous mode.
+ chassis_name: string
+ The name of the chassis where the logical port is bound.
+
options: map of string-string pairs
Reserved for future use.
@@ -3882,27 +3933,27 @@
status: string, one of admin_down, down, init, or up
BFD port logical states. Possible values are:
- · admin_down
+ • admin_down
- · down
+ • down
- · init
-
- · up
+ • init
+ • up
FDB TABLE
- This table is primarily used to learn the MACs observed on a VIF (or a
- localnet port with ’localnet_learn_fdb’ enabled) which belongs to a
- Logical_Switch_Port record in OVN_Northbound whose port security is
- disabled and ’unknown’ address set. If port security is disabled on a
- Logical_Switch_Port record, OVN should allow traffic with any source
- mac from the VIF. This table will be used to deliver a packet to the
+ This table is primarily used to learn the MACs observed on a VIF (or a
+ localnet port with ’localnet_learn_fdb’ enabled) which belongs to a
+ Logical_Switch_Port record in OVN_Northbound whose port security is
+ disabled and ’unknown’ address set. If port security is disabled on a
+ Logical_Switch_Port record, OVN should allow traffic with any source
+ mac from the VIF. This table will be used to deliver a packet to the
VIF, If a packet’s eth.dst is learnt.
Summary:
mac string
dp_key integer, in range 1 to 16,777,215
port_key integer, in range 1 to 16,777,215
+ timestamp integer
Details:
mac: string
@@ -3914,6 +3965,10 @@
port_key: integer, in range 1 to 16,777,215
The key of the port binding on which this FDB was learnt.
+ timestamp: integer
+ The timestamp in msec when the FDB was added or updated. Records
+ that existed before this column will have 0.
+
Static_MAC_Binding TABLE
Each record represents a Static_MAC_Binding entry for a logical router.
@@ -3941,7 +3996,7 @@
The logical datapath to which the logical router port belongs.
Chassis_Template_Var TABLE
- Each record represents the set of template variable instantiations for
+ Each record represents the set of template variable instantiations for
a given chassis and is populated by ovn-northd from the contents of the
OVN_Northbound.Chassis_Template_Var table.
@@ -3956,7 +4011,5 @@
variables: map of string-string pairs
The set of variable values for a given chassis.
-
-
-Open vSwitch 22.12.90 DB Schema 20.27.0 ovn-sb(5)
+Open vSwitch 24.03.90 DB Schema 20.33.0 ovn-sb(5)
diff --git a/src/static/support/dist-docs/ovn-sb.5.pdf b/src/static/support/dist-docs/ovn-sb.5.pdf
index 70cff0bd..1536217b 100644
Binary files a/src/static/support/dist-docs/ovn-sb.5.pdf and b/src/static/support/dist-docs/ovn-sb.5.pdf differ
diff --git a/src/static/support/dist-docs/ovn-sb.5.txt b/src/static/support/dist-docs/ovn-sb.5.txt
index 4bad422e..b184dbde 100644
--- a/src/static/support/dist-docs/ovn-sb.5.txt
+++ b/src/static/support/dist-docs/ovn-sb.5.txt
@@ -1,51 +1,48 @@
ovn-sb(5) Open vSwitch Manual ovn-sb(5)
-
-
NAME
ovn-sb - OVN_Southbound database schema
This database holds logical and physical configuration and state for
- the Open Virtual Network (OVN) system to support virtual network
- abstraction. For an introduction to OVN, please see ovn-architec‐
- ture(7).
+ the Open Virtual Network (OVN) system to support virtual network ab‐
+ straction. For an introduction to OVN, please see ovn-architecture(7).
The OVN Southbound database sits at the center of the OVN architecture.
It is the one component that speaks both southbound directly to all the
- hypervisors and gateways, via ovn-controller/ovn-controller-vtep, and
+ hypervisors and gateways, via ovn-controller/ovn-controller-vtep, and
northbound to the Cloud Management System, via ovn-northd:
Database Structure
- The OVN Southbound database contains classes of data with different
+ The OVN Southbound database contains classes of data with different
properties, as described in the sections below.
Physical network
- Physical network tables contain information about the chassis nodes in
- the system. This contains all the information necessary to wire the
- overlay, such as IP addresses, supported tunnel types, and security
+ Physical network tables contain information about the chassis nodes in
+ the system. This contains all the information necessary to wire the
+ overlay, such as IP addresses, supported tunnel types, and security
keys.
- The amount of physical network data is small (O(n) in the number of
- chassis) and it changes infrequently, so it can be replicated to every
+ The amount of physical network data is small (O(n) in the number of
+ chassis) and it changes infrequently, so it can be replicated to every
chassis.
The Chassis and Encap tables are the physical network tables.
Logical Network
- Logical network tables contain the topology of logical switches and
- routers, ACLs, firewall rules, and everything needed to describe how
- packets traverse a logical network, represented as logical datapath
+ Logical network tables contain the topology of logical switches and
+ routers, ACLs, firewall rules, and everything needed to describe how
+ packets traverse a logical network, represented as logical datapath
flows (see Logical Datapath Flows, below).
Logical network data may be large (O(n) in the number of logical ports,
ACL rules, etc.). Thus, to improve scaling, each chassis should receive
- only data related to logical networks in which that chassis partici‐
+ only data related to logical networks in which that chassis partici‐
pates.
- The logical network data is ultimately controlled by the cloud manage‐
- ment system (CMS) running northbound of OVN. That CMS determines the
+ The logical network data is ultimately controlled by the cloud manage‐
+ ment system (CMS) running northbound of OVN. That CMS determines the
entire OVN logical configuration and therefore the logical network data
at any given time is a deterministic function of the CMS’s configura‐
tion, although that happens indirectly via the OVN_Northbound database
@@ -66,12 +63,12 @@ NAME
sis, and map logical entities to the values that represent them in tun‐
nel encapsulations.
- These tables change frequently, at least every time a VM powers up or
- down or migrates, and especially quickly in a container environment.
+ These tables change frequently, at least every time a VM powers up or
+ down or migrates, and especially quickly in a container environment.
The amount of data per VM (or VIF) is small.
- Each chassis is authoritative about the VMs and VIFs that it hosts at
- any given time and can efficiently flood that state to a central loca‐
+ Each chassis is authoritative about the VMs and VIFs that it hosts at
+ any given time and can efficiently flood that state to a central loca‐
tion, so the consistency needs are minimal.
The Port_Binding and Datapath_Binding tables contain binding data.
@@ -87,12 +84,12 @@ NAME
Common Columns
Some tables contain a special column named external_ids. This column
- has the same form and purpose each place that it appears, so we
- describe it here to save space later.
+ has the same form and purpose each place that it appears, so we de‐
+ scribe it here to save space later.
external_ids: map of string-string pairs
Key-value pairs for use by the software that manages the
- OVN Southbound database rather than by ovn-con‐
+ OVN Southbound database rather than by ovn-con‐
troller/ovn-controller-vtep. In particular, ovn-northd
can use key-value pairs in this column to relate entities
in the southbound database to higher-level entities (such
@@ -168,8 +165,8 @@ TABLE SUMMARY
Chassis_Template_Var configuration.
SB_Global TABLE
- Southbound configuration for an OVN system. This table must have
- exactly one row.
+ Southbound configuration for an OVN system. This table must have ex‐
+ actly one row.
Summary:
Status:
@@ -192,6 +189,9 @@ SB_Global TABLE
Options for configuring Load Balancers:
options : lb_hairpin_use_ct_mark
optional string
+ Options for configuring ovn-sbctl:
+ options : sbctl_probe_interval
+ optional string
Connection Options:
connections set of Connections
ssl optional SSL
@@ -227,8 +227,8 @@ SB_Global TABLE
Options for configuring BFD:
- These options apply when ovn-controller configures BFD on tunnels
- interfaces.
+ These options apply when ovn-controller configures BFD on tunnels in‐
+ terfaces.
options : bfd-min-rx: optional string
BFD option min-rx value to use when configuring BFD on tunnel
@@ -243,48 +243,62 @@ SB_Global TABLE
interfaces.
options : bfd-mult: optional string
- BFD option mult value to use when configuring BFD on tunnel
- interfaces.
+ BFD option mult value to use when configuring BFD on tunnel in‐
+ terfaces.
options : debug_drop_domain_id: optional string
If set to a 8-bit number and if debug_drop_collector_set is also
- configured, ovn-controller will add a sample action to every
- flow that does not come from a logical flow that contains a
- ’drop’ action. The 8 most significant bits of the observa‐
- tion_domain_id field will be those specified in the
- debug_drop_domain_id. The 24 least significant bits of the
- observation_domain_id field will be zero.
-
- The observation_point_id will be set to the OpenFlow table num‐
+ configured, ovn-controller will add a sample action to every
+ flow that does not come from a logical flow that contains a
+ ’drop’ action. The 8 most significant bits of the observa‐
+ tion_domain_id field will be those specified in the de‐
+ bug_drop_domain_id. The 24 least significant bits of the obser‐
+ vation_domain_id field will be zero.
+
+ The observation_point_id will be set to the OpenFlow table num‐
ber.
options : debug_drop_collector_set: optional string
- If set to a 32-bit number ovn-controller will add a sample
- action to every flow that does not come from a logical flow that
+ If set to a 32-bit number ovn-controller will add a sample ac‐
+ tion to every flow that does not come from a logical flow that
contains a ’drop’ action. The sample action will have the speci‐
fied collector_set_id. The value must match that of the local
OVS configuration as described in ovs-actions(7).
Options for configuring Load Balancers:
- These options apply when ovn-controller configures load balancer
- related flows.
+ These options apply when ovn-controller configures load balancer re‐
+ lated flows.
options : lb_hairpin_use_ct_mark: optional string
By default this option is turned on (even if not present in the
database) unless its value is explicitly set to false. This
value is automatically set to false by ovn-northd when action
- ct_lb_mark cannot be used for new load balancer sessions and
- action ct_lb will be used instead. ovn-controller then knows
- that it should check ct_label.natted to detect load balanced
- traffic.
+ ct_lb_mark cannot be used for new load balancer sessions and ac‐
+ tion ct_lb will be used instead. ovn-controller then knows that
+ it should check ct_label.natted to detect load balanced traffic.
+
+ Options for configuring ovn-sbctl:
+
+ These options apply when ovn-sbctl connects to OVN Southbound database.
+
+ options : sbctl_probe_interval: optional string
+ The inactivity probe interval of the connection to the OVN
+ Southbound database from ovn-sbctl utility, in milliseconds. If
+ the value is zero, it disables the connection keepalive feature.
+
+ If the value is nonzero, then it will be forced to a value of at
+ least 1000 ms.
+
+ If the value is less than zero, then the default inactivity
+ probe interval for ovn-sbctl would be left intact (120000 ms).
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 Connec‐
+ 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 Connec‐
tion table for more information.
ssl: optional SSL
@@ -293,14 +307,14 @@ SB_Global TABLE
Security Configurations:
ipsec: boolean
- Tunnel encryption configuration. If this column is set to be
+ Tunnel encryption configuration. If this column is set to be
true, all OVN tunnels will be encrypted with IPsec.
Chassis TABLE
- Each row in this table represents a hypervisor or gateway (a chassis)
- in the physical network. Each chassis, via ovn-controller/ovn-con‐
- troller-vtep, adds and updates its own row, and keeps a copy of the
- remaining rows to determine how to reach other hypervisors.
+ Each row in this table represents a hypervisor or gateway (a chassis)
+ in the physical network. Each chassis, via ovn-controller/ovn-con‐
+ troller-vtep, adds and updates its own row, and keeps a copy of the re‐
+ maining rows to determine how to reach other hypervisors.
When a chassis shuts down gracefully, it should remove its own row.
(This is not critical because resources hosted on the chassis are
@@ -346,14 +360,14 @@ Chassis TABLE
on. ovn-controller-vtep will leave this column empty.
nb_cfg: integer
- Deprecated. This column is replaced by the nb_cfg column of the
+ Deprecated. This column is replaced by the nb_cfg column of the
Chassis_Private table.
other_config : ovn-bridge-mappings: optional string
- ovn-controller populates this key with the set of bridge map‐
- pings it has been configured to use. Other applications should
- treat this key as read-only. See ovn-controller(8) for more
- information.
+ ovn-controller populates this key with the set of bridge map‐
+ pings it has been configured to use. Other applications should
+ treat this key as read-only. See ovn-controller(8) for more in‐
+ formation.
other_config : datapath-type: optional string
ovn-controller populates this key with the datapath type config‐
@@ -364,13 +378,13 @@ Chassis TABLE
other_config : iface-types: optional string
ovn-controller populates this key with the interface types con‐
figured in the iface_types column of the Open_vSwitch database’s
- Open_vSwitch table. Other applications should treat this key as
+ Open_vSwitch table. Other applications should treat this key as
read-only. See ovn-controller(8) for more information.
other_config : ovn-cms-options: optional string
- ovn-controller populates this key with the set of options con‐
- figured in the external_ids:ovn-cms-options column of the
- Open_vSwitch database’s Open_vSwitch table. See ovn-con‐
+ ovn-controller populates this key with the set of options con‐
+ figured in the external_ids:ovn-cms-options column of the
+ Open_vSwitch database’s Open_vSwitch table. See ovn-con‐
troller(8) for more information.
other_config : is-interconn: optional string
@@ -388,13 +402,13 @@ Chassis TABLE
transport_zones: set of strings
ovn-controller populates this key with the transport zones con‐
figured in the external_ids:ovn-transport-zones column of the
- Open_vSwitch database’s Open_vSwitch table. See ovn-con‐
+ Open_vSwitch database’s Open_vSwitch table. See ovn-con‐
troller(8) for more information.
other_config : ovn-chassis-mac-mappings: optional string
ovn-controller populates this key with the set of options con‐
figured in the external_ids:ovn-chassis-mac-mappings column of
- the Open_vSwitch database’s Open_vSwitch table. See ovn-con‐
+ the Open_vSwitch database’s Open_vSwitch table. See ovn-con‐
troller(8) for more information.
other_config : port-up-notif: optional string
@@ -420,26 +434,26 @@ Chassis TABLE
Gateway Configuration:
- A gateway is a chassis that forwards traffic between the OVN-managed
+ A gateway is a chassis that forwards traffic between the OVN-managed
part of a logical network and a physical VLAN, extending a tunnel-based
logical network into a physical network. Gateways are typically dedi‐
- cated nodes that do not host VMs and will be controlled by ovn-con‐
+ cated nodes that do not host VMs and will be controlled by ovn-con‐
troller-vtep.
vtep_logical_switches: set of strings
Stores all VTEP logical switch names connected by this gateway
- chassis. The Port_Binding table entry with options:vtep-physi‐
+ chassis. The Port_Binding table entry with options:vtep-physi‐
cal-switch equal Chassis name, and options:vtep-logical-switch
value in Chassis vtep_logical_switches, will be associated with
this Chassis.
Chassis_Private TABLE
- Each row in this table maintains per chassis private data that are
- accessed only by the owning chassis (write only) and ovn-northd, not by
+ Each row in this table maintains per chassis private data that are ac‐
+ cessed only by the owning chassis (write only) and ovn-northd, not by
any other chassis. These data are stored in this separate table instead
- of the Chassis table for performance considerations: the rows in this
- table can be conditionally monitored by chassises so that each chassis
- only get update notifications for its own row, to avoid unnecessary
+ of the Chassis table for performance considerations: the rows in this
+ table can be conditionally monitored by chassises so that each chassis
+ only get update notifications for its own row, to avoid unnecessary
chassis private data update flooding in a large scale deployment.
Summary:
@@ -455,13 +469,13 @@ Chassis_Private TABLE
The name of the chassis that owns these chassis-private data.
chassis: optional weak reference to Chassis
- The reference to Chassis table for the chassis that owns these
+ The reference to Chassis table for the chassis that owns these
chassis-private data.
nb_cfg: integer
- Sequence number for the configuration. When ovn-controller
- updates the configuration of a chassis from the contents of the
- southbound database, it copies nb_cfg from the SB_Global table
+ Sequence number for the configuration. When ovn-controller up‐
+ dates the configuration of a chassis from the contents of the
+ southbound database, it copies nb_cfg from the SB_Global table
into this column.
nb_cfg_timestamp: integer
@@ -474,7 +488,6 @@ Chassis_Private TABLE
at the beginning of this document.
external_ids: map of string-string pairs
-
Encap TABLE
The encaps column in the Chassis table refers to rows in this table to
identify how OVN may transmit logical dataplane packets to this chas‐
@@ -492,9 +505,8 @@ Encap TABLE
Details:
type: string, one of geneve, stt, or vxlan
- The encapsulation to use to transmit packets to this chassis.
- Hypervisors must use either geneve or stt. Gateways may use
- vxlan, geneve, or stt.
+ The encapsulation to use to transmit packets to this chassis.
+ Hypervisors and gateways must use one of: geneve, vxlan, or stt.
options: map of string-string pairs
Options for configuring the encapsulation, which may be type
@@ -510,27 +522,26 @@ Encap TABLE
table. Other applications should treat this key as read-only.
See ovn-controller(8) for more information.
- In terms of performance, checksumming actually significantly
- increases throughput in most common cases when running on Linux
- based hosts without NICs supporting encapsulation hardware off‐
- load (around 60% for bulk traffic). The reason is that generally
- all NICs are capable of offloading transmitted and received
+ In terms of performance, checksumming actually significantly in‐
+ creases throughput in most common cases when running on Linux
+ based hosts without NICs supporting encapsulation hardware of‐
+ fload (around 60% for bulk traffic). The reason is that gener‐
+ ally all NICs are capable of offloading transmitted and received
TCP/UDP checksums (viewed as ordinary data packets and not as
tunnels). The benefit comes on the receive side where the vali‐
- dated outer checksum can be used to additionally validate an
- inner checksum (such as TCP), which in turn allows aggregation
- of packets to be more efficiently handled by the rest of the
- stack.
+ dated outer checksum can be used to additionally validate an in‐
+ ner checksum (such as TCP), which in turn allows aggregation of
+ packets to be more efficiently handled by the rest of the stack.
Not all devices see such a benefit. The most notable exception
- is hardware VTEPs. These devices are designed to not buffer
- entire packets in their switching engines and are therefore
- unable to efficiently compute or validate full packet checksums.
- In addition certain versions of the Linux kernel are not able to
+ is hardware VTEPs. These devices are designed to not buffer en‐
+ tire packets in their switching engines and are therefore unable
+ to efficiently compute or validate full packet checksums. In ad‐
+ dition certain versions of the Linux kernel are not able to
fully take advantage of encapsulation NIC offloads in the pres‐
ence of checksums. (This is actually a pretty narrow corner case
- though: earlier versions of Linux don’t support encapsulation
- offloads at all and later versions support both offloads and
+ though: earlier versions of Linux don’t support encapsulation
+ offloads at all and later versions support both offloads and
checksums well.)
csum defaults to false for hardware VTEPs and true for all other
@@ -564,10 +575,9 @@ Address_Set TABLE
name: string (must be unique within table)
addresses: set of strings
-
Port_Group TABLE
This table contains names for the logical switch ports in the
- OVN_Northbound database that belongs to the same group that is defined
+ OVN_Northbound database that belongs to the same group that is defined
in Port_Group in the OVN_Northbound database.
Summary:
@@ -578,57 +588,56 @@ Port_Group TABLE
name: string (must be unique within table)
ports: set of strings
-
Logical_Flow TABLE
- Each row in this table represents one logical flow. ovn-northd popu‐
- lates this table with logical flows that implement the L2 and L3
- topologies specified in the OVN_Northbound database. Each hypervisor,
- via ovn-controller, translates the logical flows into OpenFlow flows
+ Each row in this table represents one logical flow. ovn-northd popu‐
+ lates this table with logical flows that implement the L2 and L3
+ topologies specified in the OVN_Northbound database. Each hypervisor,
+ via ovn-controller, translates the logical flows into OpenFlow flows
specific to its hypervisor and installs them into Open vSwitch.
- Logical flows are expressed in an OVN-specific format, described here.
- A logical datapath flow is much like an OpenFlow flow, except that the
- flows are written in terms of logical ports and logical datapaths
- instead of physical ports and physical datapaths. Translation between
- logical and physical flows helps to ensure isolation between logical
- datapaths. (The logical flow abstraction also allows the OVN central‐
- ized components to do less work, since they do not have to separately
+ Logical flows are expressed in an OVN-specific format, described here.
+ A logical datapath flow is much like an OpenFlow flow, except that the
+ flows are written in terms of logical ports and logical datapaths in‐
+ stead of physical ports and physical datapaths. Translation between
+ logical and physical flows helps to ensure isolation between logical
+ datapaths. (The logical flow abstraction also allows the OVN central‐
+ ized components to do less work, since they do not have to separately
compute and push out physical flows to each chassis.)
The default action when no flow matches is to drop packets.
Architectural Logical Life Cycle of a Packet
- This following description focuses on the life cycle of a packet
- through a logical datapath, ignoring physical details of the implemen‐
- tation. Please refer to Architectural Physical Life Cycle of a Packet
+ This following description focuses on the life cycle of a packet
+ through a logical datapath, ignoring physical details of the implemen‐
+ tation. Please refer to Architectural Physical Life Cycle of a Packet
in ovn-architecture(7) for the physical information.
- The description here is written as if OVN itself executes these steps,
- but in fact OVN (that is, ovn-controller) programs Open vSwitch, via
+ The description here is written as if OVN itself executes these steps,
+ but in fact OVN (that is, ovn-controller) programs Open vSwitch, via
OpenFlow and OVSDB, to execute them on its behalf.
- At a high level, OVN passes each packet through the logical datapath’s
- logical ingress pipeline, which may output the packet to one or more
- logical port or logical multicast groups. For each such logical output
- port, OVN passes the packet through the datapath’s logical egress pipe‐
- line, which may either drop the packet or deliver it to the destina‐
- tion. Between the two pipelines, outputs to logical multicast groups
- are expanded into logical ports, so that the egress pipeline only pro‐
- cesses a single logical output port at a time. Between the two pipe‐
- lines is also where, when necessary, OVN encapsulates a packet in a
+ At a high level, OVN passes each packet through the logical datapath’s
+ logical ingress pipeline, which may output the packet to one or more
+ logical port or logical multicast groups. For each such logical output
+ port, OVN passes the packet through the datapath’s logical egress
+ pipeline, which may either drop the packet or deliver it to the desti‐
+ nation. Between the two pipelines, outputs to logical multicast groups
+ are expanded into logical ports, so that the egress pipeline only
+ processes a single logical output port at a time. Between the two
+ pipelines is also where, when necessary, OVN encapsulates a packet in a
tunnel (or tunnels) to transmit to remote hypervisors.
In more detail, to start, OVN searches the Logical_Flow table for a row
- with correct logical_datapath or a logical_dp_group, a pipeline of
- ingress, a table_id of 0, and a match that is true for the packet. If
- none is found, OVN drops the packet. If OVN finds more than one, it
- chooses the match with the highest priority. Then OVN executes each of
- the actions specified in the row’s actions column, in the order speci‐
- fied. Some actions, such as those to modify packet headers, require no
+ with correct logical_datapath or a logical_dp_group, a pipeline of
+ ingress, a table_id of 0, and a match that is true for the packet. If
+ none is found, OVN drops the packet. If OVN finds more than one, it
+ chooses the match with the highest priority. Then OVN executes each of
+ the actions specified in the row’s actions column, in the order speci‐
+ fied. Some actions, such as those to modify packet headers, require no
further details. The next and output actions are special.
- The next action causes the above process to be repeated recursively,
+ The next action causes the above process to be repeated recursively,
except that OVN searches for table_id of 1 instead of 0. Similarly, any
next action in a row found in that table would cause a further search
for a table_id of 2, and so on. When recursive processing completes,
@@ -638,10 +647,10 @@ Logical_Flow TABLE
current value of the outport field. Suppose outport designates a logi‐
cal port. First, OVN compares inport to outport; if they are equal, it
treats the output as a no-op by default. In the common case, where they
- are different, the packet enters the egress pipeline. This transition
- to the egress pipeline discards register data, e.g. reg0 ... reg9 and
- connection tracking state, to achieve uniform behavior regardless of
- whether the egress pipeline is on a different hypervisor (because reg‐
+ are different, the packet enters the egress pipeline. This transition
+ to the egress pipeline discards register data, e.g. reg0 ... reg9 and
+ connection tracking state, to achieve uniform behavior regardless of
+ whether the egress pipeline is on a different hypervisor (because reg‐
isters aren’t preserve across tunnel encapsulation).
To execute the egress pipeline, OVN again searches the Logical_Flow ta‐
@@ -651,23 +660,22 @@ Logical_Flow TABLE
no-op. Otherwise, OVN executes the actions for the matching flow (which
is chosen from multiple, if necessary, as already described).
- In the egress pipeline, the next action acts as already described,
- except that it, of course, searches for egress flows. The output
- action, however, now directly outputs the packet to the output port
- (which is now fixed, because outport is read-only within the egress
- pipeline).
+ In the egress pipeline, the next action acts as already described, ex‐
+ cept that it, of course, searches for egress flows. The output action,
+ however, now directly outputs the packet to the output port (which is
+ now fixed, because outport is read-only within the egress pipeline).
The description earlier assumed that outport referred to a logical
- port. If it instead designates a logical multicast group, then the
- description above still applies, with the addition of fan-out from the
+ port. If it instead designates a logical multicast group, then the de‐
+ scription above still applies, with the addition of fan-out from the
logical multicast group to each logical port in the group. For each
member of the group, OVN executes the logical pipeline as described,
with the logical output port replaced by the group member.
Pipeline Stages
- ovn-northd populates the Logical_Flow table with the logical flows
- described in detail in ovn-northd(8).
+ ovn-northd populates the Logical_Flow table with the logical flows de‐
+ scribed in detail in ovn-northd(8).
Summary:
logical_datapath optional Datapath_Binding
@@ -690,17 +698,17 @@ Logical_Flow TABLE
The logical datapath to which the logical flow belongs.
logical_dp_group: optional Logical_DP_Group
- The group of logical datapaths to which the logical flow
- belongs. This means that the same logical flow belongs to all
+ The group of logical datapaths to which the logical flow be‐
+ longs. This means that the same logical flow belongs to all
datapaths in a group.
pipeline: string, either egress or ingress
The primary flows used for deciding on a packet’s destination
- are the ingress flows. The egress flows implement ACLs. See Log‐
+ are the ingress flows. The egress flows implement ACLs. See Log‐
ical Life Cycle of a Packet, above, for details.
table_id: integer, in range 0 to 32
- The stage in the logical pipeline, analogous to an OpenFlow ta‐
+ The stage in the logical pipeline, analogous to an OpenFlow ta‐
ble number.
priority: integer, in range 0 to 65,535
@@ -710,7 +718,7 @@ Logical_Flow TABLE
to the packet is undefined.
match: string
- A matching expression. OVN provides a superset of OpenFlow
+ A matching expression. OVN provides a superset of OpenFlow
matching capabilities, using a syntax similar to Boolean expres‐
sions in a programming language.
@@ -722,48 +730,48 @@ Logical_Flow TABLE
Matching expressions also support parentheses for grouping, the
logical NOT prefix operator !, and literals 0 and 1 to express
- ``false’’ or ``true,’’ respectively. The latter is useful by
- itself as a catch-all expression that matches every packet.
+ ``false’’ or ``true,’’ respectively. The latter is useful by it‐
+ self as a catch-all expression that matches every packet.
- Match expressions also support a kind of function syntax. The
+ Match expressions also support a kind of function syntax. The
following functions are supported:
is_chassis_resident(lport)
- Evaluates to true on a chassis on which logical port
- lport (a quoted string) resides, and to false elsewhere.
+ Evaluates to true on a chassis on which logical port
+ lport (a quoted string) resides, and to false elsewhere.
This function was introduced in OVN 2.7.
Symbols
- Type. Symbols have integer or string type. Integer symbols have
+ Type. Symbols have integer or string type. Integer symbols have
a width in bits.
Kinds. There are three kinds of symbols:
- · Fields. A field symbol represents a packet header or
+ • Fields. A field symbol represents a packet header or
metadata field. For example, a field named vlan.tci might
represent the VLAN TCI field in a packet.
A field symbol can have integer or string type. Integer
- fields can be nominal or ordinal (see Level of Measure‐
+ fields can be nominal or ordinal (see Level of Measure‐
ment, below).
- · Subfields. A subfield represents a subset of bits from a
- larger field. For example, a field vlan.vid might be
- defined as an alias for vlan.tci[0..11]. Subfields are
- provided for syntactic convenience, because it is always
- possible to instead refer to a subset of bits from a
+ • Subfields. A subfield represents a subset of bits from a
+ larger field. For example, a field vlan.vid might be de‐
+ fined as an alias for vlan.tci[0..11]. Subfields are pro‐
+ vided for syntactic convenience, because it is always
+ possible to instead refer to a subset of bits from a
field directly.
Only ordinal fields (see Level of Measurement, below) may
have subfields. Subfields are always ordinal.
- · Predicates. A predicate is shorthand for a Boolean
- expression. Predicates may be used much like 1-bit
- fields. For example, ip4 might expand to eth.type ==
- 0x800. Predicates are provided for syntactic convenience,
- because it is always possible to instead specify the
- underlying expression directly.
+ • Predicates. A predicate is shorthand for a Boolean ex‐
+ pression. Predicates may be used much like 1-bit fields.
+ For example, ip4 might expand to eth.type == 0x800. Pred‐
+ icates are provided for syntactic convenience, because it
+ is always possible to instead specify the underlying ex‐
+ pression directly.
A predicate whose expansion refers to any nominal field
or predicate (see Level of Measurement, below) is nomi‐
@@ -774,7 +782,7 @@ Logical_Flow TABLE
tistical concept on which this classification is based. There
are three levels:
- · Ordinal. In statistics, ordinal values can be ordered on
+ • Ordinal. In statistics, ordinal values can be ordered on
a scale. OVN considers a field (or subfield) to be ordi‐
nal if its bits can be examined individually. This is
true for the OpenFlow fields that OpenFlow or Open
@@ -790,16 +798,16 @@ Logical_Flow TABLE
because OVN can implement these in OpenFlow and Open
vSwitch as collections of bitwise tests.
- · Nominal. In statistics, nominal values cannot be usefully
- compared except for equality. This is true of OpenFlow
- port numbers, Ethernet types, and IP protocols are exam‐
- ples: all of these are just identifiers assigned arbi‐
- trarily with no deeper meaning. In OpenFlow and Open
- vSwitch, bits in these fields generally aren’t individu‐
+ • Nominal. In statistics, nominal values cannot be usefully
+ compared except for equality. This is true of OpenFlow
+ port numbers, Ethernet types, and IP protocols are exam‐
+ ples: all of these are just identifiers assigned arbi‐
+ trarily with no deeper meaning. In OpenFlow and Open
+ vSwitch, bits in these fields generally aren’t individu‐
ally addressable.
- OVN only supports arithmetic tests for equality on nomi‐
- nal fields, because OpenFlow and Open vSwitch provide no
+ OVN only supports arithmetic tests for equality on nomi‐
+ nal fields, because OpenFlow and Open vSwitch provide no
way for a flow to efficiently implement other comparisons
on them. (A test for inequality can be sort of built out
of two flows with different priorities, but OVN matching
@@ -808,45 +816,45 @@ Logical_Flow TABLE
String fields are always nominal.
- · Boolean. A nominal field that has only two values, 0 and
+ • Boolean. A nominal field that has only two values, 0 and
1, is somewhat exceptional, since it is easy to support
- both equality and inequality tests on such a field:
- either one can be implemented as a test for 0 or 1.
+ both equality and inequality tests on such a field: ei‐
+ ther one can be implemented as a test for 0 or 1.
Only predicates (see above) have a Boolean level of mea‐
surement.
This isn’t a standard level of measurement.
- Prerequisites. Any symbol can have prerequisites, which are
- additional condition implied by the use of the symbol. For exam‐
+ Prerequisites. Any symbol can have prerequisites, which are ad‐
+ ditional condition implied by the use of the symbol. For exam‐
ple, For example, icmp4.type symbol might have prerequisite
- icmp4, which would cause an expression icmp4.type == 0 to be
- interpreted as icmp4.type == 0 && icmp4, which would in turn
- expand to icmp4.type == 0 && eth.type == 0x800 && ip4.proto == 1
- (assuming icmp4 is a predicate defined as suggested under Types
+ icmp4, which would cause an expression icmp4.type == 0 to be in‐
+ terpreted as icmp4.type == 0 && icmp4, which would in turn ex‐
+ pand to icmp4.type == 0 && eth.type == 0x800 && ip4.proto == 1
+ (assuming icmp4 is a predicate defined as suggested under Types
above).
Relational operators
- All of the standard relational operators ==, !=, <, <=, >, and
- >= are supported. Nominal fields support only == and !=, and
- only in a positive sense when outer ! are taken into account,
+ All of the standard relational operators ==, !=, <, <=, >, and
+ >= are supported. Nominal fields support only == and !=, and
+ only in a positive sense when outer ! are taken into account,
e.g. given string field inport, inport == "eth0" and !(inport !=
"eth0") are acceptable, but not inport != "eth0".
- The implementation of == (or != when it is negated), is more
- efficient than that of the other relational operators.
+ The implementation of == (or != when it is negated), is more ef‐
+ ficient than that of the other relational operators.
Constants
- Integer constants may be expressed in decimal, hexadecimal pre‐
+ Integer constants may be expressed in decimal, hexadecimal pre‐
fixed by 0x, or as dotted-quad IPv4 addresses, IPv6 addresses in
their standard forms, or Ethernet addresses as colon-separated
hex digits. A constant in any of these forms may be followed by
a slash and a second constant (the mask) in the same form, to
- form a masked constant. IPv4 and IPv6 masks may be given as
- integers, to express CIDR prefixes.
+ form a masked constant. IPv4 and IPv6 masks may be given as in‐
+ tegers, to express CIDR prefixes.
String constants have the same syntax as quoted strings in JSON
(thus, they are Unicode strings).
@@ -856,58 +864,58 @@ Logical_Flow TABLE
last elements, are optional. With ==, ``field == { constant1,
constant2, ... }’’ is syntactic sugar for ``field == constant1
|| field == constant2 || .... Similarly, ``field != { constant1,
- constant2, ... }’’ is equivalent to ``field != constant1 &&
+ constant2, ... }’’ is equivalent to ``field != constant1 &&
field != constant2 && ...’’.
You may refer to a set of IPv4, IPv6, or MAC addresses stored in
the Address_Set table by its name. An Address_Set with a name of
set1 can be referred to as $set1.
- You may refer to a group of logical switch ports stored in the
- Port_Group table by its name. An Port_Group with a name of
+ You may refer to a group of logical switch ports stored in the
+ Port_Group table by its name. An Port_Group with a name of
port_group1 can be referred to as @port_group1.
Additionally, you may refer to the set of addresses belonging to
a group of logical switch ports stored in the Port_Group table
by its name followed by a suffix ’_ip4’/’_ip6’. The IPv4 address
- set of a Port_Group with a name of port_group1 can be referred
- to as $port_group1_ip4, and the IPv6 address set of the same
+ set of a Port_Group with a name of port_group1 can be referred
+ to as $port_group1_ip4, and the IPv6 address set of the same
Port_Group can be referred to as $port_group1_ip6
Miscellaneous
- Comparisons may name the symbol or the constant first, e.g.
+ Comparisons may name the symbol or the constant first, e.g.
tcp.src == 80 and 80 == tcp.src are both acceptable.
- Tests for a range may be expressed using a syntax like 1024 <=
- tcp.src <= 49151, which is equivalent to 1024 <= tcp.src &&
+ Tests for a range may be expressed using a syntax like 1024 <=
+ tcp.src <= 49151, which is equivalent to 1024 <= tcp.src &&
tcp.src <= 49151.
- For a one-bit field or predicate, a mention of its name is
- equivalent to symobl == 1, e.g. vlan.present is equivalent to
- vlan.present == 1. The same is true for one-bit subfields, e.g.
- vlan.tci[12]. There is no technical limitation to implementing
- the same for ordinal fields of all widths, but the implementa‐
+ For a one-bit field or predicate, a mention of its name is
+ equivalent to symobl == 1, e.g. vlan.present is equivalent to
+ vlan.present == 1. The same is true for one-bit subfields, e.g.
+ vlan.tci[12]. There is no technical limitation to implementing
+ the same for ordinal fields of all widths, but the implementa‐
tion is expensive enough that the syntax parser requires writing
an explicit comparison against zero to make mistakes less
- likely, e.g. in tcp.src != 0 the comparison against 0 is
- required.
+ likely, e.g. in tcp.src != 0 the comparison against 0 is re‐
+ quired.
Operator precedence is as shown below, from highest to lowest.
There are two exceptions where parentheses are required even
- though the table would suggest that they are not: && and ||
- require parentheses when used together, and ! requires parenthe‐
- ses when applied to a relational expression. Thus, in (eth.type
- == 0x800 || eth.type == 0x86dd) && ip.proto == 6 or !(arp.op ==
- 1), the parentheses are mandatory.
+ though the table would suggest that they are not: && and || re‐
+ quire parentheses when used together, and ! requires parentheses
+ when applied to a relational expression. Thus, in (eth.type ==
+ 0x800 || eth.type == 0x86dd) && ip.proto == 6 or !(arp.op == 1),
+ the parentheses are mandatory.
- · ()
+ • ()
- · == != < <= > >=
+ • == != < <= > >=
- · !
+ • !
- · && ||
+ • && ||
Comments may be introduced by //, which extends to the next new-
line. Comments within a line may be bracketed by /* and */. Mul‐
@@ -917,143 +925,143 @@ Logical_Flow TABLE
Most of the symbols below have integer type. Only inport and
outport have string type. inport names a logical port. Thus, its
- value is a logical_port name from the Port_Binding table. out‐
- port may name a logical port, as inport, or a logical multicast
- group defined in the Multicast_Group table. For both symbols,
+ value is a logical_port name from the Port_Binding table. out‐
+ port may name a logical port, as inport, or a logical multicast
+ group defined in the Multicast_Group table. For both symbols,
only names within the flow’s logical datapath may be used.
- The regX symbols are 32-bit integers. The xxregX symbols are
- 128-bit integers, which overlay four of the 32-bit registers:
+ The regX symbols are 32-bit integers. The xxregX symbols are
+ 128-bit integers, which overlay four of the 32-bit registers:
xxreg0 overlays reg0 through reg3, with reg0 supplying the most-
significant bits of xxreg0 and reg3 the least-significant.
xxreg1 similarly overlays reg4 through reg7.
- · reg0...reg9
+ • reg0...reg9
- · xxreg0 xxreg1
+ • xxreg0 xxreg1
- · inport outport
+ • inport outport
- · flags.loopback
+ • flags.loopback
- · pkt.mark
+ • pkt.mark
- · eth.src eth.dst eth.type
+ • eth.src eth.dst eth.type
- · vlan.tci vlan.vid vlan.pcp vlan.present
+ • vlan.tci vlan.vid vlan.pcp vlan.present
- · ip.proto ip.dscp ip.ecn ip.ttl ip.frag
+ • ip.proto ip.dscp ip.ecn ip.ttl ip.frag
- · ip4.src ip4.dst
+ • ip4.src ip4.dst
- · ip6.src ip6.dst ip6.label
+ • ip6.src ip6.dst ip6.label
- · arp.op arp.spa arp.tpa arp.sha arp.tha
+ • arp.op arp.spa arp.tpa arp.sha arp.tha
- · rarp.op rarp.spa rarp.tpa rarp.sha rarp.tha
+ • rarp.op rarp.spa rarp.tpa rarp.sha rarp.tha
- · tcp.src tcp.dst tcp.flags
+ • tcp.src tcp.dst tcp.flags
- · udp.src udp.dst
+ • udp.src udp.dst
- · sctp.src sctp.dst
+ • sctp.src sctp.dst
- · icmp4.type icmp4.code
+ • icmp4.type icmp4.code
- · icmp6.type icmp6.code
+ • icmp6.type icmp6.code
- · nd.target nd.sll nd.tll
+ • nd.target nd.sll nd.tll
- · ct_mark ct_label
+ • ct_mark ct_label
- · ct_state, which has several Boolean subfields. The
+ • ct_state, which has several Boolean subfields. The
ct_next action initializes the following subfields:
- · ct.trk: Always set to true by ct_next to indicate
+ • ct.trk: Always set to true by ct_next to indicate
that connection tracking has taken place. All
other ct subfields have ct.trk as a prerequisite.
- · ct.new: True for a new flow
+ • ct.new: True for a new flow
- · ct.est: True for an established flow
+ • ct.est: True for an established flow
- · ct.rel: True for a related flow
+ • ct.rel: True for a related flow
- · ct.rpl: True for a reply flow
+ • ct.rpl: True for a reply flow
- · ct.inv: True for a connection entry in a bad state
+ • ct.inv: True for a connection entry in a bad state
The ct_dnat, ct_snat, and ct_lb actions initialize the
following subfields:
- · ct.dnat: True for a packet whose destination IP
+ • ct.dnat: True for a packet whose destination IP
address has been changed.
- · ct.snat: True for a packet whose source IP address
+ • ct.snat: True for a packet whose source IP address
has been changed.
The following predicates are supported:
- · eth.bcast expands to eth.dst == ff:ff:ff:ff:ff:ff
+ • eth.bcast expands to eth.dst == ff:ff:ff:ff:ff:ff
- · eth.mcast expands to eth.dst[40]
+ • eth.mcast expands to eth.dst[40]
- · vlan.present expands to vlan.tci[12]
+ • vlan.present expands to vlan.tci[12]
- · ip4 expands to eth.type == 0x800
+ • ip4 expands to eth.type == 0x800
- · ip4.src_mcast expands to ip4.src[28..31] == 0xe
+ • ip4.src_mcast expands to ip4.src[28..31] == 0xe
- · ip4.mcast expands to ip4.dst[28..31] == 0xe
+ • ip4.mcast expands to ip4.dst[28..31] == 0xe
- · ip6 expands to eth.type == 0x86dd
+ • ip6 expands to eth.type == 0x86dd
- · ip expands to ip4 || ip6
+ • ip expands to ip4 || ip6
- · icmp4 expands to ip4 && ip.proto == 1
+ • icmp4 expands to ip4 && ip.proto == 1
- · icmp6 expands to ip6 && ip.proto == 58
+ • icmp6 expands to ip6 && ip.proto == 58
- · icmp expands to icmp4 || icmp6
+ • icmp expands to icmp4 || icmp6
- · ip.is_frag expands to ip.frag[0]
+ • ip.is_frag expands to ip.frag[0]
- · ip.later_frag expands to ip.frag[1]
+ • ip.later_frag expands to ip.frag[1]
- · ip.first_frag expands to ip.is_frag && !ip.later_frag
+ • ip.first_frag expands to ip.is_frag && !ip.later_frag
- · arp expands to eth.type == 0x806
+ • arp expands to eth.type == 0x806
- · rarp expands to eth.type == 0x8035
+ • rarp expands to eth.type == 0x8035
- · nd expands to icmp6.type == {135, 136} && icmp6.code == 0
+ • nd expands to icmp6.type == {135, 136} && icmp6.code == 0
&& ip.ttl == 255
- · nd_ns expands to icmp6.type == 135 && icmp6.code == 0 &&
+ • nd_ns expands to icmp6.type == 135 && icmp6.code == 0 &&
ip.ttl == 255
- · nd_na expands to icmp6.type == 136 && icmp6.code == 0 &&
+ • nd_na expands to icmp6.type == 136 && icmp6.code == 0 &&
ip.ttl == 255
- · nd_rs expands to icmp6.type == 133 && icmp6.code == 0 &&
+ • nd_rs expands to icmp6.type == 133 && icmp6.code == 0 &&
ip.ttl == 255
- · nd_ra expands to icmp6.type == 134 && icmp6.code == 0 &&
+ • nd_ra expands to icmp6.type == 134 && icmp6.code == 0 &&
ip.ttl == 255
- · tcp expands to ip.proto == 6
+ • tcp expands to ip.proto == 6
- · udp expands to ip.proto == 17
+ • udp expands to ip.proto == 17
- · sctp expands to ip.proto == 132
+ • sctp expands to ip.proto == 132
actions: string
Logical datapath actions, to be executed when the logical flow
represented by this row is the highest-priority match.
Actions share lexical syntax with the match column. An empty set
- of actions (or one that contains just white space or comments),
- or a set of actions that consists of just drop;, causes the
+ of actions (or one that contains just white space or comments),
+ or a set of actions that consists of just drop;, causes the
matched packets to be dropped. Otherwise, the column should con‐
tain a sequence of actions, each terminated by a semicolon.
@@ -1066,13 +1074,13 @@ Logical_Flow TABLE
ticast group, the egress pipeline runs once for each log‐
ical port in the group.
- In the egress pipeline, this action performs the actual
- output to the outport logical port. (In the egress pipe‐
- line, outport never names a multicast group.)
+ In the egress pipeline, this action performs the actual
+ output to the outport logical port. (In the egress
+ pipeline, outport never names a multicast group.)
- By default, output to the input port is implicitly
- dropped, that is, output becomes a no-op if outport ==
- inport. Occasionally it may be useful to override this
+ By default, output to the input port is implicitly
+ dropped, that is, output becomes a no-op if outport ==
+ inport. Occasionally it may be useful to override this
behavior, e.g. to send an ARP reply to an ARP request; to
do so, use flags.loopback = 1 to allow the packet to
"hair-pin" back to the input port.
@@ -1083,19 +1091,19 @@ Logical_Flow TABLE
Executes the given logical datapath table in pipeline as a
subroutine. The default table is just after the current
one. If pipeline is specified, it may be ingress or egress;
- the default pipeline is the one currently executing.
- Actions in the both ingress and egress pipeline can use
- next to jump across the other pipeline. Actions in the
- ingress pipeline should use next to jump into the specific
- table of egress pipeline only if it is certain that the
- packets are local and not tunnelled and wants to skip cer‐
- tain stages in the packet processing.
+ the default pipeline is the one currently executing. Ac‐
+ tions in the both ingress and egress pipeline can use next
+ to jump across the other pipeline. Actions in the ingress
+ pipeline should use next to jump into the specific table of
+ egress pipeline only if it is certain that the packets are
+ local and not tunnelled and wants to skip certain stages in
+ the packet processing.
field = constant;
- Sets data or metadata field field to constant value con‐
- stant, e.g. outport = "vif0"; to set the logical output
- port. To set only a subset of bits in a field, specify a
- subfield for field or a masked constant, e.g. one may use
+ Sets data or metadata field field to constant value con‐
+ stant, e.g. outport = "vif0"; to set the logical output
+ port. To set only a subset of bits in a field, specify a
+ subfield for field or a masked constant, e.g. one may use
vlan.pcp[2] = 1; or vlan.pcp = 4/4; to set the most signif‐
icant bit of the VLAN PCP.
@@ -1118,30 +1126,30 @@ Logical_Flow TABLE
Below are the supported OVN fields:
- · icmp4.frag_mtu icmp6.frag_mtu
+ • icmp4.frag_mtu icmp6.frag_mtu
This field sets the low-order 16 bits of the
- ICMP{4,6} header field that is labelled "unused" in
- the ICMP specification as defined in the RFC 1191
+ ICMP{4,6} header field that is labelled "unused" in
+ the ICMP specification as defined in the RFC 1191
with the value specified in constant.
Eg. icmp4.frag_mtu = 1500;
field1 = field2;
- Sets data or metadata field field1 to the value of data or
- metadata field field2, e.g. reg0 = ip4.src; copies ip4.src
+ Sets data or metadata field field1 to the value of data or
+ metadata field field2, e.g. reg0 = ip4.src; copies ip4.src
into reg0. To modify only a subset of a field’s bits, spec‐
ify a subfield for field1 or field2 or both, e.g. vlan.pcp
= reg0[0..2]; copies the least-significant bits of reg0
into the VLAN PCP.
field1 and field2 must be the same type, either both string
- or both integer fields. If they are both integer fields,
+ or both integer fields. If they are both integer fields,
they must have the same width.
- If field1 or field2 has prerequisites, they are added
- implicitly to match. It is possible to write an assignment
- with contradictory prerequisites, such as ip4.src =
+ If field1 or field2 has prerequisites, they are added im‐
+ plicitly to match. It is possible to write an assignment
+ with contradictory prerequisites, such as ip4.src =
ip6.src[0..31];, but the contradiction means that a logical
flow with such an assignment will never be matched.
@@ -1159,8 +1167,8 @@ Logical_Flow TABLE
ip.ttl--;
Decrements the IPv4 or IPv6 TTL. If this would make the TTL
- zero or negative, then processing of the packet halts; no
- further actions are processed. (To properly handle such
+ zero or negative, then processing of the packet halts; no
+ further actions are processed. (To properly handle such
cases, a higher-priority flow should match on ip.ttl == {0,
1};.)
@@ -1173,16 +1181,16 @@ Logical_Flow TABLE
As a side effect, IP fragments will be reassembled for
matching. If a fragmented packet is output, then it will be
- sent with any overlapping fragments squashed. The connec‐
- tion tracking state is scoped by the logical port when the
- action is used in a flow for a logical switch, so overlap‐
+ sent with any overlapping fragments squashed. The connec‐
+ tion tracking state is scoped by the logical port when the
+ action is used in a flow for a logical switch, so overlap‐
ping addresses may be used. To allow traffic related to the
matched flow, execute ct_commit . Connection tracking state
- is scoped by the logical topology when the action is used
+ is scoped by the logical topology when the action is used
in a flow for a router.
- It is possible to have actions follow ct_next, but they
- will not have access to any of its side-effects and is not
+ It is possible to have actions follow ct_next, but they
+ will not have access to any of its side-effects and is not
generally useful.
ct_commit { };
@@ -1197,8 +1205,8 @@ Logical_Flow TABLE
ct_mark is a 32-bit field. ct_label is a 128-bit field. The
value[/mask] should be specified in hex string if more than
64bits are to be used. Registers and other named fields can
- be used for value. ct_mark and ct_label may be sub-
- addressed in order to have specific bits set.
+ be used for value. ct_mark and ct_label may be sub-ad‐
+ dressed in order to have specific bits set.
Note that if you want processing to continue in the next
table, you must execute the next action after ct_commit.
@@ -1211,29 +1219,29 @@ Logical_Flow TABLE
ct_dnat(IP);
ct_dnat sends the packet through the DNAT zone in connec‐
tion tracking table to unDNAT any packet that was DNATed in
- the opposite direction. The packet is then automatically
- sent to to the next tables as if followed by next; action.
- The next tables will see the changes in the packet caused
+ the opposite direction. The packet is then automatically
+ sent to to the next tables as if followed by next; action.
+ The next tables will see the changes in the packet caused
by the connection tracker.
- ct_dnat(IP) sends the packet through the DNAT zone to
- change the destination IP address of the packet to the one
+ ct_dnat(IP) sends the packet through the DNAT zone to
+ change the destination IP address of the packet to the one
provided inside the parentheses and commits the connection.
The packet is then automatically sent to the next tables as
- if followed by next; action. The next tables will see the
+ if followed by next; action. The next tables will see the
changes in the packet caused by the connection tracker.
ct_snat;
ct_snat(IP);
- ct_snat sends the packet through the SNAT zone to unSNAT
- any packet that was SNATed in the opposite direction. The
- packet is automatically sent to the next tables as if fol‐
- lowed by the next; action. The next tables will see the
+ ct_snat sends the packet through the SNAT zone to unSNAT
+ any packet that was SNATed in the opposite direction. The
+ packet is automatically sent to the next tables as if fol‐
+ lowed by the next; action. The next tables will see the
changes in the packet caused by the connection tracker.
- ct_snat(IP) sends the packet through the SNAT zone to
- change the source IP address of the packet to the one pro‐
- vided inside the parenthesis and commits the connection.
+ ct_snat(IP) sends the packet through the SNAT zone to
+ change the source IP address of the packet to the one pro‐
+ vided inside the parenthesis and commits the connection.
The packet is then automatically sent to the next tables as
if followed by next; action. The next tables will see the
changes in the packet caused by the connection tracker.
@@ -1250,25 +1258,25 @@ Logical_Flow TABLE
ct_dnat_in_czone(IP) sends the packet through the common
NAT zone to change the destination IP address of the packet
- to the one provided inside the parentheses and commits the
- connection. The packet is then automatically sent to the
+ to the one provided inside the parentheses and commits the
+ connection. The packet is then automatically sent to the
next tables as if followed by next; action. The next tables
will see the changes in the packet caused by the connection
tracker.
ct_snat_in_czone;
ct_snat_in_czone(IP);
- ct_snat_in_czone sends the packet through the common NAT
- zone to unSNAT any packet that was SNATed in the opposite
- direction. The packet is automatically sent to the next
- tables as if followed by the next; action. The next tables
+ ct_snat_in_czone sends the packet through the common NAT
+ zone to unSNAT any packet that was SNATed in the opposite
+ direction. The packet is automatically sent to the next ta‐
+ bles as if followed by the next; action. The next tables
will see the changes in the packet caused by the connection
tracker.
- ct_snat_in_czone(IP) sends the packet\ through the common
- NAT zone to change the source IP address of the packet to
- the one provided inside the parenthesis and commits the
- connection. The packet is then automatically sent to the
+ ct_snat_in_czone(IP) sends the packet\ through the common
+ NAT zone to change the source IP address of the packet to
+ the one provided inside the parenthesis and commits the
+ connection. The packet is then automatically sent to the
next tables as if followed by next; action. The next tables
will see the changes in the packet caused by the connection
tracker.
@@ -1285,8 +1293,8 @@ Logical_Flow TABLE
clone { action; ... };
Makes a copy of the packet being processed and executes
- each action on the copy. Actions following the clone
- action, if any, apply to the original, unmodified packet.
+ each action on the copy. Actions following the clone ac‐
+ tion, if any, apply to the original, unmodified packet.
This can be used as a way to ``save and restore’’ the
packet around a set of actions that may modify it and
should not persist.
@@ -1299,67 +1307,67 @@ Logical_Flow TABLE
The ARP packet that this action operates on is initialized
based on the IPv4 packet being processed, as follows. These
- are default values that the nested actions will probably
+ are default values that the nested actions will probably
want to change:
- · eth.src unchanged
+ • eth.src unchanged
- · eth.dst unchanged
+ • eth.dst unchanged
- · eth.type = 0x0806
+ • eth.type = 0x0806
- · arp.op = 1 (ARP request)
+ • arp.op = 1 (ARP request)
- · arp.sha copied from eth.src
+ • arp.sha copied from eth.src
- · arp.spa copied from ip4.src
+ • arp.spa copied from ip4.src
- · arp.tha = 00:00:00:00:00:00
+ • arp.tha = 00:00:00:00:00:00
- · arp.tpa copied from ip4.dst
+ • arp.tpa copied from ip4.dst
- The ARP packet has the same VLAN header, if any, as the IP
+ The ARP packet has the same VLAN header, if any, as the IP
packet it replaces.
Prerequisite: ip4
get_arp(P, A);
- Parameters: logical port string field P, 32-bit IP address
+ Parameters: logical port string field P, 32-bit IP address
field A.
- Looks up A in P’s mac binding table. If an entry is found,
- stores its Ethernet address in eth.dst, otherwise stores
+ Looks up A in P’s mac binding table. If an entry is found,
+ stores its Ethernet address in eth.dst, otherwise stores
00:00:00:00:00:00 in eth.dst.
Example: get_arp(outport, ip4.dst);
put_arp(P, A, E);
- Parameters: logical port string field P, 32-bit IP address
+ Parameters: logical port string field P, 32-bit IP address
field A, 48-bit Ethernet address field E.
- Adds or updates the entry for IP address A in logical port
+ Adds or updates the entry for IP address A in logical port
P’s mac binding table, setting its Ethernet address to E.
Example: put_arp(inport, arp.spa, arp.sha);
R = lookup_arp(P, A, M);
- Parameters: logical port string field P, 32-bit IP address
+ Parameters: logical port string field P, 32-bit IP address
field A, 48-bit MAC address field M.
Result: stored to a 1-bit subfield R.
- Looks up A and M in P’s mac binding table. If an entry is
+ Looks up A and M in P’s mac binding table. If an entry is
found, stores 1 in the 1-bit subfield R, else 0.
Example: reg0[0] = lookup_arp(inport, arp.spa, arp.sha);
R = lookup_arp_ip(P, A);
- Parameters: logical port string field P, 32-bit IP address
+ Parameters: logical port string field P, 32-bit IP address
field A.
Result: stored to a 1-bit subfield R.
- Looks up A in P’s mac binding table. If an entry is found,
+ Looks up A in P’s mac binding table. If an entry is found,
stores 1 in the 1-bit subfield R, else 0.
Example: reg0[0] = lookup_arp_ip(inport, arp.spa);
@@ -1367,7 +1375,7 @@ Logical_Flow TABLE
P = get_fdb(A);
Parameters:48-bit MAC address field A.
- Looks up A in fdb table. If an entry is found, stores the
+ Looks up A in fdb table. If an entry is found, stores the
logical port key to the out parameter P.
Example: outport = get_fdb(eth.src);
@@ -1387,9 +1395,11 @@ Logical_Flow TABLE
Result: stored to a 1-bit subfield R.
- Looks up A in fdb table. If an entry is found and the the
- logical port key is P, P, stores 1 in the 1-bit subfield R,
- else 0.
+ Looks up A in fdb table. If an entry is found and the logi‐
+ cal port key is P, P, stores 1 in the 1-bit subfield R,
+ else 0. If flags.localnet is set then 1 is stored if an en‐
+ try is found and the logical port key is P or if an entry
+ is found and the entry port type is VIF.
Example: reg0[0] = lookup_fdb(inport, eth.src);
@@ -1400,23 +1410,23 @@ Logical_Flow TABLE
action, if any, apply to the original, unmodified packet.
The IPv6 NS packet that this action operates on is initial‐
- ized based on the IPv6 packet being processed, as follows.
+ ized based on the IPv6 packet being processed, as follows.
These are default values that the nested actions will prob‐
ably want to change:
- · eth.src unchanged
+ • eth.src unchanged
- · eth.dst set to IPv6 multicast MAC address
+ • eth.dst set to IPv6 multicast MAC address
- · eth.type = 0x86dd
+ • eth.type = 0x86dd
- · ip6.src copied from ip6.src
+ • ip6.src copied from ip6.src
- · ip6.dst set to IPv6 Solicited-Node multicast address
+ • ip6.dst set to IPv6 Solicited-Node multicast address
- · icmp6.type = 135 (Neighbor Solicitation)
+ • icmp6.type = 135 (Neighbor Solicitation)
- · nd.target copied from ip6.dst
+ • nd.target copied from ip6.dst
The IPv6 NS packet has the same VLAN header, if any, as the
IP packet it replaces.
@@ -1424,32 +1434,32 @@ Logical_Flow TABLE
Prerequisite: ip6
nd_na { action; ... };
- Temporarily replaces the IPv6 neighbor solicitation packet
- being processed by an IPv6 neighbor advertisement (NA)
- packet and executes each nested action on the NA packet.
- Actions following the nd_na action, if any, apply to the
+ Temporarily replaces the IPv6 neighbor solicitation packet
+ being processed by an IPv6 neighbor advertisement (NA)
+ packet and executes each nested action on the NA packet.
+ Actions following the nd_na action, if any, apply to the
original, unmodified packet.
- The NA packet that this action operates on is initialized
+ The NA packet that this action operates on is initialized
based on the IPv6 packet being processed, as follows. These
are default values that the nested actions will probably
want to change:
- · eth.dst exchanged with eth.src
+ • eth.dst exchanged with eth.src
- · eth.type = 0x86dd
+ • eth.type = 0x86dd
- · ip6.dst copied from ip6.src
+ • ip6.dst copied from ip6.src
- · ip6.src copied from nd.target
+ • ip6.src copied from nd.target
- · icmp6.type = 136 (Neighbor Advertisement)
+ • icmp6.type = 136 (Neighbor Advertisement)
- · nd.target unchanged
+ • nd.target unchanged
- · nd.sll = 00:00:00:00:00:00
+ • nd.sll = 00:00:00:00:00:00
- · nd.tll copied from eth.dst
+ • nd.tll copied from eth.dst
The ND packet has the same VLAN header, if any, as the IPv6
packet it replaces.
@@ -1457,33 +1467,33 @@ Logical_Flow TABLE
Prerequisite: nd_ns
nd_na_router { action; ... };
- Temporarily replaces the IPv6 neighbor solicitation packet
- being processed by an IPv6 neighbor advertisement (NA)
- packet, sets ND_NSO_ROUTER in the RSO flags and executes
- each nested action on the NA packet. Actions following the
+ Temporarily replaces the IPv6 neighbor solicitation packet
+ being processed by an IPv6 neighbor advertisement (NA)
+ packet, sets ND_NSO_ROUTER in the RSO flags and executes
+ each nested action on the NA packet. Actions following the
nd_na_router action, if any, apply to the original, unmodi‐
fied packet.
The NA packet that this action operates on is initialized
based on the IPv6 packet being processed, as follows. These
- are default values that the nested actions will probably
+ are default values that the nested actions will probably
want to change:
- · eth.dst exchanged with eth.src
+ • eth.dst exchanged with eth.src
- · eth.type = 0x86dd
+ • eth.type = 0x86dd
- · ip6.dst copied from ip6.src
+ • ip6.dst copied from ip6.src
- · ip6.src copied from nd.target
+ • ip6.src copied from nd.target
- · icmp6.type = 136 (Neighbor Advertisement)
+ • icmp6.type = 136 (Neighbor Advertisement)
- · nd.target unchanged
+ • nd.target unchanged
- · nd.sll = 00:00:00:00:00:00
+ • nd.sll = 00:00:00:00:00:00
- · nd.tll copied from eth.dst
+ • nd.tll copied from eth.dst
The ND packet has the same VLAN header, if any, as the IPv6
packet it replaces.
@@ -1491,8 +1501,8 @@ Logical_Flow TABLE
Prerequisite: nd_ns
get_nd(P, A);
- Parameters: logical port string field P, 128-bit IPv6
- address field A.
+ Parameters: logical port string field P, 128-bit IPv6 ad‐
+ dress field A.
Looks up A in P’s mac binding table. If an entry is found,
stores its Ethernet address in eth.dst, otherwise stores
@@ -1501,8 +1511,8 @@ Logical_Flow TABLE
Example: get_nd(outport, ip6.dst);
put_nd(P, A, E);
- Parameters: logical port string field P, 128-bit IPv6
- address field A, 48-bit Ethernet address field E.
+ Parameters: logical port string field P, 128-bit IPv6 ad‐
+ dress field A, 48-bit Ethernet address field E.
Adds or updates the entry for IPv6 address A in logical
port P’s mac binding table, setting its Ethernet address to
@@ -1527,7 +1537,7 @@ Logical_Flow TABLE
Result: stored to a 1-bit subfield R.
- Looks up A in P’s mac binding table. If an entry is found,
+ Looks up A in P’s mac binding table. If an entry is found,
stores 1 in the 1-bit subfield R, else 0.
Example: reg0[0] = lookup_nd_ip(inport, ip6.src);
@@ -1542,16 +1552,16 @@ Logical_Flow TABLE
When this action is applied to a DHCP request packet
(DHCPDISCOVER or DHCPREQUEST), it changes the packet into a
- DHCP reply (DHCPOFFER or DHCPACK, respectively), replaces
- the options by those specified as parameters, and stores 1
+ DHCP reply (DHCPOFFER or DHCPACK, respectively), replaces
+ the options by those specified as parameters, and stores 1
in R.
- When this action is applied to a non-DHCP packet or a DHCP
- packet that is not DHCPDISCOVER or DHCPREQUEST, it leaves
+ When this action is applied to a non-DHCP packet or a DHCP
+ packet that is not DHCPDISCOVER or DHCPREQUEST, it leaves
the packet unchanged and stores 0 in R.
- The contents of the DHCP_Option table control the DHCP
- option names and values that this action supports.
+ The contents of the DHCP_Option table control the DHCP op‐
+ tion names and values that this action supports.
Example: reg0[0] = put_dhcp_opts(offerip = 10.0.0.2, router
= 10.0.0.1, netmask = 255.255.255.0, dns_server = {8.8.8.8,
@@ -1564,32 +1574,31 @@ Logical_Flow TABLE
Valid only in the ingress pipeline.
- When this action is applied to a DHCPv6 request packet, it
- changes the packet into a DHCPv6 reply, replaces the
- options by those specified as parameters, and stores 1 in
- R.
+ When this action is applied to a DHCPv6 request packet, it
+ changes the packet into a DHCPv6 reply, replaces the op‐
+ tions by those specified as parameters, and stores 1 in R.
When this action is applied to a non-DHCPv6 packet or an
- invalid DHCPv6 request packet , it leaves the packet
- unchanged and stores 0 in R.
+ invalid DHCPv6 request packet , it leaves the packet un‐
+ changed and stores 0 in R.
The contents of the DHCPv6_Options table control the DHCPv6
option names and values that this action supports.
- Example: reg0[3] = put_dhcpv6_opts(ia_addr = aef0::4,
- server_id = 00:00:00:00:10:02,
+ Example: reg0[3] = put_dhcpv6_opts(ia_addr = aef0::4,
+ server_id = 00:00:00:00:10:02,
dns_server={ae70::1,ae70::2});
set_queue(queue_number);
- Parameters: Queue number queue_number, in the range 0 to
+ Parameters: Queue number queue_number, in the range 0 to
61440.
- This is a logical equivalent of the OpenFlow set_queue
- action. It affects packets that egress a hypervisor through
- a physical interface. For nonzero queue_number, it config‐
- ures packet queuing to match the settings configured for
- the Port_Binding with options:qdisc_queue_id matching
- queue_number. When queue_number is zero, it resets queuing
+ This is a logical equivalent of the OpenFlow set_queue ac‐
+ tion. It affects packets that egress a hypervisor through a
+ physical interface. For nonzero queue_number, it configures
+ packet queuing to match the settings configured for the
+ Port_Binding with options:qdisc_queue_id matching
+ queue_number. When queue_number is zero, it resets queuing
to the default strategy.
Example: set_queue(10);
@@ -1598,28 +1607,28 @@ Logical_Flow TABLE
ct_lb(backends=ip[:port][,...][;
hash_fields=field1,field2,...][; ct_flag]);
With arguments, ct_lb commits the packet to the connection
- tracking table and DNATs the packet’s destination IP
- address (and port) to the IP address or addresses (and
- optional ports) specified in the backends. If multiple
- comma-separated IP addresses are specified, each is given
- equal weight for picking the DNAT address. By default,
- dp_hash is used as the OpenFlow group selection method, but
- if hash_fields is specified, hash is used as the selection
+ tracking table and DNATs the packet’s destination IP ad‐
+ dress (and port) to the IP address or addresses (and op‐
+ tional ports) specified in the backends. If multiple comma-
+ separated IP addresses are specified, each is given equal
+ weight for picking the DNAT address. By default, dp_hash is
+ used as the OpenFlow group selection method, but if
+ hash_fields is specified, hash is used as the selection
method, and the fields listed are used as the hash fields.
The ct_flag field represents one of supported flag:
- skip_snat or force_snat, this flag will be stored in
- ct_label register.
+ skip_snat or force_snat, this flag will be stored in ct_la‐
+ bel register.
Without arguments, ct_lb sends the packet to the connection
tracking table to NAT the packets. If the packet is part of
- an established connection that was previously committed to
- the connection tracker via ct_lb(...), it will automati‐
+ an established connection that was previously committed to
+ the connection tracker via ct_lb(...), it will automati‐
cally get DNATed to the same IP address as the first packet
in that connection.
Processing automatically moves on to the next table, as if
next; were specified, and later tables act on the packet as
- modified by the connection tracker. Connection tracking
+ modified by the connection tracker. Connection tracking
state is scoped by the logical port when the action is used
in a flow for a logical switch, so overlapping addresses
may be used. Connection tracking state is scoped by the
@@ -1629,8 +1638,8 @@ Logical_Flow TABLE
ct_lb_mark;
ct_lb_mark(backends=ip[:port][,...][;
hash_fields=field1,field2,...][; ct_flag]);
- Same as ct_lb, except that it internally uses ct_mark to
- store the NAT flag, while ct_lb uses ct_label for the same
+ Same as ct_lb, except that it internally uses ct_mark to
+ store the NAT flag, while ct_lb uses ct_label for the same
purpose.
R = dns_lookup();
@@ -1640,18 +1649,18 @@ Logical_Flow TABLE
Valid only in the ingress pipeline.
- When this action is applied to a valid DNS request (a UDP
- packet typically directed to port 53), it attempts to
- resolve the query using the contents of the DNS table. If
- it is successful, it changes the packet into a DNS reply
- and stores 1 in R. If the action is applied to a non-DNS
- packet, an invalid DNS request packet, or a valid DNS
- request for which the DNS table does not supply an answer,
- it leaves the packet unchanged and stores 0 in R.
+ When this action is applied to a valid DNS request (a UDP
+ packet typically directed to port 53), it attempts to re‐
+ solve the query using the contents of the DNS table. If it
+ is successful, it changes the packet into a DNS reply and
+ stores 1 in R. If the action is applied to a non-DNS
+ packet, an invalid DNS request packet, or a valid DNS re‐
+ quest for which the DNS table does not supply an answer, it
+ leaves the packet unchanged and stores 0 in R.
Regardless of success, the action does not make any of the
changes to the flow that are necessary to direct the packet
- back to the requester. The logical pipeline can implement
+ back to the requester. The logical pipeline can implement
this behavior with matches and actions in later tables.
Example: reg0[3] = dns_lookup();
@@ -1659,10 +1668,10 @@ Logical_Flow TABLE
Prerequisite: udp
R = put_nd_ra_opts(D1 = V1, D2 = V2, ..., Dn = Vn);
- Parameters: The following IPv6 ND Router Advertisement
- option/value pairs as defined in RFC 4861.
+ Parameters: The following IPv6 ND Router Advertisement op‐
+ tion/value pairs as defined in RFC 4861.
- · addr_mode
+ • addr_mode
Mandatory parameter which specifies the address mode
flag to be set in the RA flag options field. The
@@ -1670,23 +1679,23 @@ Logical_Flow TABLE
values can be defined - "slaac", "dhcpv6_stateful"
and "dhcpv6_stateless".
- · slla
+ • slla
Mandatory parameter which specifies the link-layer
- address of the interface from which the Router
- Advertisement is sent.
+ address of the interface from which the Router Ad‐
+ vertisement is sent.
- · mtu
+ • mtu
Optional parameter which specifies the MTU.
- · prefix
+ • prefix
Optional parameter which should be specified if the
addr_mode is "slaac" or "dhcpv6_stateless". The
value should be an IPv6 prefix which will be used
- for stateless IPv6 address configuration. This
- option can be defined multiple times.
+ for stateless IPv6 address configuration. This op‐
+ tion can be defined multiple times.
Result: stored to a 1-bit subfield R.
@@ -1706,7 +1715,7 @@ Logical_Flow TABLE
set_meter(rate);
set_meter(rate, burst);
- Parameters: rate limit int field rate in kbps, burst rate
+ Parameters: rate limit int field rate in kbps, burst rate
limits int field burst in kbps.
This action sets the rate limit for a flow.
@@ -1718,47 +1727,47 @@ Logical_Flow TABLE
Result: stored to a 1-bit subfield R.
- This is a logical equivalent of the OpenFlow
- check_pkt_larger action. If the packet is larger than the
+ This is a logical equivalent of the OpenFlow
+ check_pkt_larger action. If the packet is larger than the
length specified in L, it stores 1 in the subfield R.
Example: reg0[6] = check_pkt_larger(1000);
log(key=value, ...);
- Causes ovn-controller to log the packet on the chassis
+ Causes ovn-controller to log the packet on the chassis
that processes it. Packet logging currently uses the same
logging mechanism as other Open vSwitch and OVN messages,
- which means that whether and where log messages appear
- depends on the local logging configuration that can be
+ which means that whether and where log messages appear
+ depends on the local logging configuration that can be
configured with ovs-appctl, etc.
- The log action takes zero or more of the following key-
+ The log action takes zero or more of the following key-
value pair arguments that control what is logged:
name=string
- An optional name for the ACL. The string is cur‐
+ An optional name for the ACL. The string is cur‐
rently limited to 64 bytes.
severity=level
- Indicates the severity of the event. The level is
- one of following (from more to less serious):
- alert, warning, notice, info, or debug. If a
+ Indicates the severity of the event. The level is
+ one of following (from more to less serious):
+ alert, warning, notice, info, or debug. If a
severity is not provided, the default is info.
verdict=value
- The verdict for packets matching the flow. The
+ The verdict for packets matching the flow. The
value must be one of allow, deny, or reject.
meter=string
- An optional rate-limiting meter to be applied to
+ An optional rate-limiting meter to be applied to
the logs. The string should reference a name entry
from the Meter table. The only meter action that
is appropriate is drop.
fwd_group(liveness=bool, childports=port, ...);
- Parameters: optional liveness, either true or false,
- defaulting to false; childports, a comma-delimited list
- of strings denoting logical ports to load balance across.
+ Parameters: optional liveness, either true or false, de‐
+ faulting to false; childports, a comma-delimited list of
+ strings denoting logical ports to load balance across.
Load balance traffic to one or more child ports in a log‐
ical switch. ovn-controller translates the fwd_group into
@@ -1773,24 +1782,24 @@ Logical_Flow TABLE
icmp4_error { action; ... };
Temporarily replaces the IPv4 packet being processed by an
ICMPv4 packet and executes each nested action on the ICMPv4
- packet. Actions following these actions, if any, apply to
+ packet. Actions following these actions, if any, apply to
the original, unmodified packet.
- The ICMPv4 packet that these actions operates on is ini‐
- tialized based on the IPv4 packet being processed, as fol‐
+ The ICMPv4 packet that these actions operates on is ini‐
+ tialized based on the IPv4 packet being processed, as fol‐
lows. These are default values that the nested actions will
probably want to change. Ethernet and IPv4 fields not
listed here are not changed:
- · ip.proto = 1 (ICMPv4)
+ • ip.proto = 1 (ICMPv4)
- · ip.frag = 0 (not a fragment)
+ • ip.frag = 0 (not a fragment)
- · ip.ttl = 255
+ • ip.ttl = 255
- · icmp4.type = 3 (destination unreachable)
+ • icmp4.type = 3 (destination unreachable)
- · icmp4.code = 1 (host unreachable)
+ • icmp4.code = 1 (host unreachable)
icmp4_error action is expected to be used to generate an
ICMPv4 packet in response to an error in original IP
@@ -1804,22 +1813,22 @@ Logical_Flow TABLE
icmp6_error { action; ... };
Temporarily replaces the IPv6 packet being processed by an
ICMPv6 packet and executes each nested action on the ICMPv6
- packet. Actions following the icmp6 action, if any, apply
+ packet. Actions following the icmp6 action, if any, apply
to the original, unmodified packet.
- The ICMPv6 packet that this action operates on is initial‐
- ized based on the IPv6 packet being processed, as follows.
+ The ICMPv6 packet that this action operates on is initial‐
+ ized based on the IPv6 packet being processed, as follows.
These are default values that the nested actions will prob‐
ably want to change. Ethernet and IPv6 fields not listed
here are not changed:
- · ip.proto = 58 (ICMPv6)
+ • ip.proto = 58 (ICMPv6)
- · ip.ttl = 255
+ • ip.ttl = 255
- · icmp6.type = 1 (destination unreachable)
+ • icmp6.type = 1 (destination unreachable)
- · icmp6.code = 1 (administratively prohibited)
+ • icmp6.code = 1 (administratively prohibited)
icmp6_error action is expected to be used to generate an
ICMPv6 packet in response to an error in original IPv6
@@ -1845,27 +1854,27 @@ Logical_Flow TABLE
Prerequisite: tcp
reject { action; ... };
- If the original packet is IPv4 or IPv6 TCP packet, it
- replaces it with IPv4 or IPv6 TCP RST packet and executes
- the inner actions. Otherwise it replaces it with an ICMPv4
- or ICMPv6 packet and executes the inner actions.
+ If the original packet is IPv4 or IPv6 TCP packet, it re‐
+ places it with IPv4 or IPv6 TCP RST packet and executes the
+ inner actions. Otherwise it replaces it with an ICMPv4 or
+ ICMPv6 packet and executes the inner actions.
- The inner actions should not attempt to swap eth source
- with eth destination and IP source with IP destination as
+ The inner actions should not attempt to swap eth source
+ with eth destination and IP source with IP destination as
this action implicitly does that.
trigger_event;
- This action is used to allow ovs-vswitchd to report CMS
- related events writing them in Controller_Event table. It
- is possible to associate a meter to a each event in order
- to not overload pinctrl thread under heavy load; each meter
- is identified though a defined naming convention. Supported
+ This action is used to allow ovs-vswitchd to report CMS re‐
+ lated events writing them in Controller_Event table. It is
+ possible to associate a meter to a each event in order to
+ not overload pinctrl thread under heavy load; each meter is
+ identified though a defined naming convention. Supported
events:
- · empty_lb_backends. This event is raised if a
- received packet is destined for a load balancer VIP
- that has no configured backend destinations. For
- this event, the event info includes the load bal‐
+ • empty_lb_backends. This event is raised if a re‐
+ ceived packet is destined for a load balancer VIP
+ that has no configured backend destinations. For
+ this event, the event info includes the load bal‐
ancer VIP, the load balancer UUID, and the transport
protocol. Associated meter: event-elb
@@ -1880,7 +1889,7 @@ Logical_Flow TABLE
logical port string field P.
Binds the virtual logical port V and sets the chassis col‐
- umn and virtual_parent of the table Port_Binding. vir‐
+ umn and virtual_parent of the table Port_Binding. vir‐
tual_parent is set to P.
handle_svc_check(P);
@@ -1896,9 +1905,9 @@ Logical_Flow TABLE
handle_dhcpv6_reply;
Handle DHCPv6 prefix delegation advertisements/replies from
- a IPv6 delegation server. ovn-controller will add an entry
- ipv6_ra_pd_list in the options table for each prefix
- received from the delegation server
+ a IPv6 delegation server. ovn-controller will add an entry
+ ipv6_ra_pd_list in the options table for each prefix re‐
+ ceived from the delegation server
R = select(N1[=W1], N2[=W2], ...);
Parameters: Integer N1, N2..., with optional weight W1, W2,
@@ -1908,26 +1917,26 @@ Logical_Flow TABLE
Select from a list of integers N1, N2..., each within the
range 0 ~ 65535, and store the selected one in the field R.
- There must be 2 or more integers listed, each with an
- optional weight, which is an integer within the range 1 ~
- 65535. If weight is not specified, it defaults to 100. The
- selection method is based on the 5-tuple hash of packet
+ There must be 2 or more integers listed, each with an op‐
+ tional weight, which is an integer within the range 1 ~
+ 65535. If weight is not specified, it defaults to 100. The
+ selection method is based on the 5-tuple hash of packet
header.
- Processing automatically moves on to the next table, as if
- next; were specified. The select action must be put as the
- last action of the logical flow when there are multiple
- actions (actions put after select will not take effect).
+ Processing automatically moves on to the next table, as if
+ next; were specified. The select action must be put as the
+ last action of the logical flow when there are multiple ac‐
+ tions (actions put after select will not take effect).
Example: reg8[16..31] = select(1=20, 2=30, 3=50);
handle_dhcpv6_reply;
This action is used to parse DHCPv6 replies from IPv6 Dele‐
- gation Router and managed IPv6 Prefix delegation state
- machine
+ gation Router and managed IPv6 Prefix delegation state ma‐
+ chine
R = chk_lb_hairpin();
- This action checks if the packet under consideration was
+ This action checks if the packet under consideration was
destined to a load balancer VIP and it is hairpinned, i.e.,
after load balancing the destination IP matches the source
IP. If it is so, then the 1-bit destination register R is
@@ -1942,13 +1951,13 @@ Logical_Flow TABLE
R = ct_snat_to_vip;
This action sends the packet through the SNAT zone to
change the source IP address of the packet to the load bal‐
- ancer VIP if the original destination IP was load balancer
- VIP and commits the connection. This action applies suc‐
+ ancer VIP if the original destination IP was load balancer
+ VIP and commits the connection. This action applies suc‐
cessfully only for the hairpinned traffic i.e if the action
chk_lb_hairpin returned success. This action doesn’t take
any arguments and it determines the SNAT IP internally. The
- packet is not automatically sent to the next table. The
- caller has to execute the next; action explicitly after
+ packet is not automatically sent to the next table. The
+ caller has to execute the next; action explicitly after
this action to advance the packet to the next stage.
R = check_in_port_sec();
@@ -1965,12 +1974,12 @@ Logical_Flow TABLE
R = check_out_port_sec();
This action checks if the packet under consideration passes
- the outport port security checks. If the packet fails the
- port security checks, then 1 is stored in the destination
- register R. Else 0 is stored. The port security values to
+ the outport port security checks. If the packet fails the
+ port security checks, then 1 is stored in the destination
+ register R. Else 0 is stored. The port security values to
check are retrieved from the the outport logical port.
- This action should be used in the egress logical switch
+ This action should be used in the egress logical switch
pipeline.
Example: reg8[0..7] = check_out_port_sec();
@@ -1978,15 +1987,15 @@ Logical_Flow TABLE
commit_ecmp_nh(ipv6);
Parameters: IPv4/IPv6 traffic.
- This action translates to an openflow "learn" action that
+ This action translates to an openflow "learn" action that
inserts two new flows in tables 76 and 77.
- · Match on the the 5-tuple and the expected next-hop
- mac address in table 76: nw_src=ip0, nw_dst=ip1,
+ • Match on the the 5-tuple and the expected next-hop
+ mac address in table 76: nw_src=ip0, nw_dst=ip1,
ip_proto,tp_src=l4_port0,
tp_dst=l4_port1,dl_src=ethaddr and set reg9[5].
- · Match on the 5-tuple in table 77: nw_src=ip1,
+ • Match on the 5-tuple in table 77: nw_src=ip1,
nw_dst=ip0, ip_proto, tp_src=l4_port1,
tp_dst=l4_port0 and set reg9[5] to 1
@@ -1995,87 +2004,91 @@ Logical_Flow TABLE
R = check_ecmp_nh_mac();
This action checks if the packet under consideration
- matches any flow in table 76. If it is so, then the 1-bit
+ matches any flow in table 76. If it is so, then the 1-bit
destination register R is set to 1.
R = check_ecmp_nh();
This action checks if the packet under consideration
- matches the any flow in table 77. If it is so, then the
+ matches the any flow in table 77. If it is so, then the
1-bit destination register R is set to 1.
- commit_lb_aff(vip, backend, proto, timeout); Parameters:
- load-balancer virtual ip:port vip, load-balancer backend
- ip:port backend, load-balancer protocol proto, affinity
+ commit_lb_aff(vip, backend, proto, timeout); Parameters:
+ load-balancer virtual ip:port vip, load-balancer backend
+ ip:port backend, load-balancer protocol proto, affinity
timeout timeout.
- This action translates to an openflow "learn" action that
+ This action translates to an openflow "learn" action that
inserts a new flow in table 78.
- · Match on the 4-tuple in table 78: nw_src=ip client,
- nw_dst=vip ip, ip_proto, tp_dst=vip port and set
- reg9[6] to 1, reg4 and reg8 to backend ip and port
- respectively. For IPv6 register xxreg1 is used to
+ • Match on the 4-tuple in table 78: nw_src=ip client,
+ nw_dst=vip ip, ip_proto, tp_dst=vip port and set
+ reg9[6] to 1, reg4 and reg8 to backend ip and port
+ respectively. For IPv6 register xxreg1 is used to
store the backend ip.
- This action is applied for new connections received by a
+ This action is applied for new connections received by a
specific load-balacer with affinity timeout configured.
R = chk_lb_aff();
This action checks if the packet under consideration
- matches any flow in table 78. If it is so, then the 1-bit
+ matches any flow in table 78. If it is so, then the 1-bit
destination register R is set to 1.
sample(probability=packets, ...)
- This action causes the matched traffic to be sampled using
- IPFIX protocol. More information about how per-flow IPFIX
- sampling works in OVS can be found in ovs-actions(7) and
+ This action causes the matched traffic to be sampled using
+ IPFIX protocol. More information about how per-flow IPFIX
+ sampling works in OVS can be found in ovs-actions(7) and
ovs-vswitchd.conf.db(5).
- In order to reliably identify each sampled packet when it
- is received by the IPFIX collector, this action sets the
- content of the ObservationDomainID and ObservationPointID
+ In order to reliably identify each sampled packet when it
+ is received by the IPFIX collector, this action sets the
+ content of the ObservationDomainID and ObservationPointID
IPFIX fields (see argument description below).
The following key-value arguments are supported:
probability=packets
- The number of sampled packets out of 65535. It must
+ The number of sampled packets out of 65535. It must
be greater or equal to 1.
collector_set=id
The unsigned 32-bit integer identifier of the sample
collector to send sampled packets to. It must match
- the value configured in the Flow_Sample_Collec‐
+ the value configured in the Flow_Sample_Collec‐
tor_Set Table in OVS. Defaults to 0.
obs_domain=id
An unsigned 8-bit integer that identifies the sam‐
pling application. It will be placed in the 8 most
significant bits of the ObservationDomainID field of
- IPFIX samples. The 24 less significant bits will be
- automatically filled in with the datapath key.
- Defaults to 0.
+ IPFIX samples. The 24 less significant bits will be
+ automatically filled in with the datapath key. De‐
+ faults to 0.
obs_point=id
- An unsigned 32-bit integer to be used as Obsserva‐
- tionPointID or the string @cookie to indicate that
- the first 32 bits of the Logical_Flow’s UUID shall
+ An unsigned 32-bit integer to be used as Obsserva‐
+ tionPointID or the string @cookie to indicate that
+ the first 32 bits of the Logical_Flow’s UUID shall
be used instead.
+ mac_cache_use;
+ This action resubmits to corresponding table which updates
+ the use statistics of MAC cache.
+
tags: map of string-string pairs
Key-value pairs that provide additional information to help ovn-
- controller processing the logical flow. Below are the tags used
+ controller processing the logical flow. Below are the tags used
by ovn-controller.
in_out_port
In the logical flow’s "match" column, if a logical port P
is compared with "inport" and the logical flow is on a
logical switch ingress pipeline, or if P is compared with
- "outport" and the logical flow is on a logical switch
- egress pipeline, and the expression is combined with
- other expressions (if any) using the operator &&, then
- the port P should be added as the value in this tag. If
- there are multiple logical ports meeting this criteria,
+ "outport" and the logical flow is on a logical switch
+ egress pipeline, and the expression is combined with
+ other expressions (if any) using the operator &&, then
+ the port P should be added as the value in this tag. If
+ there are multiple logical ports meeting this criteria,
one of them can be added. ovn-controller uses this infor‐
mation to skip parsing flows that are not needed on the
chassis. Failing to add the tag will affect efficiency,
@@ -2090,26 +2103,25 @@ Logical_Flow TABLE
external_ids : stage-hint: optional string, containing an uuid
UUID of a OVN_Northbound record that caused this logical flow to
- be created. Currently used only for attribute of logical flows
+ be created. Currently used only for attribute of logical flows
to northbound ACL records.
external_ids : source: optional string
- Source file and line number of the code that added this flow to
+ Source file and line number of the code that added this flow to
the pipeline.
Common Columns:
- The overall purpose of these columns is described under Common Columns
+ The overall purpose of these columns is described under Common Columns
at the beginning of this document.
external_ids: map of string-string pairs
-
Logical_DP_Group TABLE
- Each row in this table represents a group of logical datapaths refer‐
+ Each row in this table represents a group of logical datapaths refer‐
enced by the logical_dp_group column in the Logical_Flow table.
Summary:
- datapaths set of weak reference to Datapath_Bind‐
+ datapaths set of weak reference to Datapath_Bind‐
ings
Details:
@@ -2119,11 +2131,11 @@ Logical_DP_Group TABLE
Multicast_Group TABLE
The rows in this table define multicast groups of logical ports. Multi‐
cast groups allow a single packet transmitted over a tunnel to a hyper‐
- visor to be delivered to multiple VMs on that hypervisor, which uses
+ visor to be delivered to multiple VMs on that hypervisor, which uses
bandwidth more efficiently.
- Each row in this table defines a logical multicast group numbered tun‐
- nel_key within datapath, whose logical ports are listed in the ports
+ Each row in this table defines a logical multicast group numbered tun‐
+ nel_key within datapath, whose logical ports are listed in the ports
column.
Summary:
@@ -2137,15 +2149,15 @@ Multicast_Group TABLE
The logical datapath in which the multicast group resides.
tunnel_key: integer, in range 32,768 to 65,535
- The value used to designate this logical egress port in tunnel
- encapsulations. An index forces the key to be unique within the
- datapath. The unusual range ensures that multicast group IDs do
+ The value used to designate this logical egress port in tunnel
+ encapsulations. An index forces the key to be unique within the
+ datapath. The unusual range ensures that multicast group IDs do
not overlap with logical port IDs.
name: string
- The logical multicast group’s name. An index forces the name to
- be unique within the datapath. Logical flows in the ingress
- pipeline may output to the group just as for individual logical
+ The logical multicast group’s name. An index forces the name to
+ be unique within the datapath. Logical flows in the ingress
+ pipeline may output to the group just as for individual logical
ports, by assigning the group’s name to outport and executing an
output action.
@@ -2155,7 +2167,7 @@ Multicast_Group TABLE
names that begin with _MC_.
ports: set of weak reference to Port_Bindings
- The logical ports included in the multicast group. All of these
+ The logical ports included in the multicast group. All of these
ports must be in the datapath logical datapath (but the database
schema cannot enforce this).
@@ -2166,9 +2178,10 @@ Mirror TABLE
Summary:
name string (must be unique within table)
- filter string, either from-lport or to-lport
+ filter string, one of both, from-lport, or
+ to-lport
sink string
- type string, either erspan or gre
+ type string, one of erspan, gre, or local
index integer
external_ids map of string-string pairs
@@ -2176,27 +2189,35 @@ Mirror TABLE
name: string (must be unique within table)
Represents the name of the mirror.
- filter: string, either from-lport or to-lport
- The value of this field represents selection criteria of the
- mirror.
+ filter: string, one of both, from-lport, or to-lport
+ The value of this field represents selection criteria of the
+ mirror. to-lport mirrors the packets coming into logical port.
+ from-lport mirrors the packets going out of logical port. both
+ mirrors for both directions.
sink: string
- The value of this field represents the destination/sink of the
- mirror.
+ The value of this field represents the destination/sink of the
+ mirror. If the type is gre or erspan, the value indicates the
+ tunnel remote IP (either IPv4 or IPv6). For a type of local,
+ this field defines a local interface on the OVS integration
+ bridge to be used as the mirror destination. The interface must
+ possess external-ids:mirror-id that matches this string.
- type: string, either erspan or gre
- The value of this field represents the type of the tunnel used
- for sending the mirrored packets
+ type: string, one of erspan, gre, or local
+ The value of this field specifies the mirror type - gre, erspan
+ or local.
index: integer
- The value of this field represents the key/idx depending on the
- tunnel type configured
+ The value of this field represents the tunnel ID. If the config‐
+ ured tunnel type is gre, this field represents the GRE key value
+ and if the configured tunnel type is erspan it represents the
+ erspan_idx value. It is ignored if the type is local.
external_ids: map of string-string pairs
See External IDs at the beginning of this document.
Meter TABLE
- Each row in this table represents a meter that can be used for QoS or
+ Each row in this table represents a meter that can be used for QoS or
rate-limiting.
Summary:
@@ -2208,12 +2229,12 @@ Meter TABLE
name: string (must be unique within table)
A name for this meter.
- Names that begin with "__" (two underscores) are reserved for
+ Names that begin with "__" (two underscores) are reserved for
OVN internal use and should not be added manually.
unit: string, either kbps or pktps
- The unit for rate and burst_rate parameters in the bands entry.
- kbps specifies kilobits per second, and pktps specifies packets
+ The unit for rate and burst_rate parameters in the bands entry.
+ kbps specifies kilobits per second, and pktps specifies packets
per second.
bands: set of 1 or more Meter_Bands
@@ -2224,7 +2245,7 @@ Meter TABLE
Meter_Band TABLE
Each row in this table represents a meter band which specifies the rate
- above which the configured action should be applied. These bands are
+ above which the configured action should be applied. These bands are
referenced by the bands column in the Meter table.
Summary:
@@ -2239,30 +2260,29 @@ Meter_Band TABLE
rate: integer, in range 1 to 4,294,967,295
The rate limit for this band, in kilobits per second or bits per
- second, depending on whether the parent Meter entry’s unit col‐
+ second, depending on whether the parent Meter entry’s unit col‐
umn specified kbps or pktps.
burst_size: integer, in range 0 to 4,294,967,295
- The maximum burst allowed for the band in kilobits or packets,
- depending on whether kbps or pktps was selected in the parent
- Meter entry’s unit column. If the size is zero, the switch is
+ The maximum burst allowed for the band in kilobits or packets,
+ depending on whether kbps or pktps was selected in the parent
+ Meter entry’s unit column. If the size is zero, the switch is
free to select some reasonable value depending on its configura‐
tion.
-
Datapath_Binding TABLE
Each row in this table represents a logical datapath, which implements
a logical pipeline among the ports in the Port_Binding table associated
- with it. In practice, the pipeline in a given logical datapath imple‐
+ with it. In practice, the pipeline in a given logical datapath imple‐
ments either a logical switch or a logical router.
- The main purpose of a row in this table is provide a physical binding
- for a logical datapath. A logical datapath does not have a physical
- location, so its physical binding information is limited: just tun‐
+ The main purpose of a row in this table is provide a physical binding
+ for a logical datapath. A logical datapath does not have a physical lo‐
+ cation, so its physical binding information is limited: just tun‐
nel_key. The rest of the data in this table does not affect packet for‐
warding.
Summary:
- tunnel_key integer, in range 1 to 16,777,215 (must
+ tunnel_key integer, in range 1 to 16,777,215 (must
be unique within table)
load_balancers set of uuids
OVN_Northbound Relationship:
@@ -2279,36 +2299,36 @@ Datapath_Binding TABLE
external_ids map of string-string pairs
Details:
- tunnel_key: integer, in range 1 to 16,777,215 (must be unique within
+ tunnel_key: integer, in range 1 to 16,777,215 (must be unique within
table)
The tunnel key value to which the logical datapath is bound. The
- Tunnel Encapsulation section in ovn-architecture(7) describes
- how tunnel keys are constructed for each supported encapsula‐
+ Tunnel Encapsulation section in ovn-architecture(7) describes
+ how tunnel keys are constructed for each supported encapsula‐
tion.
load_balancers: set of uuids
- Not used anymore; kept for backwards compatibility of the
+ Not used anymore; kept for backwards compatibility of the
schema.
OVN_Northbound Relationship:
- Each row in Datapath_Binding is associated with some logical datapath.
- ovn-northd uses these keys to track the association of a logical data‐
+ Each row in Datapath_Binding is associated with some logical datapath.
+ ovn-northd uses these keys to track the association of a logical data‐
path with concepts in the OVN_Northbound database.
external_ids : logical-switch: optional string, containing an uuid
For a logical datapath that represents a logical switch,
- ovn-northd stores in this key the UUID of the corresponding Log‐
+ ovn-northd stores in this key the UUID of the corresponding Log‐
ical_Switch row in the OVN_Northbound database.
external_ids : logical-router: optional string, containing an uuid
For a logical datapath that represents a logical router,
- ovn-northd stores in this key the UUID of the corresponding Log‐
+ ovn-northd stores in this key the UUID of the corresponding Log‐
ical_Router row in the OVN_Northbound database.
external_ids : interconn-ts: optional string
- For a logical datapath that represents a logical switch that
- represents a transit switch for interconnection, ovn-northd
+ For a logical datapath that represents a logical switch that
+ represents a transit switch for interconnection, ovn-northd
stores in this key the value of the same interconn-ts key of the
external_ids column of the corresponding Logical_Switch row in
the OVN_Northbound database.
@@ -2328,32 +2348,31 @@ Datapath_Binding TABLE
Common Columns:
- The overall purpose of these columns is described under Common Columns
+ The overall purpose of these columns is described under Common Columns
at the beginning of this document.
external_ids: map of string-string pairs
-
Port_Binding TABLE
- Each row in this table binds a logical port to a realization. For most
- logical ports, this means binding to some physical location, for exam‐
- ple by binding a logical port to a VIF that belongs to a VM running on
- a particular hypervisor. Other logical ports, such as logical patch
- ports, can be realized without a specific physical location, but their
+ Each row in this table binds a logical port to a realization. For most
+ logical ports, this means binding to some physical location, for exam‐
+ ple by binding a logical port to a VIF that belongs to a VM running on
+ a particular hypervisor. Other logical ports, such as logical patch
+ ports, can be realized without a specific physical location, but their
bindings are still expressed through rows in this table.
- For every Logical_Switch_Port record in OVN_Northbound database,
- ovn-northd creates a record in this table. ovn-northd populates and
- maintains every column except the chassis and virtual_parent columns,
+ For every Logical_Switch_Port record in OVN_Northbound database,
+ ovn-northd creates a record in this table. ovn-northd populates and
+ maintains every column except the chassis and virtual_parent columns,
which it leaves empty in new records.
ovn-controller/ovn-controller-vtep populates the chassis column for the
records that identify the logical ports that are located on its hyper‐
visor/gateway, which ovn-controller/ovn-controller-vtep in turn finds
out by monitoring the local hypervisor’s Open_vSwitch database, which
- identifies logical ports via the conventions described in Integra‐
+ identifies logical ports via the conventions described in Integra‐
tionGuide.rst. (The exceptions are for Port_Binding records with type
- of l3gateway, whose locations are identified by ovn-northd via the
- options:l3gateway-chassis column in this table. ovn-controller is still
+ of l3gateway, whose locations are identified by ovn-northd via the op‐
+ tions:l3gateway-chassis column in this table. ovn-controller is still
responsible to populate the chassis column.)
ovn-controller also populates the virtual_parent column of records
@@ -2364,7 +2383,7 @@ Port_Binding TABLE
resources hosted on the chassis are equally unreachable regardless of
whether their rows are present.) To handle the case where a VM is shut
down abruptly on one chassis, then brought up again on a different one,
- ovn-controller/ovn-controller-vtep must overwrite the chassis column
+ ovn-controller/ovn-controller-vtep must overwrite the chassis column
with new information.
Summary:
@@ -2418,7 +2437,9 @@ Port_Binding TABLE
options : qos_min_rate optional string
options : qos_max_rate optional string
options : qos_burst optional string
- options : qdisc_queue_id optional string, containing an integer,
+ options : qos_physical_network
+ optional string
+ options : qdisc_queue_id optional string, containing an integer,
in range 1 to 61,440
Distributed Gateway Port Options:
options : chassis-redirect-port
@@ -2444,17 +2465,17 @@ Port_Binding TABLE
The logical datapath to which the logical port belongs.
logical_port: string (must be unique within table)
- A logical port. For a logical switch port, this is taken from
+ A logical port. For a logical switch port, this is taken from
name in the OVN_Northbound database’s Logical_Switch_Port table.
For a logical router port, this is taken from name in the
OVN_Northbound database’s Logical_Router_port table. (This means
- that logical switch ports and router port names must not share
+ that logical switch ports and router port names must not share
names in an OVN deployment.) OVN does not prescribe a particular
format for the logical port ID.
encap: optional weak reference to Encap
Points to preferred encapsulation configuration to transmit log‐
- ical dataplane packets to this chassis. The entry is reference
+ ical dataplane packets to this chassis. The entry is reference
to a Encap record.
additional_encap: set of weak reference to Encaps
@@ -2467,25 +2488,25 @@ Port_Binding TABLE
umn. This is the meaning for each type
(empty string)
- The physical location of the logical port. To success‐
- fully identify a chassis, this column must be a Chassis
+ The physical location of the logical port. To success‐
+ fully identify a chassis, this column must be a Chassis
record. This is populated by ovn-controller.
- vtep The physical location of the hardware_vtep gateway. To
- successfully identify a chassis, this column must be a
+ vtep The physical location of the hardware_vtep gateway. To
+ successfully identify a chassis, this column must be a
Chassis record. This is populated by ovn-controller-vtep.
localnet
- Always empty. A localnet port is realized on every chas‐
- sis that has connectivity to the corresponding physical
+ Always empty. A localnet port is realized on every chas‐
+ sis that has connectivity to the corresponding physical
network.
localport
- Always empty. A localport port is present on every chas‐
+ Always empty. A localport port is present on every chas‐
sis.
l3gateway
- The physical location of the L3 gateway. To successfully
+ The physical location of the L3 gateway. To successfully
identify a chassis, this column must be a Chassis record.
This is populated by ovn-controller based on the value of
the options:l3gateway-chassis column in this table.
@@ -2504,19 +2525,19 @@ Port_Binding TABLE
gateway_chassis: set of Gateway_Chassises
A list of Gateway_Chassis.
- This should only be populated for ports with type set to chas‐
+ This should only be populated for ports with type set to chas‐
sisredirect. This column defines the list of chassis used as
gateways where traffic will be redirected through.
ha_chassis_group: optional HA_Chassis_Group
- This should only be populated for ports with type set to chas‐
+ This should only be populated for ports with type set to chas‐
sisredirect. This column defines the HA chassis group with a
list of HA chassis used as gateways where traffic will be redi‐
rected through.
up: optional boolean
This is set to true whenever all OVS flows required by this
- Port_Binding have been installed. This is populated by ovn-con‐
+ Port_Binding have been installed. This is populated by ovn-con‐
troller.
tunnel_key: integer, in range 1 to 32,767
@@ -2528,17 +2549,17 @@ Port_Binding TABLE
mac: set of strings
This column is a misnomer as it may contain MAC addresses and IP
- addresses. It is copied from the addresses column in the Logi‐
+ addresses. It is copied from the addresses column in the Logi‐
cal_Switch_Port table in the Northbound database. It follows the
same format as that column.
port_security: set of strings
- This column controls the addresses from which the host attached
- to the logical port (``the host’’) is allowed to send packets
+ This column controls the addresses from which the host attached
+ to the logical port (``the host’’) is allowed to send packets
and to which it is allowed to receive packets. If this column is
empty, all addresses are permitted.
- It is copied from the port_security column in the Logi‐
+ It is copied from the port_security column in the Logi‐
cal_Switch_Port table in the Northbound database. It follows the
same format as that column.
@@ -2550,7 +2571,7 @@ Port_Binding TABLE
(empty string)
VM (or VIF) interface.
- patch One of a pair of logical ports that act as if connected
+ patch One of a pair of logical ports that act as if connected
by a patch cable. Useful for connecting two logical data‐
paths, e.g. to connect a logical router to a logical
switch or to another logical router.
@@ -2558,79 +2579,79 @@ Port_Binding TABLE
l3gateway
One of a pair of logical ports that act as if connected
by a patch cable across multiple chassis. Useful for con‐
- necting a logical switch with a Gateway router (which is
+ necting a logical switch with a Gateway router (which is
only resident on a particular chassis).
localnet
- A connection to a locally accessible network from
+ A connection to a locally accessible network from
ovn-controller instances that have a corresponding bridge
mapping. A logical switch can have multiple localnet
ports attached. This type is used to model direct connec‐
- tivity to existing networks. In this case, each chassis
- should have a mapping for one of the physical networks
- only. Note: nothing said above implies that a chassis
- cannot be plugged to multiple physical networks as long
+ tivity to existing networks. In this case, each chassis
+ should have a mapping for one of the physical networks
+ only. Note: nothing said above implies that a chassis
+ cannot be plugged to multiple physical networks as long
as they belong to different switches.
localport
- A connection to a local VIF. Traffic that arrives on a
- localport is never forwarded over a tunnel to another
- chassis. These ports are present on every chassis and
- have the same address in all of them. This is used to
- model connectivity to local services that run on every
+ A connection to a local VIF. Traffic that arrives on a
+ localport is never forwarded over a tunnel to another
+ chassis. These ports are present on every chassis and
+ have the same address in all of them. This is used to
+ model connectivity to local services that run on every
hypervisor.
l2gateway
- An L2 connection to a physical network. The chassis this
- Port_Binding is bound to will serve as an L2 gateway to
+ An L2 connection to a physical network. The chassis this
+ Port_Binding is bound to will serve as an L2 gateway to
the network named by options:network_name.
- vtep A port to a logical switch on a VTEP gateway chassis. In
- order to get this port correctly recognized by the OVN
- controller, the options:vtep-physical-switch and
- options:vtep-logical-switch must also be defined.
+ vtep A port to a logical switch on a VTEP gateway chassis. In
+ order to get this port correctly recognized by the OVN
+ controller, the options:vtep-physical-switch and op‐
+ tions:vtep-logical-switch must also be defined.
chassisredirect
- A logical port that represents a particular instance,
- bound to a specific chassis, of an otherwise distributed
- parent port (e.g. of type patch). A chassisredirect port
- should never be used as an inport. When an ingress pipe‐
- line sets the outport, it may set the value to a logical
- port of type chassisredirect. This will cause the packet
- to be directed to a specific chassis to carry out the
- egress pipeline. At the beginning of the egress pipeline,
- the outport will be reset to the value of the distributed
- port.
+ A logical port that represents a particular instance,
+ bound to a specific chassis, of an otherwise distributed
+ parent port (e.g. of type patch). A chassisredirect port
+ should never be used as an inport. When an ingress
+ pipeline sets the outport, it may set the value to a log‐
+ ical port of type chassisredirect. This will cause the
+ packet to be directed to a specific chassis to carry out
+ the egress pipeline. At the beginning of the egress
+ pipeline, the outport will be reset to the value of the
+ distributed port.
virtual
- Represents a logical port with an virtual ip. This vir‐
- tual ip can be configured on a logical port (which is
- referred as virtual parent).
+ Represents a logical port with an virtual ip. This vir‐
+ tual ip can be configured on a logical port (which is re‐
+ ferred as virtual parent).
requested_chassis: optional weak reference to Chassis
- This column exists so that the ovn-controller can effectively
- monitor all Port_Binding records destined for it, and is a sup‐
- plement to the options:requested-chassis option. The option is
- still required so that the ovn-controller can check the CMS
- intent when the chassis pointed to does not currently exist,
- which for example occurs when the ovn-controller is stopped
- without passing the -restart argument. This column must be a
- Chassis record. This is populated by ovn-northd when the
- options:requested-chassis is defined and contains a string
- matching the name or hostname of an existing chassis. See also
- requested_additional_chassis.
+ This column exists so that the ovn-controller can effectively
+ monitor all Port_Binding records destined for it, and is a sup‐
+ plement to the options:requested-chassis option. The option is
+ still required so that the ovn-controller can check the CMS in‐
+ tent when the chassis pointed to does not currently exist, which
+ for example occurs when the ovn-controller is stopped without
+ passing the -restart argument. This column must be a Chassis
+ record. This is populated by ovn-northd when the options:re‐
+ quested-chassis is defined and contains a string matching the
+ name or hostname of an existing chassis. See also requested_ad‐
+ ditional_chassis.
requested_additional_chassis: set of weak reference to Chassis
This column exists so that the ovn-controller can effectively
monitor all Port_Binding records destined for it, and is a sup‐
plement to the options:requested-chassis option when multiple
chassis are listed. This column must be a list of Chassis
- records. This is populated by ovn-northd when the
- options:requested-chassis is defined as a list of chassis names
- or hostnames. See also requested_chassis.
+ records. This is populated by ovn-northd when the options:re‐
+ quested-chassis is defined as a list of chassis names or host‐
+ names. See also requested_chassis.
mirror_rules: set of weak reference to Mirrors
- Mirror rules that apply to the port binding. Please see the Mir‐
+ Mirror rules that apply to the port binding. Please see the Mir‐
ror table.
Patch Options:
@@ -2638,14 +2659,14 @@ Port_Binding TABLE
These options apply to logical ports with type of patch.
options : peer: optional string
- The logical_port in the Port_Binding record for the other side
- of the patch. The named logical_port must specify this logi‐
- cal_port in its own peer option. That is, the two patch logical
+ The logical_port in the Port_Binding record for the other side
+ of the patch. The named logical_port must specify this logi‐
+ cal_port in its own peer option. That is, the two patch logical
ports must have reversed logical_port and peer values.
nat_addresses: set of strings
- MAC address followed by a list of SNAT and DNAT external IP
- addresses, followed by is_chassis_resident("lport"), where lport
+ MAC address followed by a list of SNAT and DNAT external IP ad‐
+ dresses, followed by is_chassis_resident("lport"), where lport
is the name of a logical port on the same chassis where the cor‐
responding NAT rules are applied. This is used to send gratu‐
itous ARPs for SNAT and DNAT external IP addresses via localnet,
@@ -2661,10 +2682,10 @@ Port_Binding TABLE
These options apply to logical ports with type of l3gateway.
options : peer: optional string
- The logical_port in the Port_Binding record for the other side
- of the ’l3gateway’ port. The named logical_port must specify
- this logical_port in its own peer option. That is, the two
- ’l3gateway’ logical ports must have reversed logical_port and
+ The logical_port in the Port_Binding record for the other side
+ of the ’l3gateway’ port. The named logical_port must specify
+ this logical_port in its own peer option. That is, the two
+ ’l3gateway’ logical ports must have reversed logical_port and
peer values.
options : l3gateway-chassis: optional string
@@ -2673,10 +2694,10 @@ Port_Binding TABLE
nat_addresses: set of strings
MAC address of the l3gateway port followed by a list of SNAT and
DNAT external IP addresses. This is used to send gratuitous ARPs
- for SNAT and DNAT external IP addresses via localnet. Example:
- 80:fa:5b:06:72:b7 158.36.44.22 158.36.44.24. This would result
- in generation of gratuitous ARPs for IP addresses 158.36.44.22
- and 158.36.44.24 with a MAC address of 80:fa:5b:06:72:b7. This
+ for SNAT and DNAT external IP addresses via localnet. Example:
+ 80:fa:5b:06:72:b7 158.36.44.22 158.36.44.24. This would result
+ in generation of gratuitous ARPs for IP addresses 158.36.44.22
+ and 158.36.44.24 with a MAC address of 80:fa:5b:06:72:b7. This
is used in OVS version 2.8 and later versions.
Localnet Options:
@@ -2684,29 +2705,29 @@ Port_Binding TABLE
These options apply to logical ports with type of localnet.
options : network_name: optional string
- Required. ovn-controller uses the configuration entry
+ Required. ovn-controller uses the configuration entry
ovn-bridge-mappings to determine how to connect to this network.
ovn-bridge-mappings is a list of network names mapped to a local
- OVS bridge that provides access to that network. An example of
+ OVS bridge that provides access to that network. An example of
configuring ovn-bridge-mappings would be: .IP
$ ovs-vsctl set open . external-ids:ovn-bridge-mappings=physnet1:br-eth0,physnet2:br-eth1
- When a logical switch has a localnet port attached, every chas‐
- sis that may have a local vif attached to that logical switch
- must have a bridge mapping configured to reach that localnet.
- Traffic that arrives on a localnet port is never forwarded over
- a tunnel to another chassis. If there are multiple localnet
- ports in a logical switch, each chassis should only have a sin‐
- gle bridge mapping for one of the physical networks. Note: In
- case of multiple localnet ports, to provide interconnectivity
- between all VIFs located on different chassis with different
- fabric connectivity, the fabric should implement some form of
+ When a logical switch has a localnet port attached, every chas‐
+ sis that may have a local vif attached to that logical switch
+ must have a bridge mapping configured to reach that localnet.
+ Traffic that arrives on a localnet port is never forwarded over
+ a tunnel to another chassis. If there are multiple localnet
+ ports in a logical switch, each chassis should only have a sin‐
+ gle bridge mapping for one of the physical networks. Note: In
+ case of multiple localnet ports, to provide interconnectivity
+ between all VIFs located on different chassis with different
+ fabric connectivity, the fabric should implement some form of
routing between the segments.
tag: optional integer, in range 1 to 4,095
- If set, indicates that the port represents a connection to a
- specific VLAN on a locally accessible network. The VLAN ID is
- used to match incoming traffic and is also added to outgoing
+ If set, indicates that the port represents a connection to a
+ specific VLAN on a locally accessible network. The VLAN ID is
+ used to match incoming traffic and is also added to outgoing
traffic.
L2 Gateway Options:
@@ -2714,10 +2735,10 @@ Port_Binding TABLE
These options apply to logical ports with type of l2gateway.
options : network_name: optional string
- Required. ovn-controller uses the configuration entry
+ Required. ovn-controller uses the configuration entry
ovn-bridge-mappings to determine how to connect to this network.
ovn-bridge-mappings is a list of network names mapped to a local
- OVS bridge that provides access to that network. An example of
+ OVS bridge that provides access to that network. An example of
configuring ovn-bridge-mappings would be: .IP
$ ovs-vsctl set open . external-ids:ovn-bridge-mappings=physnet1:br-eth0,physnet2:br-eth1
@@ -2730,8 +2751,8 @@ Port_Binding TABLE
tag: optional integer, in range 1 to 4,095
If set, indicates that the gateway is connected to a specific
- VLAN on the physical network. The VLAN ID is used to match
- incoming traffic and is also added to outgoing traffic.
+ VLAN on the physical network. The VLAN ID is used to match in‐
+ coming traffic and is also added to outgoing traffic.
VTEP Options:
@@ -2750,10 +2771,10 @@ Port_Binding TABLE
options : requested-chassis: optional string
If set, identifies a specific chassis (by name or hostname) that
- is allowed to bind this port. Using this option will prevent
- thrashing between two chassis trying to bind the same port dur‐
- ing a live migration. It can also prevent similar thrashing due
- to a mis-configuration, if a port is accidentally created on
+ is allowed to bind this port. Using this option will prevent
+ thrashing between two chassis trying to bind the same port dur‐
+ ing a live migration. It can also prevent similar thrashing due
+ to a mis-configuration, if a port is accidentally created on
more than one chassis.
If set to a comma separated list, the first entry identifies the
@@ -2769,8 +2790,8 @@ Port_Binding TABLE
options : activation-strategy: optional string
If used with multiple chassis set in requested-chassis, speci‐
- fies an activation strategy for all additional chassis. By
- default, no activation strategy is used, meaning additional port
+ fies an activation strategy for all additional chassis. By de‐
+ fault, no activation strategy is used, meaning additional port
locations are immediately available for use. When set to "rarp",
the port is blocked for ingress and egress communication until a
RARP packet is sent from a new location. The "rarp" strategy is
@@ -2790,15 +2811,19 @@ Port_Binding TABLE
sent from this interface, in bit/s.
options : qos_max_rate: optional string
- If set, indicates the maximum rate for data sent from this
- interface, in bit/s. The traffic will be shaped according to
- this limit.
+ If set, indicates the maximum rate for data sent from this in‐
+ terface, in bit/s. The traffic will be shaped according to this
+ limit.
options : qos_burst: optional string
If set, indicates the maximum burst size for data sent from this
interface, in bits.
- options : qdisc_queue_id: optional string, containing an integer, in
+ options : qos_physical_network: optional string
+ If set, indicates the name of the egress network name where
+ traffic shaping will be applied.
+
+ options : qdisc_queue_id: optional string, containing an integer, in
range 1 to 61,440
Indicates the queue number on the physical device. This is same
as the queue_id used in OpenFlow in struct ofp_action_enqueue.
@@ -2845,7 +2870,7 @@ Port_Binding TABLE
Identifies the VLAN tag in the network traffic associated with
that container’s network interface.
- This column is used for a different purpose when type is local‐
+ This column is used for a different purpose when type is local‐
net (see Localnet Options, above) or l2gateway (see L2 Gateway
Options, above).
@@ -2855,7 +2880,7 @@ Port_Binding TABLE
This column is set by ovn-controller with one of the value from
the options:virtual-parents in the OVN_Northbound database’s
Logical_Switch_Port table when the OVN action bind_vport is exe‐
- cuted. ovn-controller also sets the chassis column when it exe‐
+ cuted. ovn-controller also sets the chassis column when it exe‐
cutes this action with its chassis id.
ovn-controller sets this column only if the type is "virtual".
@@ -2863,11 +2888,11 @@ Port_Binding TABLE
Naming:
external_ids : name: optional string
- For a logical switch port, ovn-northd copies this from exter‐
- nal_ids:neutron:port_name in the Logical_Switch_Port table in
+ For a logical switch port, ovn-northd copies this from exter‐
+ nal_ids:neutron:port_name in the Logical_Switch_Port table in
the OVN_Northbound database, if it is a nonempty string.
- For a logical switch port, ovn-northd does not currently set
+ For a logical switch port, ovn-northd does not currently set
this key.
Common Columns:
@@ -2875,54 +2900,54 @@ Port_Binding TABLE
external_ids: map of string-string pairs
See External IDs at the beginning of this document.
- The ovn-northd program populates this column with all entries
- into the external_ids column of the Logical_Switch_Port and Log‐
+ The ovn-northd program populates this column with all entries
+ into the external_ids column of the Logical_Switch_Port and Log‐
ical_Router_Port tables of the OVN_Northbound database.
MAC_Binding TABLE
Each row in this table specifies a binding from an IP address to an
Ethernet address that has been discovered through ARP (for IPv4) or
neighbor discovery (for IPv6). This table is primarily used to discover
- bindings on physical networks, because IP-to-MAC bindings for virtual
+ bindings on physical networks, because IP-to-MAC bindings for virtual
machines are usually populated statically into the Port_Binding table.
- This table expresses a functional relationship: MAC_Binding(logi‐
+ This table expresses a functional relationship: MAC_Binding(logi‐
cal_port, ip) = mac.
- In outline, the lifetime of a logical router’s MAC binding looks like
+ In outline, the lifetime of a logical router’s MAC binding looks like
this:
- 1. On hypervisor 1, a logical router determines that a packet
- should be forwarded to IP address A on one of its router
- ports. It uses its logical flow table to determine that A
- lacks a static IP-to-MAC binding and the get_arp action to
+ 1. On hypervisor 1, a logical router determines that a packet
+ should be forwarded to IP address A on one of its router
+ ports. It uses its logical flow table to determine that A
+ lacks a static IP-to-MAC binding and the get_arp action to
determine that it lacks a dynamic IP-to-MAC binding.
- 2. Using an OVN logical arp action, the logical router gener‐
- ates and sends a broadcast ARP request to the router port.
+ 2. Using an OVN logical arp action, the logical router gener‐
+ ates and sends a broadcast ARP request to the router port.
It drops the IP packet.
- 3. The logical switch attached to the router port delivers the
- ARP request to all of its ports. (It might make sense to
- deliver it only to ports that have no static IP-to-MAC bind‐
+ 3. The logical switch attached to the router port delivers the
+ ARP request to all of its ports. (It might make sense to de‐
+ liver it only to ports that have no static IP-to-MAC bind‐
ings, but this could also be surprising behavior.)
- 4. A host or VM on hypervisor 2 (which might be the same as
- hypervisor 1) attached to the logical switch owns the IP
- address in question. It composes an ARP reply and unicasts
- it to the logical router port’s Ethernet address.
+ 4. A host or VM on hypervisor 2 (which might be the same as hy‐
+ pervisor 1) attached to the logical switch owns the IP ad‐
+ dress in question. It composes an ARP reply and unicasts it
+ to the logical router port’s Ethernet address.
- 5. The logical switch delivers the ARP reply to the logical
+ 5. The logical switch delivers the ARP reply to the logical
router port.
- 6. The logical router flow table executes a put_arp action. To
- record the IP-to-MAC binding, ovn-controller adds a row to
+ 6. The logical router flow table executes a put_arp action. To
+ record the IP-to-MAC binding, ovn-controller adds a row to
the MAC_Binding table.
- 7. On hypervisor 1, ovn-controller receives the updated
+ 7. On hypervisor 1, ovn-controller receives the updated
MAC_Binding table from the OVN southbound database. The next
- packet destined to A through the logical router is sent
- directly to the bound Ethernet address.
+ packet destined to A through the logical router is sent di‐
+ rectly to the bound Ethernet address.
Summary:
logical_port string
@@ -2949,17 +2974,17 @@ MAC_Binding TABLE
The logical datapath to which the logical port belongs.
DHCP_Options TABLE
- Each row in this table stores the DHCP Options supported by native OVN
- DHCP. ovn-northd populates this table with the supported DHCP options.
- ovn-controller looks up this table to get the DHCP codes of the DHCP
- options defined in the "put_dhcp_opts" action. Please refer to the RFC
- 2132 "https://tools.ietf.org/html/rfc2132" for the possible list of
+ Each row in this table stores the DHCP Options supported by native OVN
+ DHCP. ovn-northd populates this table with the supported DHCP options.
+ ovn-controller looks up this table to get the DHCP codes of the DHCP
+ options defined in the "put_dhcp_opts" action. Please refer to the RFC
+ 2132 "https://tools.ietf.org/html/rfc2132" for the possible list of
DHCP options that can be defined here.
Summary:
name string
code integer, in range 0 to 254
- type string, one of bool, domains, host_id,
+ type string, one of bool, domains, host_id,
ipv4, static_routes, str, uint16, uint32,
or uint8
@@ -2974,12 +2999,12 @@ DHCP_Options TABLE
Example. code=3
- type: string, one of bool, domains, host_id, ipv4, static_routes, str,
+ type: string, one of bool, domains, host_id, ipv4, static_routes, str,
uint16, uint32, or uint8
Data type of the DHCP option code.
value: bool
- This indicates that the value of the DHCP option is a
+ This indicates that the value of the DHCP option is a
bool.
Example. "name=ip_forward_enable", "code=19",
@@ -2988,7 +3013,7 @@ DHCP_Options TABLE
put_dhcp_opts(..., ip_forward_enable = 1,...)
value: uint8
- This indicates that the value of the DHCP option is an
+ This indicates that the value of the DHCP option is an
unsigned int8 (8 bits)
Example. "name=default_ttl", "code=23", "type=uint8".
@@ -2996,7 +3021,7 @@ DHCP_Options TABLE
put_dhcp_opts(..., default_ttl = 50,...)
value: uint16
- This indicates that the value of the DHCP option is an
+ This indicates that the value of the DHCP option is an
unsigned int16 (16 bits).
Example. "name=mtu", "code=26", "type=uint16".
@@ -3004,7 +3029,7 @@ DHCP_Options TABLE
put_dhcp_opts(..., mtu = 1450,...)
value: uint32
- This indicates that the value of the DHCP option is an
+ This indicates that the value of the DHCP option is an
unsigned int32 (32 bits).
Example. "name=lease_time", "code=51", "type=uint32".
@@ -3012,7 +3037,7 @@ DHCP_Options TABLE
put_dhcp_opts(..., lease_time = 86400,...)
value: ipv4
- This indicates that the value of the DHCP option is an
+ This indicates that the value of the DHCP option is an
IPv4 address or addresses.
Example. "name=router", "code=3", "type=ipv4".
@@ -3046,24 +3071,23 @@ DHCP_Options TABLE
Example. "name=tftp_server", "code=66", "type=host_id".
value: domains
- This indicates that the value of the DHCP option is a
- domain name or a comma separated list of domain names.
-
- Example. "name=domain_search_list", "code=119",
- "type=domains".
+ This indicates that the value of the DHCP option is a do‐
+ main name or a comma separated list of domain names.
+ Example. "name=domain_search_list", "code=119", "type=do‐
+ mains".
DHCPv6_Options TABLE
Each row in this table stores the DHCPv6 Options supported by native
OVN DHCPv6. ovn-northd populates this table with the supported DHCPv6
options. ovn-controller looks up this table to get the DHCPv6 codes of
the DHCPv6 options defined in the put_dhcpv6_opts action. Please refer
- to RFC 3315 and RFC 3646 for the list of DHCPv6 options that can be
- defined here.
+ to RFC 3315 and RFC 3646 for the list of DHCPv6 options that can be de‐
+ fined here.
Summary:
name string
code integer, in range 0 to 254
- type string, one of ipv6, mac, or str
+ type string, one of domain, ipv6, mac, or str
Details:
name: string
@@ -3072,16 +3096,16 @@ DHCPv6_Options TABLE
Example. name="ia_addr"
code: integer, in range 0 to 254
- DHCPv6 option code for the DHCPv6 option as defined in the
- appropriate RFC.
+ DHCPv6 option code for the DHCPv6 option as defined in the ap‐
+ propriate RFC.
Example. code=3
- type: string, one of ipv6, mac, or str
+ type: string, one of domain, ipv6, mac, or str
Data type of the DHCPv6 option code.
value: ipv6
- This indicates that the value of the DHCPv6 option is an
+ This indicates that the value of the DHCPv6 option is an
IPv6 address(es).
Example. "name=ia_addr", "code=5", "type=ipv6".
@@ -3089,7 +3113,7 @@ DHCPv6_Options TABLE
put_dhcpv6_opts(..., ia_addr = ae70::4,...)
value: str
- This indicates that the value of the DHCPv6 option is a
+ This indicates that the value of the DHCPv6 option is a
string.
Example. "name=domain_search", "code=24", "type=str".
@@ -3097,22 +3121,21 @@ DHCPv6_Options TABLE
put_dhcpv6_opts(..., domain_search = ovn.domain,...)
value: mac
- This indicates that the value of the DHCPv6 option is a
+ This indicates that the value of the DHCPv6 option is a
MAC address.
Example. "name=server_id", "code=2", "type=mac".
put_dhcpv6_opts(..., server_id = 01:02:03:04L05:06,...)
-
Connection TABLE
- Configuration for a database connection to an Open vSwitch database
+ Configuration for a database connection to an Open vSwitch database
(OVSDB) client.
- This table primarily configures the Open vSwitch database server
+ This table primarily configures the Open vSwitch database server
(ovsdb-server).
- The Open vSwitch database server can initiate and maintain active con‐
- nections to remote clients. It can also listen for database connec‐
+ The Open vSwitch database server can initiate and maintain active con‐
+ nections to remote clients. It can also listen for database connec‐
tions.
Summary:
@@ -3126,17 +3149,17 @@ Connection TABLE
Status:
is_connected boolean
status : last_error optional string
- status : state optional string, one of ACTIVE, BACKOFF,
+ status : state optional string, one of ACTIVE, BACKOFF,
CONNECTING, IDLE, or VOID
- status : sec_since_connect optional string, containing an integer,
+ status : sec_since_connect optional string, containing an integer,
at least 0
status : sec_since_disconnect
- optional string, containing an integer,
+ 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,
+ status : n_connections optional string, containing an integer,
at least 2
status : bound_port optional string, containing an integer
Common Columns:
@@ -3152,38 +3175,38 @@ Connection TABLE
The following connection methods are currently supported:
ssl:host[:port]
- The specified SSL port on the given host, which can
- either be a DNS name (if built with unbound library) or
- an IP address. A valid SSL configuration must be provided
- when this form is used, this configuration can be speci‐
+ The specified SSL port on the given host, which can ei‐
+ ther 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 speci‐
fied 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
+ 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 given host, which can
- either be a DNS name (if built with unbound library) or
- an IP address (IPv4 or IPv6). If host is an IPv6 address,
+ The specified TCP port on the given host, which can ei‐
+ ther be a DNS name (if built with unbound library) or an
+ IP address (IPv4 or IPv6). If host is an IPv6 address,
wrap it in square brackets, e.g. tcp:[::1]:6640.
If port is not specified, it defaults to 6640.
pssl:[port][:host]
- Listens for SSL connections on the specified TCP port.
- Specify 0 for port to have the kernel automatically
- choose an available port. If host, which can either be a
- DNS name (if built with unbound library) or an IP
- address, is specified, then connections are restricted to
- the resolved or specified local IP address (either IPv4
- or IPv6 address). If host is an IPv6 address, wrap in
- square brackets, e.g. pssl:6640:[::1]. If host is not
- specified then it listens only on IPv4 (but not IPv6)
- addresses. A valid SSL configuration must be provided
- when this form is used, this can be specified either via
- command-line options or the SSL table.
+ 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 ad‐
+ dress, is specified, then connections are restricted to
+ the resolved or specified local IP address (either IPv4
+ or IPv6 address). If host is an IPv6 address, wrap in
+ square brackets, e.g. pssl:6640:[::1]. If host is not
+ specified then it listens only on IPv4 (but not IPv6) ad‐
+ dresses. A valid SSL configuration must be provided when
+ this form is used, this can be specified either via com‐
+ mand-line options or the SSL table.
If port is not specified, it defaults to 6640.
@@ -3193,13 +3216,13 @@ Connection TABLE
ptcp:[port][:host]
Listens for connections on the specified TCP port. Spec‐
ify 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.
+ 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 re‐
+ solved 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.
@@ -3216,17 +3239,17 @@ Connection TABLE
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.
+ Maximum number of milliseconds to wait between connection at‐
+ tempts. 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 recon‐
- nect. Default is implementation-specific. A value of 0 disables
+ 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 recon‐
+ nect. Default is implementation-specific. A value of 0 disables
inactivity probes.
Status:
@@ -3235,12 +3258,12 @@ Connection TABLE
in the status columns may be updated depends on the target type.
When target specifies a connection method that listens for inbound con‐
- nections (e.g. ptcp: or punix:), both n_connections and is_connected
+ nections (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 omit‐
+ 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 omit‐
ted.
is_connected: boolean
@@ -3251,7 +3274,7 @@ Connection TABLE
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,
+ status : state: optional string, one of ACTIVE, BACKOFF, CONNECTING,
IDLE, or VOID
The state of the connection to the manager:
@@ -3267,58 +3290,57 @@ Connection TABLE
IDLE Connection is idle. Waiting for response to keep-alive.
- These values may change in the future. They are provided only
+ These values may change in the future. They are provided only
for human consumption.
- status : sec_since_connect: optional string, containing an integer, at
+ 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,
+ 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 dis‐
+ The amount of time since this client last disconnected from the
+ database (in seconds). Value is empty if client has never dis‐
connected.
status : locks_held: optional string
- Space-separated list of the names of OVSDB locks that the con‐
- nection holds. Omitted if the connection does not hold any
+ Space-separated list of the names of OVSDB locks that the con‐
+ nection 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 con‐
- nection is currently waiting to acquire. Omitted if the connec‐
+ Space-separated list of the names of OVSDB locks that the con‐
+ nection is currently waiting to acquire. Omitted if the connec‐
tion is not waiting for any locks.
status : locks_lost: optional string
- Space-separated list of the names of OVSDB locks that the con‐
- nection has had stolen by another OVSDB client. Omitted if no
+ Space-separated list of the names of OVSDB locks that the con‐
+ nection 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
+ 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 con‐
+ When target specifies a connection method that listens for in‐
+ bound connections (e.g. ptcp: or pssl:) and more than one con‐
nection 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
+ 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
+ The overall purpose of these columns is described under Common Columns
at the beginning of this document.
external_ids: map of string-string pairs
other_config: map of string-string pairs
-
SSL TABLE
SSL configuration for ovn-sb database access.
@@ -3334,11 +3356,11 @@ SSL TABLE
Details:
private_key: string
- Name of a PEM file containing the private key used as the
+ 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 cer‐
+ Name of a PEM file containing a certificate, signed by the cer‐
tificate authority (CA) used by the controller and manager, that
certifies the switch’s private key, identifying a trustworthy
switch.
@@ -3350,8 +3372,8 @@ SSL TABLE
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
+ save it to the named PEM file. If it is successful, it will im‐
+ mediately 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
@@ -3359,28 +3381,28 @@ SSL TABLE
ping.
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.
+ List of SSL protocols to be enabled for SSL connections. The de‐
+ fault when this option is omitted is TLSv1,TLSv1.1,TLSv1.2.
ssl_ciphers: string
- List of ciphers (in OpenSSL cipher string format) to be sup‐
- ported for SSL connections. The default when this option is
+ List of ciphers (in OpenSSL cipher string format) to be sup‐
+ ported 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
+ The overall purpose of these columns is described under Common Columns
at the beginning of this document.
external_ids: map of string-string pairs
-
DNS TABLE
- Each row in this table stores the DNS records. The OVN action
+ Each row in this table stores the DNS records. The OVN action
dns_lookup uses this table for DNS resolution.
Summary:
records map of string-string pairs
datapaths set of 1 or more Datapath_Bindings
+ options : ovn-owned optional string
Common Columns:
external_ids map of string-string pairs
@@ -3398,6 +3420,11 @@ DNS TABLE
only to the DNS queries originating from the datapaths defined
in this column.
+ options : ovn-owned: optional string
+ This column indicates that all the Domains in this table are
+ owned by OVN, and all DNS queries for those domains will be an‐
+ swered locally by either an IP address or DNS rejection.
+
Common Columns:
external_ids: map of string-string pairs
@@ -3408,12 +3435,12 @@ RBAC_Role TABLE
Summary:
name string
- permissions map of string-weak reference to RBAC_Per‐
+ permissions map of string-weak reference to RBAC_Per‐
mission pairs
Details:
name: string
- The role name, corresponding to the role column in the Connec‐
+ The role name, corresponding to the role column in the Connec‐
tion table.
permissions: map of string-weak reference to RBAC_Permission pairs
@@ -3433,7 +3460,7 @@ RBAC_Permission TABLE
Name of table to which this row applies.
authorization: set of strings
- Set of strings identifying columns and column:key pairs to be
+ Set of strings identifying columns and column:key pairs to be
compared with client ID. At least one match is required in order
to be authorized. A zero-length string is treated as a special
value indicating all clients should be considered authorized.
@@ -3443,12 +3470,12 @@ RBAC_Permission TABLE
permitted.
update: set of strings
- Set of strings identifying columns and column:key pairs that
- authorized clients are allowed to modify.
+ Set of strings identifying columns and column:key pairs that au‐
+ thorized clients are allowed to modify.
Gateway_Chassis TABLE
- Association of Port_Binding rows of type chassisredirect to a Chassis.
- The traffic going out through a specific chassisredirect port will be
+ Association of Port_Binding rows of type chassisredirect to a Chassis.
+ The traffic going out through a specific chassisredirect port will be
redirected to a chassis, or a set of them in high availability configu‐
rations.
@@ -3483,7 +3510,6 @@ Gateway_Chassis TABLE
at the beginning of this document.
external_ids: map of string-string pairs
-
HA_Chassis TABLE
Summary:
chassis optional weak reference to Chassis
@@ -3506,13 +3532,13 @@ HA_Chassis TABLE
HA_Chassis_Group TABLE
Table representing a group of chassis which can provide High availabil‐
- ity services. Each chassis in the group is represented by the table
- HA_Chassis. The HA chassis with highest priority will be the master of
- this group. If the master chassis failover is detected, the HA chassis
- with the next higher priority takes over the responsibility of provid‐
+ ity services. Each chassis in the group is represented by the table
+ HA_Chassis. The HA chassis with highest priority will be the master of
+ this group. If the master chassis failover is detected, the HA chassis
+ with the next higher priority takes over the responsibility of provid‐
ing the HA. If ha_chassis_group column of the table Port_Binding refer‐
ences this table, then this HA chassis group provides the gateway func‐
- tionality and redirects the gateway traffic to the master of this
+ tionality and redirects the gateway traffic to the master of this
group.
Summary:
@@ -3530,14 +3556,14 @@ HA_Chassis_Group TABLE
A list of HA_Chassis which belongs to this group.
ref_chassis: set of weak reference to Chassis
- The set of Chassis that reference this HA chassis group. To
- determine the correct Chassis, find the chassisredirect type
- Port_Binding that references this HA_Chassis_Group. This
- Port_Binding is derived from some particular logical router.
- Starting from that LR, find the set of all logical switches and
- routers connected to it, directly or indirectly, across router
- ports that link one LRP to another or to a LSP. For each LSP in
- these logical switches, find the corresponding Port_Binding and
+ The set of Chassis that reference this HA chassis group. To de‐
+ termine the correct Chassis, find the chassisredirect type
+ Port_Binding that references this HA_Chassis_Group. This
+ Port_Binding is derived from some particular logical router.
+ Starting from that LR, find the set of all logical switches and
+ routers connected to it, directly or indirectly, across router
+ ports that link one LRP to another or to a LSP. For each LSP in
+ these logical switches, find the corresponding Port_Binding and
add its bound Chassis (if any) to ref_chassis.
Common Columns:
@@ -3546,7 +3572,7 @@ HA_Chassis_Group TABLE
See External IDs at the beginning of this document.
Controller_Event TABLE
- Database table used by ovn-controller to report CMS related events.
+ Database table used by ovn-controller to report CMS related events.
Please note there is no guarantee a given event is written exactly once
in the db. It is CMS responsibility to squash duplicated lines or to
filter out duplicated events
@@ -3565,12 +3591,12 @@ Controller_Event TABLE
Key-value pairs used to specify event info to the CMS. Possible
values are:
- · vip: VIP reported for the empty_lb_backends event
+ • vip: VIP reported for the empty_lb_backends event
- · protocol: Transport protocol reported for the
+ • protocol: Transport protocol reported for the
empty_lb_backends event
- · load_balancer: UUID of the load balancer reported for the
+ • load_balancer: UUID of the load balancer reported for the
empty_lb_backends event
chassis: optional weak reference to Chassis
@@ -3586,7 +3612,7 @@ IP_Multicast TABLE
IP Multicast configuration options. For now only applicable to IGMP.
Summary:
- datapath weak reference to Datapath_Binding (must
+ datapath weak reference to Datapath_Binding (must
be unique within table)
enabled optional boolean
querier optional boolean
@@ -3610,12 +3636,12 @@ IP_Multicast TABLE
Enables/disables multicast snooping. Default: disabled.
querier: optional boolean
- Enables/disables multicast querying. If enabled then multicast
+ Enables/disables multicast querying. If enabled then multicast
querying is enabled by default.
table_size: optional integer
- Limits the number of multicast groups that can be learned.
- Default: 2048 groups per datapath.
+ Limits the number of multicast groups that can be learned. De‐
+ fault: 2048 groups per datapath.
idle_timeout: optional integer
Configures the idle timeout (in seconds) for IP multicast groups
@@ -3623,16 +3649,16 @@ IP_Multicast TABLE
query_interval: optional integer
Configures the interval (in seconds) for sending multicast
- queries if snooping and querier are enabled. Default: idle_time‐
+ queries if snooping and querier are enabled. Default: idle_time‐
out/2 seconds.
seq_no: integer
- ovn-controller reads this value and flushes all learned multi‐
+ ovn-controller reads this value and flushes all learned multi‐
cast groups when it detects that seq_no was changed.
Querier configuration options:
- The ovn-controller process that runs on OVN hypervisor nodes uses the
+ The ovn-controller process that runs on OVN hypervisor nodes uses the
following columns to determine field values in IGMP/MLD queries that it
originates:
@@ -3654,10 +3680,11 @@ IGMP_Group TABLE
Summary:
address string
- datapath optional weak reference to Datapath_Bind‐
+ datapath optional weak reference to Datapath_Bind‐
ing
chassis optional weak reference to Chassis
ports set of weak reference to Port_Bindings
+ chassis_name string
Details:
address: string
@@ -3672,13 +3699,17 @@ IGMP_Group TABLE
ports: set of weak reference to Port_Bindings
The destination port bindings for this IGMP group.
+ chassis_name: string
+ The chassis that inserted this record. This column is used for
+ RBAC purposes only.
+
Service_Monitor TABLE
Each row in this table configures monitoring a service for its live‐
- ness. The service can be an IPv4 TCP or UDP service. ovn-controller
- periodically sends out service monitor packets and updates the status
- of the service. Service monitoring for IPv6 services is not supported.
+ ness. The service can be an IPv4 TCP or UDP service. ovn-controller pe‐
+ riodically sends out service monitor packets and updates the status of
+ the service. Service monitoring for IPv6 services is not supported.
- ovn-northd uses this feature to implement the load balancer health
+ ovn-northd uses this feature to implement the load balancer health
check feature offered to the CMS through the northbound database.
Summary:
@@ -3689,12 +3720,13 @@ Service_Monitor TABLE
logical_port string
src_mac string
src_ip string
+ chassis_name string
options : interval optional string, containing an integer
options : timeout optional string, containing an integer
options : success_count optional string, containing an integer
options : failure_count optional string, containing an integer
Status Reporting:
- status optional string, one of error, offline,
+ status optional string, one of error, offline,
or online
Common Columns:
external_ids map of string-string pairs
@@ -3725,6 +3757,9 @@ Service_Monitor TABLE
src_ip: string
Source IPv4 address to use in the service monitor packet.
+ chassis_name: string
+ The name of the chassis where the logical port is bound.
+
options : interval: optional string, containing an integer
The interval, in seconds, between service monitor checks.
@@ -3767,6 +3802,8 @@ Load_Balancer TABLE
protocol optional string, one of sctp, tcp, or udp
datapaths set of Datapath_Bindings
datapath_group optional Logical_DP_Group
+ ls_datapath_group optional Logical_DP_Group
+ lr_datapath_group optional Logical_DP_Group
Load_Balancer options:
options : hairpin_snat_ip optional string
options : hairpin_orig_tuple
@@ -3776,30 +3813,40 @@ Load_Balancer TABLE
Details:
name: string
- A name for the load balancer. This name has no special meaning
- or purpose other than to provide convenience for human interac‐
+ A name for the load balancer. This name has no special meaning
+ or purpose other than to provide convenience for human interac‐
tion with the ovn-nb database.
vips: map of string-string pairs
- A map of virtual IP addresses (and an optional port number with
- : as a separator) associated with this load balancer and their
- corresponding endpoint IP addresses (and optional port numbers
+ A map of virtual IP addresses (and an optional port number with
+ : as a separator) associated with this load balancer and their
+ corresponding endpoint IP addresses (and optional port numbers
with : as separators) separated by commas.
protocol: optional string, one of sctp, tcp, or udp
- Valid protocols are tcp, udp, or sctp. This column is useful
- when a port number is provided as part of the vips column. If
- this column is empty and a port number is provided as part of
+ Valid protocols are tcp, udp, or sctp. This column is useful
+ when a port number is provided as part of the vips column. If
+ this column is empty and a port number is provided as part of
vips column, OVN assumes the protocol to be tcp.
datapaths: set of Datapath_Bindings
Datapaths to which this load balancer applies to.
datapath_group: optional Logical_DP_Group
- The group of datapaths to which this load balancer applies to.
- This means that the same load balancer applies to all datapaths
+ Deprecated. The group of datapaths to which this load balancer
+ applies to. This means that the same load balancer applies to
+ all datapaths in a group.
+
+ ls_datapath_group: optional Logical_DP_Group
+ The group of datapaths to which this load balancer applies to.
+ This means that the same load balancer applies to all datapaths
in a group.
+ lr_datapath_group: optional Logical_DP_Group
+ The group of logical router datapaths to which this load bal‐
+ ancer applies to. This means that the same load balancer applies
+ to all datapaths in a group.
+
Load_Balancer options:
options : hairpin_snat_ip: optional string
@@ -3809,7 +3856,7 @@ Load_Balancer TABLE
options : hairpin_orig_tuple: optional string, either true or false
This value is automatically set to true by ovn-northd when orig‐
- inal destination IP and transport port of the load balanced
+ inal destination IP and transport port of the load balanced
packets are stored in registers reg1, reg2, xxreg1.
Common Columns:
@@ -3829,6 +3876,7 @@ BFD TABLE
min_tx integer
min_rx integer
detect_mult integer
+ chassis_name string
options map of string-string pairs
external_ids map of string-string pairs
Status Reporting:
@@ -3844,7 +3892,7 @@ BFD TABLE
disc: integer
A unique, nonzero discriminator value generated by the transmit‐
- ting system, used to demultiplex multiple BFD sessions between
+ ting system, used to demultiplex multiple BFD sessions between
the same pair of systems.
logical_port: string
@@ -3854,22 +3902,25 @@ BFD TABLE
BFD peer IP address.
min_tx: integer
- This is the minimum interval, in milliseconds, that the local
- system would like to use when transmitting BFD Control packets,
+ This is the minimum interval, in milliseconds, that the local
+ system would like to use when transmitting BFD Control packets,
less any jitter applied. The value zero is reserved.
min_rx: integer
- This is the minimum interval, in milliseconds, between received
- BFD Control packets that this system is capable of supporting,
- less any jitter applied by the sender. If this value is zero,
- the transmitting system does not want the remote system to send
+ This is the minimum interval, in milliseconds, between received
+ BFD Control packets that this system is capable of supporting,
+ less any jitter applied by the sender. If this value is zero,
+ the transmitting system does not want the remote system to send
any periodic BFD Control packets.
detect_mult: integer
- Detection time multiplier. The negotiated transmit interval,
- multiplied by this value, provides the Detection Time for the
+ Detection time multiplier. The negotiated transmit interval,
+ multiplied by this value, provides the Detection Time for the
receiving system in Asynchronous mode.
+ chassis_name: string
+ The name of the chassis where the logical port is bound.
+
options: map of string-string pairs
Reserved for future use.
@@ -3881,27 +3932,27 @@ BFD TABLE
status: string, one of admin_down, down, init, or up
BFD port logical states. Possible values are:
- · admin_down
+ • admin_down
- · down
+ • down
- · init
-
- · up
+ • init
+ • up
FDB TABLE
- This table is primarily used to learn the MACs observed on a VIF (or a
- localnet port with ’localnet_learn_fdb’ enabled) which belongs to a
- Logical_Switch_Port record in OVN_Northbound whose port security is
- disabled and ’unknown’ address set. If port security is disabled on a
- Logical_Switch_Port record, OVN should allow traffic with any source
- mac from the VIF. This table will be used to deliver a packet to the
+ This table is primarily used to learn the MACs observed on a VIF (or a
+ localnet port with ’localnet_learn_fdb’ enabled) which belongs to a
+ Logical_Switch_Port record in OVN_Northbound whose port security is
+ disabled and ’unknown’ address set. If port security is disabled on a
+ Logical_Switch_Port record, OVN should allow traffic with any source
+ mac from the VIF. This table will be used to deliver a packet to the
VIF, If a packet’s eth.dst is learnt.
Summary:
mac string
dp_key integer, in range 1 to 16,777,215
port_key integer, in range 1 to 16,777,215
+ timestamp integer
Details:
mac: string
@@ -3913,6 +3964,10 @@ FDB TABLE
port_key: integer, in range 1 to 16,777,215
The key of the port binding on which this FDB was learnt.
+ timestamp: integer
+ The timestamp in msec when the FDB was added or updated. Records
+ that existed before this column will have 0.
+
Static_MAC_Binding TABLE
Each record represents a Static_MAC_Binding entry for a logical router.
@@ -3940,7 +3995,7 @@ Static_MAC_Binding TABLE
The logical datapath to which the logical router port belongs.
Chassis_Template_Var TABLE
- Each record represents the set of template variable instantiations for
+ Each record represents the set of template variable instantiations for
a given chassis and is populated by ovn-northd from the contents of the
OVN_Northbound.Chassis_Template_Var table.
@@ -3955,6 +4010,4 @@ Chassis_Template_Var TABLE
variables: map of string-string pairs
The set of variable values for a given chassis.
-
-
-Open vSwitch 22.12.90 DB Schema 20.27.0 ovn-sb(5)
+Open vSwitch 24.03.90 DB Schema 20.33.0 ovn-sb(5)
diff --git a/src/static/support/dist-docs/ovn-sbctl.8 b/src/static/support/dist-docs/ovn-sbctl.8
index c5909cee..5ae0521d 100644
--- a/src/static/support/dist-docs/ovn-sbctl.8
+++ b/src/static/support/dist-docs/ovn-sbctl.8
@@ -1,6 +1,6 @@
'\" p
.\" -*- nroff -*-
-.TH "ovn-sbctl" 8 "ovn-sbctl" "OVN 22\[char46]12\[char46]90" "OVN Manual"
+.TH "ovn-sbctl" 8 "ovn-sbctl" "OVN 24\[char46]03\[char46]90" "OVN Manual"
.fp 5 L CR \\" Make fixed-width font available as \\fL.
.de TQ
. br
diff --git a/src/static/support/dist-docs/ovn-sbctl.8.html b/src/static/support/dist-docs/ovn-sbctl.8.html
index 60975a80..23275d66 100644
--- a/src/static/support/dist-docs/ovn-sbctl.8.html
+++ b/src/static/support/dist-docs/ovn-sbctl.8.html
@@ -1,7 +1,5 @@
-ovn-sbctl(8) OVN Manual ovn-sbctl(8)
-
-
+ovn-sbctl(8) OVN Manual ovn-sbctl(8)
NAME
ovn-sbctl - Open Virtual Network southbound db management utility
@@ -22,20 +20,20 @@
ovn-sbctl can perform any number of commands in a single run, imple‐
mented as a single atomic transaction against the database.
- The ovn-sbctl command line begins with global options (see OPTIONS
- below for details). The global options are followed by one or more com‐
+ The ovn-sbctl command line begins with global options (see OPTIONS be‐
+ low for details). The global options are followed by one or more com‐
mands. Each command should begin with -- by itself as a command-line
argument, to separate it from the following commands. (The -- before
the first command is optional.) The command itself starts with command-
- specific options, if any, followed by the command name and any argu‐
+ specific options, if any, followed by the command name and any argu‐
ments.
DAEMON MODE
- When it is invoked in the most ordinary way, ovn-sbctl connects to an
- OVSDB server that hosts the southbound database, retrieves a partial
- copy of the database that is complete enough to do its work, sends a
- transaction request to the server, and receives and processes the
- server’s reply. In common interactive use, this is fine, but if the
+ When it is invoked in the most ordinary way, ovn-sbctl connects to an
+ OVSDB server that hosts the southbound database, retrieves a partial
+ copy of the database that is complete enough to do its work, sends a
+ transaction request to the server, and receives and processes the
+ server’s reply. In common interactive use, this is fine, but if the
database is large, the step in which ovn-sbctl retrieves a partial copy
of the database can take a long time, which yields poor performance
overall.
@@ -43,22 +41,22 @@
To improve performance in such a case, ovn-sbctl offers a "daemon
mode," in which the user first starts ovn-sbctl running in the back‐
ground and afterward uses the daemon to execute operations. Over sev‐
- eral ovn-sbctl command invocations, this performs better overall
- because it retrieves a copy of the database only once at the beginning,
+ eral ovn-sbctl command invocations, this performs better overall be‐
+ cause it retrieves a copy of the database only once at the beginning,
not once per program run.
Use the --detach option to start an ovn-sbctl daemon. With this option,
- ovn-sbctl prints the name of a control socket to stdout. The client
- should save this name in environment variable OVN_SB_DAEMON. Under the
+ ovn-sbctl prints the name of a control socket to stdout. The client
+ should save this name in environment variable OVN_SB_DAEMON. Under the
Bourne shell this might be done like this:
export OVN_SB_DAEMON=$(ovn-sbctl --pidfile --detach)
- When OVN_SB_DAEMON is set, ovn-sbctl automatically and transparently
+ When OVN_SB_DAEMON is set, ovn-sbctl automatically and transparently
uses the daemon to execute its commands.
- When the daemon is no longer needed, kill it and unset the environment
+ When the daemon is no longer needed, kill it and unset the environment
variable, e.g.:
kill $(cat $OVN_RUNDIR/ovn-sbctl.pid)
@@ -85,23 +83,23 @@
ovn-appctl. One may also use ovn-appctl directly with the following
commands:
- run [options] command [arg...] [-- [options] command [arg...]
+ run [options] command [arg...] [-- [options] command [arg...]
...]
Instructs the daemon process to run one or more ovn-sbctl
commands described above and reply with the results of
running these commands. Accepts the --no-wait, --wait,
- --timeout, --dry-run, --oneline, and the options
- described under Table Formatting Options in addition to
- the the command-specific options.
+ --timeout, --dry-run, --oneline, and the options de‐
+ scribed under Table Formatting Options in addition to the
+ the command-specific options.
exit Causes ovn-sbctl to gracefully terminate.
OPTIONS
- The options listed below affect the behavior of ovn-sbctl as a whole.
+ The options listed below affect the behavior of ovn-sbctl as a whole.
Some individual commands also accept their own options, which are given
just before the command name. If the first command on the command line
- has options, then those options must be separated from the global
- options by --.
+ has options, then those options must be separated from the global op‐
+ tions by --.
ovn-sbctl also accepts options from the OVN_SBCTL_OPTIONS environment
variable, in the same format as on the command line. Options from the
@@ -109,10 +107,10 @@
--db database
The OVSDB database remote to contact. If the OVN_SB_DB
- environment variable is set, its value is used as the
- default. Otherwise, the default is unix:/ovnsb_db.sock,
- but this default is unlikely to be useful outside of sin‐
- gle-machine OVN test environments.
+ environment variable is set, its value is used as the de‐
+ fault. Otherwise, the default is unix:/ovnsb_db.sock, but
+ this default is unlikely to be useful outside of single-
+ machine OVN test environments.
--leader-only
--no-leader-only
@@ -122,7 +120,7 @@
ovn-sbctl reads and reports is up-to-date. With
--no-leader-only, ovn-sbctl will use any server in the
cluster, which means that for read-only transactions it can
- report and act on stale data (transactions that modify the
+ report and act on stale data (transactions that modify the
database are always serialized even with --no-leader-only).
Refer to Understanding Cluster Consistency in ovsdb(7) for
more information.
@@ -136,11 +134,11 @@
tries to connect. The remotes will be shuffled only once to
a new order before the first connection attempt. The fol‐
lowing retries, if any, will follow the same new order. The
- default behavior is to make sure clients of a clustered
- database can distribute evenly to all members of the clus‐
- ter. With --no-shuffle-remotes, ovn-sbctl will use the
- original order specified in the connection string to con‐
- nect. This allows user to specify the preferred order,
+ default behavior is to make sure clients of a clustered
+ database can distribute evenly to all members of the clus‐
+ ter. With --no-shuffle-remotes, ovn-sbctl will use the
+ original order specified in the connection string to con‐
+ nect. This allows user to specify the preferred order,
which is particularly useful for testing.
--no-syslog
@@ -152,10 +150,10 @@
--oneline
Modifies the output format so that the output for each com‐
- mand is printed on a single line. New-line characters that
- would otherwise separate lines are printed as \fB\\n\fR,
- and any instances of \fB\\\fR that would otherwise appear
- in the output are doubled. Prints a blank line for each
+ mand is printed on a single line. New-line characters that
+ would otherwise separate lines are printed as \fB\\n\fR,
+ and any instances of \fB\\\fR that would otherwise appear
+ in the output are doubled. Prints a blank line for each
command that has no output. This option does not affect the
formatting of output from the list or find commands; see
Table Formatting Options below.
@@ -175,7 +173,7 @@
Daemon Options
--pidfile[=pidfile]
Causes a file (by default, program.pid) to be created indicating
- the PID of the running process. If the pidfile argument is not
+ the PID of the running process. If the pidfile argument is not
specified, or if it does not begin with /, then it is created in
.
@@ -193,13 +191,13 @@
Runs this program as a background process. The process forks,
and in the child it starts a new session, closes the standard
file descriptors (which has the side effect of disabling logging
- to the console), and changes its current directory to the root
- (unless --no-chdir is specified). After the child completes its
+ to the console), and changes its current directory to the root
+ (unless --no-chdir is specified). After the child completes its
initialization, the parent exits.
--monitor
- Creates an additional process to monitor this program. If it
- dies due to a signal that indicates a programming error (SIGA‐
+ Creates an additional process to monitor this program. If it
+ dies due to a signal that indicates a programming error (SIGA‐‐
BRT, SIGALRM, SIGBUS, SIGFPE, SIGILL, SIGPIPE, SIGSEGV, SIGXCPU,
or SIGXFSZ) then the monitor process starts a new copy of it. If
the daemon dies or exits for another reason, the monitor process
@@ -210,10 +208,10 @@
--no-chdir
By default, when --detach is specified, the daemon changes its
- current working directory to the root directory after it
- detaches. Otherwise, invoking the daemon from a carelessly cho‐
- sen directory would prevent the administrator from unmounting
- the file system that holds that directory.
+ current working directory to the root directory after it de‐
+ taches. Otherwise, invoking the daemon from a carelessly chosen
+ directory would prevent the administrator from unmounting the
+ file system that holds that directory.
Specifying --no-chdir suppresses this behavior, preventing the
daemon from changing its current working directory. This may be
@@ -232,21 +230,21 @@
implementations that are typically enforced from kernel-space
(e.g. DAC or MAC), self-confinement is imposed from the user-
space daemon itself and hence should not be considered as a full
- confinement strategy, but instead should be viewed as an addi‐
+ confinement strategy, but instead should be viewed as an addi‐
tional layer of security.
--user=user:group
- Causes this program to run as a different user specified in
- user:group, thus dropping most of the root privileges. Short
- forms user and :group are also allowed, with current user or
- group assumed, respectively. Only daemons started by the root
+ Causes this program to run as a different user specified in
+ user:group, thus dropping most of the root privileges. Short
+ forms user and :group are also allowed, with current user or
+ group assumed, respectively. Only daemons started by the root
user accepts this argument.
On Linux, daemons will be granted CAP_IPC_LOCK and
- CAP_NET_BIND_SERVICES before dropping root privileges. Daemons
- that interact with a datapath, such as ovs-vswitchd, will be
- granted three additional capabilities, namely CAP_NET_ADMIN,
- CAP_NET_BROADCAST and CAP_NET_RAW. The capability change will
+ CAP_NET_BIND_SERVICES before dropping root privileges. Daemons
+ that interact with a datapath, such as ovs-vswitchd, will be
+ granted three additional capabilities, namely CAP_NET_ADMIN,
+ CAP_NET_BROADCAST and CAP_NET_RAW. The capability change will
apply even if the new user is root.
On Windows, this option is not currently supported. For security
@@ -261,13 +259,13 @@
words separated by spaces or commas or colons, up to one from each
category below:
- · A valid module name, as displayed by the vlog/list command
+ • A valid module name, as displayed by the vlog/list command
on ovs-appctl(8), limits the log level change to the speci‐
fied module.
- · syslog, console, or file, to limit the log level change to
- only to the system log, to the console, or to a file,
- respectively. (If --detach is specified, the daemon closes
+ • syslog, console, or file, to limit the log level change to
+ only to the system log, to the console, or to a file, re‐
+ spectively. (If --detach is specified, the daemon closes
its standard file descriptors, so logging to the console
will have no effect.)
@@ -275,15 +273,15 @@
only useful along with the --syslog-target option (the word
has no effect otherwise).
- · off, emer, err, warn, info, or dbg, to control the log
- level. Messages of the given severity or higher will be
- logged, and messages of lower severity will be filtered
- out. off filters out all messages. See ovs-appctl(8) for a
+ • off, emer, err, warn, info, or dbg, to control the log
+ level. Messages of the given severity or higher will be
+ logged, and messages of lower severity will be filtered
+ out. off filters out all messages. See ovs-appctl(8) for a
definition of each log level.
Case is not significant within spec.
- Regardless of the log levels set for file, logging to a file will
+ Regardless of the log levels set for file, logging to a file will
not take place unless --log-file is also specified (see below).
For compatibility with older versions of OVS, any is accepted as a
@@ -291,22 +289,22 @@
-v
--verbose
- Sets the maximum logging verbosity level, equivalent to --ver‐
+ Sets the maximum logging verbosity level, equivalent to --ver‐‐
bose=dbg.
-vPATTERN:destination:pattern
--verbose=PATTERN:destination:pattern
- Sets the log pattern for destination to pattern. Refer to
- ovs-appctl(8) for a description of the valid syntax for pattern.
+ Sets the log pattern for destination to pattern. Refer to ovs-ap‐‐
+ pctl(8) for a description of the valid syntax for pattern.
-vFACILITY:facility
--verbose=FACILITY:facility
Sets the RFC5424 facility of the log message. facility can be one
of kern, user, mail, daemon, auth, syslog, lpr, news, uucp, clock,
- ftp, ntp, audit, alert, clock2, local0, local1, local2, local3,
+ ftp, ntp, audit, alert, clock2, local0, local1, local2, local3,
local4, local5, local6 or local7. If this option is not specified,
- daemon is used as the default for the local system syslog and
- local0 is used while sending a message to the target provided via
+ daemon is used as the default for the local system syslog and lo‐‐
+ cal0 is used while sending a message to the target provided via
the --syslog-target option.
--log-file[=file]
@@ -315,111 +313,111 @@
if file is omitted is /usr/local/var/log/ovn/program.log.
--syslog-target=host:port
- Send syslog messages to UDP port on host, in addition to the sys‐
- tem syslog. The host must be a numerical IP address, not a host‐
+ Send syslog messages to UDP port on host, in addition to the sys‐
+ tem syslog. The host must be a numerical IP address, not a host‐
name.
--syslog-method=method
- Specify method as how syslog messages should be sent to syslog
+ Specify method as how syslog messages should be sent to syslog
daemon. The following forms are supported:
- · libc, to use the libc syslog() function. Downside of using
- this options is that libc adds fixed prefix to every mes‐
- sage before it is actually sent to the syslog daemon over
+ • libc, to use the libc syslog() function. Downside of using
+ this options is that libc adds fixed prefix to every mes‐
+ sage before it is actually sent to the syslog daemon over
/dev/log UNIX domain socket.
- · unix:file, to use a UNIX domain socket directly. It is pos‐
+ • unix:file, to use a UNIX domain socket directly. It is pos‐
sible to specify arbitrary message format with this option.
- However, rsyslogd 8.9 and older versions use hard coded
- parser function anyway that limits UNIX domain socket use.
- If you want to use arbitrary message format with older
- rsyslogd versions, then use UDP socket to localhost IP
- address instead.
-
- · udp:ip:port, to use a UDP socket. With this method it is
- possible to use arbitrary message format also with older
- rsyslogd. When sending syslog messages over UDP socket
- extra precaution needs to be taken into account, for exam‐
- ple, syslog daemon needs to be configured to listen on the
- specified UDP port, accidental iptables rules could be
- interfering with local syslog traffic and there are some
- security considerations that apply to UDP sockets, but do
- not apply to UNIX domain sockets.
-
- · null, to discard all messages logged to syslog.
-
- The default is taken from the OVS_SYSLOG_METHOD environment vari‐
+ However, rsyslogd 8.9 and older versions use hard coded
+ parser function anyway that limits UNIX domain socket use.
+ If you want to use arbitrary message format with older
+ rsyslogd versions, then use UDP socket to localhost IP ad‐
+ dress instead.
+
+ • udp:ip:port, to use a UDP socket. With this method it is
+ possible to use arbitrary message format also with older
+ rsyslogd. When sending syslog messages over UDP socket ex‐
+ tra precaution needs to be taken into account, for example,
+ syslog daemon needs to be configured to listen on the spec‐
+ ified UDP port, accidental iptables rules could be inter‐
+ fering with local syslog traffic and there are some secu‐
+ rity considerations that apply to UDP sockets, but do not
+ apply to UNIX domain sockets.
+
+ • null, to discard all messages logged to syslog.
+
+ The default is taken from the OVS_SYSLOG_METHOD environment vari‐
able; if it is unset, the default is libc.
Table Formatting Options
- These options control the format of output from the list and find com‐
+ These options control the format of output from the list and find com‐
mands.
-f format
--format=format
- Sets the type of table formatting. The following types of
+ Sets the type of table formatting. The following types of
format are available:
table 2-D text tables with aligned columns.
list (default)
- A list with one column per line and rows separated
+ A list with one column per line and rows separated
by a blank line.
html HTML tables.
csv Comma-separated values as defined in RFC 4180.
- json JSON format as defined in RFC 4627. The output is a
- sequence of JSON objects, each of which corresponds
- to one table. Each JSON object has the following
+ json JSON format as defined in RFC 4627. The output is a
+ sequence of JSON objects, each of which corresponds
+ to one table. Each JSON object has the following
members with the noted values:
caption
- The table’s caption. This member is omitted
+ The table’s caption. This member is omitted
if the table has no caption.
headings
- An array with one element per table column.
- Each array element is a string giving the
+ An array with one element per table column.
+ Each array element is a string giving the
corresponding column’s heading.
data An array with one element per table row. Each
element is also an array with one element per
- table column. The elements of this second-
+ table column. The elements of this second-
level array are the cells that constitute the
table. Cells that represent OVSDB data or
- data types are expressed in the format
- described in the OVSDB specification; other
+ data types are expressed in the format de‐
+ scribed in the OVSDB specification; other
cells are simply expressed as text strings.
-d format
--data=format
Sets the formatting for cells within output tables unless
the table format is set to json, in which case json format‐
- ting is always used when formatting cells. The following
+ ting is always used when formatting cells. The following
types of format are available:
string (default)
- The simple format described in the Database Values
+ The simple format described in the Database Values
section of ovs-vsctl(8).
- bare The simple format with punctuation stripped off: []
- and {} are omitted around sets, maps, and empty col‐
- umns, items within sets and maps are space-sepa‐
+ bare The simple format with punctuation stripped off: []
+ and {} are omitted around sets, maps, and empty
+ columns, items within sets and maps are space-sepa‐
rated, and strings are never quoted. This format may
be easier for scripts to parse.
json The RFC 4627 JSON format as described above.
--no-headings
- This option suppresses the heading row that otherwise
- appears in the first row of table output.
+ This option suppresses the heading row that otherwise ap‐
+ pears in the first row of table output.
--pretty
By default, JSON in output is printed as compactly as pos‐
sible. This option causes JSON in output to be printed in a
- more readable fashion. Members of objects and elements of
+ more readable fashion. Members of objects and elements of
arrays are printed one per line, with indentation.
This option does not affect JSON in tables, which is always
@@ -451,22 +449,22 @@
ifying certificates presented to this program by SSL peers.
(This may be the same certificate that SSL peers use to
verify the certificate specified on -c or --certificate, or
- it may be a different one, depending on the PKI design in
+ it may be a different one, depending on the PKI design in
use.)
-C none
--ca-cert=none
- Disables verification of certificates presented by SSL
- peers. This introduces a security risk, because it means
- that certificates cannot be verified to be those of known
+ Disables verification of certificates presented by SSL
+ peers. This introduces a security risk, because it means
+ that certificates cannot be verified to be those of known
trusted hosts.
--bootstrap-ca-cert=cacert.pem
- When cacert.pem exists, this option has the same effect
- as -C or --ca-cert. If it does not exist, then the exe‐
- cutable will attempt to obtain the CA certificate from
- the SSL peer on its first SSL connection and save it to
- the named PEM file. If it is successful, it will immedi‐
+ When cacert.pem exists, this option has the same effect
+ as -C or --ca-cert. If it does not exist, then the exe‐
+ cutable will attempt to obtain the CA certificate from
+ the SSL peer on its first SSL connection and save it to
+ the named PEM file. If it is successful, it will immedi‐
ately drop the connection and reconnect, and from then on
all SSL connections must be authenticated by a certifi‐
cate signed by the CA certificate thus obtained.
@@ -477,7 +475,7 @@
This option is only useful if the SSL peer sends its CA
certificate as part of the SSL certificate chain. The SSL
- protocol does not require the server to send the CA cer‐
+ protocol does not require the server to send the CA cer‐
tificate.
This option is mutually exclusive with -C and --ca-cert.
@@ -529,20 +527,20 @@
Binds the logical port named logical-port to chassis.
Without --may-exist, attempting to bind a logical port
- that has already been bound is an error. With
- --may-exist, this command does nothing if logical-port
- has already been bound to a chassis.
+ that has already been bound is an error. With --may-ex‐‐
+ ist, this command does nothing if logical-port has al‐
+ ready been bound to a chassis.
[--if-exists] lsp-unbind logical-port
Removes the binding of logical-port.
Without --if-exists, attempting to unbind a logical port
that is not bound is an error. With --if-exists, attempt‐
- ing to unbind logical port that is not bound has no
- effect.
+ ing to unbind logical port that is not bound has no ef‐
+ fect.
Logical Flow Commands
- [--uuid] [--ovs[=remote]] [--stats] [--vflows] lflow-list [logical-
+ [--uuid] [--ovs[=remote]] [--stats] [--vflows] lflow-list [logical-
datapath] [lflow...]
List logical flows. If logical-datapath is specified, only list
flows for that logical datapath. The logical-datapath may be
@@ -551,9 +549,9 @@
If at least one lflow is given, only matching logical flows, if
any, are listed. Each lflow may be specified as a UUID or the
- first few characters of a UUID, optionally prefixed by 0x.
- (Because ovn-controller sets OpenFlow flow cookies to the first
- 32 bits of the corresponding logical flow’s UUID, this makes it
+ first few characters of a UUID, optionally prefixed by 0x. (Be‐
+ cause ovn-controller sets OpenFlow flow cookies to the first 32
+ bits of the corresponding logical flow’s UUID, this makes it
easy to look up the logical flow that generated a particular
OpenFlow flow.)
@@ -564,21 +562,21 @@
If --ovs is included, ovn-sbctl attempts to obtain and display
the OpenFlow flows that correspond to each OVN logical flow. To
do so, ovn-sbctl connects to remote (by default,
- unix:/br-int.mgmt) over OpenFlow and retrieves the flows. If
- remote is specified, it must be an active OpenFlow connection
- method described in ovsdb(7). Please see the discussion of the
- similar --ovs option in ovn-trace(8) for more information about
+ unix:/br-int.mgmt) over OpenFlow and retrieves the flows. If re
+ mote is specified, it must be an active OpenFlow connection
+ method described in ovsdb(7). Please see the discussion of the
+ similar --ovs option in ovn-trace(8) for more information about
the OpenFlow flow output.
- By default, OpenFlow flow output includes only match and
- actions. Add --stats to include all OpenFlow information, such
- as packet and byte counters, duration, and timeouts.
+ By default, OpenFlow flow output includes only match and ac‐
+ tions. Add --stats to include all OpenFlow information, such as
+ packet and byte counters, duration, and timeouts.
- If --vflows is included, other southbound database records
- directly used for generating OpenFlow flows are also listed.
- This includes: port-bindings, mac-bindings, multicast-groups,
- chassis. The --ovs and --stats can also be used in conjunction
- with --vflows.
+ If --vflows is included, other southbound database records di‐
+ rectly used for generating OpenFlow flows are also listed. This
+ includes: port-bindings, mac-bindings, multicast-groups, chas
+ sis. The --ovs and --stats can also be used in conjunction with
+ --vflows.
[--uuid] dump-flows [logical-datapath]
Alias for lflow-list.
@@ -589,9 +587,8 @@
Remote Connectivity Commands
These commands manipulate the connections column in the SB_Global table
and rows in the Connection table. When ovsdb-server is configured to
- use the connections column for OVSDB connections, this allows the
- administrator to use \fBovn\-sbctl\fR to configure database connec‐
- tions.
+ use the connections column for OVSDB connections, this allows the ad‐
+ ministrator to use \fBovn\-sbctl\fR to configure database connections.
get-connection
Prints the configured connection(s).
@@ -600,30 +597,30 @@
Deletes the configured connection(s).
[--inactivity-probe=msecs] set-connection target...
- Sets the configured manager target or targets. Use
- --inactivity-probe=msecs to override the default idle
- connection inactivity probe time. Use 0 to disable inac‐
- tivity probes.
+ Sets the configured manager target or targets. Use --in‐‐
+ activity-probe=msecs to override the default idle connec‐
+ tion inactivity probe time. Use 0 to disable inactivity
+ probes.
SSL Configuration Commands
- When ovsdb-server is configured to connect using SSL, the following
- parameters are required:
+ When ovsdb-server is configured to connect using SSL, the following pa‐
+ rameters are required:
private-key
- Specifies a PEM file containing the private key used for
+ Specifies a PEM file containing the private key used for
SSL connections.
certificate
- Specifies a PEM file containing a certificate, signed by
- the certificate authority (CA) used by the connection
- peers, that certifies the private key, identifying a
+ Specifies a PEM file containing a certificate, signed by
+ the certificate authority (CA) used by the connection
+ peers, that certifies the private key, identifying a
trustworthy peer.
ca-cert
- Specifies a PEM file containing the CA certificate used
+ Specifies a PEM file containing the CA certificate used
to verify that the connection peers are trustworthy.
- These SSL settings apply to all SSL connections made by the southbound
+ These SSL settings apply to all SSL connections made by the southbound
database server.
get-ssl
@@ -632,7 +629,7 @@
del-ssl
Deletes the current SSL configuration.
- [--bootstrap] set-ssl private-key certificate ca-cert [ssl-pro‐
+ [--bootstrap] set-ssl private-key certificate ca-cert [ssl-pro
tocol-list [ssl-cipher-list]]
Sets the SSL configuration.
@@ -645,20 +642,20 @@
Each of these commands has a table parameter to identify a table within
the database. Many of them also take a record parameter that identifies
- a particular record within a table. The record parameter may be the
- UUID for a record, which may be abbreviated to its first 4 (or more)
- hex digits, as long as that is unique. Many tables offer additional
- ways to identify records. Some commands also take column parameters
+ a particular record within a table. The record parameter may be the
+ UUID for a record, which may be abbreviated to its first 4 (or more)
+ hex digits, as long as that is unique. Many tables offer additional
+ ways to identify records. Some commands also take column parameters
that identify a particular field within the records in a table.
- For a list of tables and their columns, see ovn-sb(5) or see the table
+ For a list of tables and their columns, see ovn-sb(5) or see the table
listing from the --help option.
Record names must be specified in full and with correct capitalization,
except that UUIDs may be abbreviated to their first 4 (or more) hex
digits, as long as that is unique within the table. Names of tables and
- columns are not case-sensitive, and - and _ are treated interchange‐
- ably. Unique abbreviations of table and column names are acceptable,
+ columns are not case-sensitive, and - and _ are treated interchange‐
+ ably. Unique abbreviations of table and column names are acceptable,
e.g. d or dhcp is sufficient to identify the DHCP_Options table.
Database Values
@@ -680,40 +677,40 @@
begin with an English letter or underscore and consist
only of letters, underscores, hyphens, and periods. How‐
ever, true and false and strings that match the syntax of
- UUIDs (see below) must be enclosed in double quotes to
- distinguish them from other basic types. When double
- quotes are used, the syntax is that of strings in JSON,
- e.g. backslashes may be used to escape special charac‐
- ters. The empty string must be represented as a pair of
+ UUIDs (see below) must be enclosed in double quotes to
+ distinguish them from other basic types. When double
+ quotes are used, the syntax is that of strings in JSON,
+ e.g. backslashes may be used to escape special charac‐
+ ters. The empty string must be represented as a pair of
double quotes ("").
- UUID Either a universally unique identifier in the style of
- RFC 4122, e.g. f81d4fae-7dec-11d0-a765-00a0c91e6bf6, or
- an @name defined by a get or create command within the
+ UUID Either a universally unique identifier in the style of
+ RFC 4122, e.g. f81d4fae-7dec-11d0-a765-00a0c91e6bf6, or
+ an @name defined by a get or create command within the
same ovs-vsctl invocation.
Multiple values in a single column may be separated by spaces or a sin‐
- gle comma. When multiple values are present, duplicates are not
- allowed, and order is not important. Conversely, some database columns
+ gle comma. When multiple values are present, duplicates are not al‐
+ lowed, and order is not important. Conversely, some database columns
can have an empty set of values, represented as [], and square brackets
may optionally enclose other non-empty sets or single values as well.
- A few database columns are ``maps’’ of key-value pairs, where the key
+ A few database columns are ``maps’’ of key-value pairs, where the key
and the value are each some fixed database type. These are specified in
the form key=value, where key and value follow the syntax for the col‐
umn’s key type and value type, respectively. When multiple pairs are
- present (separated by spaces or a comma), duplicate keys are not
- allowed, and again the order is not important. Duplicate values are
- allowed. An empty map is represented as {}. Curly braces may optionally
+ present (separated by spaces or a comma), duplicate keys are not al‐
+ lowed, and again the order is not important. Duplicate values are al‐
+ lowed. An empty map is represented as {}. Curly braces may optionally
enclose non-empty maps as well (but use quotes to prevent the shell
- from expanding other-config={0=x,1=y} into other-config=0=x other-con‐
+ from expanding other-config={0=x,1=y} into other-config=0=x other-con‐‐
fig=1=y, which may not have the desired effect).
Database Command Syntax
- [--if-exists] [--columns=column[,column]...] list table
+ [--if-exists] [--columns=column[,column]...] list table
[record]...
- Lists the data in each specified record. If no records
+ Lists the data in each specified record. If no records
are specified, lists all the records in table.
If --columns is specified, only the requested columns are
@@ -721,32 +718,32 @@
are listed, in alphabetical order by column name.
Without --if-exists, it is an error if any specified
- record does not exist. With --if-exists, the command
- ignores any record that does not exist, without producing
+ record does not exist. With --if-exists, the command ig‐
+ nores any record that does not exist, without producing
any output.
- [--columns=column[,column]...] find table [col‐
+ [--columns=column[,column]...] find table [col
umn[:key]=value]...
- Lists the data in each record in table whose column
- equals value or, if key is specified, whose column con‐
+ Lists the data in each record in table whose column
+ equals value or, if key is specified, whose column con‐
tains a key with the specified value. The following oper‐
ators may be used where = is written in the syntax sum‐
mary:
= != gt;>gt; = >gt;>gt;=
Selects records in which column[:key] equals, does
- not equal, is less than, is greater than, is less
- than or equal to, or is greater than or equal to
+ not equal, is less than, is greater than, is less
+ than or equal to, or is greater than or equal to
value, respectively.
- Consider column[:key] and value as sets of ele‐
+ Consider column[:key] and value as sets of ele‐
ments. Identical sets are considered equal. Other‐
wise, if the sets have different numbers of ele‐
ments, then the set with more elements is consid‐
ered to be larger. Otherwise, consider a element
from each set pairwise, in increasing order within
- each set. The first pair that differs determines
- the result. (For a column that contains key-value
+ each set. The first pair that differs determines
+ the result. (For a column that contains key-value
pairs, first all the keys are compared, and values
are considered only if the two sets contain iden‐
tical keys.)
@@ -765,30 +762,30 @@
the empty set or contains 1 or 2 but not both.
{>gt;>gt;=} {>gt;>gt;}
- Same as {=} and {}, respectively, except that
- the relationship is reversed. For example,
- flood-vlans{>gt;>gt;=}1,2 selects records in which the
+ Same as {=} and {}, respectively, except that
+ the relationship is reversed. For example,
+ flood-vlans{>gt;>gt;=}1,2 selects records in which the
flood-vlans column contains both 1 and 2.
The following operators are available only in Open
vSwitch 2.16 and later:
- {in} Selects records in which every element in col‐
- umn[:key] is also in value. (This is the same as
+ {in} Selects records in which every element in col
+ umn[:key] is also in value. (This is the same as
{=}.)
{not-in}
- Selects records in which every element in col‐
+ Selects records in which every element in col
umn[:key] is not in value.
- For arithmetic operators (= != gt;>gt; = >gt;>gt;=), when key is
- specified but a particular record’s column does not con‐
- tain key, the record is always omitted from the results.
- Thus, the condition other-config:mtu!=1500 matches
- records that have a mtu key whose value is not 1500, but
+ For arithmetic operators (= != gt;>gt; = >gt;>gt;=), when key is
+ specified but a particular record’s column does not con‐
+ tain key, the record is always omitted from the results.
+ Thus, the condition other-config:mtu!=1500 matches
+ records that have a mtu key whose value is not 1500, but
not those that lack an mtu key.
- For the set operators, when key is specified but a par‐
+ For the set operators, when key is specified but a par‐
ticular record’s column does not contain key, the compar‐
ison is done against an empty set. Thus, the condition
other-config:mtu{!=}1500 matches records that have a mtu
@@ -816,9 +813,9 @@
record. With --if-exists, a missing record yields no out‐
put and a missing key prints a blank line.
- If @name is specified, then the UUID for record may be
- referred to by that name later in the same ovs-vsctl
- invocation in contexts where a UUID is expected.
+ If @name is specified, then the UUID for record may be
+ referred to by that name later in the same ovs-vsctl in‐
+ vocation in contexts where a UUID is expected.
Both --id and the column arguments are optional, but usu‐
ally at least one or the other should be specified. If
@@ -828,41 +825,40 @@
--id and --if-exists cannot be used together.
[--if-exists] set table record column[:key]=value...
- Sets the value of each specified column in the given
- record in table to value. For map columns, a key may
- optionally be specified, in which case the value associ‐
- ated with key in that column is changed (or added, if
- none exists), instead of the entire map.
+ Sets the value of each specified column in the given
+ record in table to value. For map columns, a key may op‐
+ tionally be specified, in which case the value associated
+ with key in that column is changed (or added, if none ex‐
+ ists), instead of the entire map.
- Without --if-exists, it is an error if record does not
- exist. With --if-exists, this command does nothing if
+ Without --if-exists, it is an error if record does not
+ exist. With --if-exists, this command does nothing if
record does not exist.
[--if-exists] add table record column [key=]value...
- Adds the specified value or key-value pair to column in
- record in table. If column is a map, then key is
- required, otherwise it is prohibited. If key already
- exists in a map column, then the current value is not
- replaced (use the set command to replace an existing
- value).
+ Adds the specified value or key-value pair to column in
+ record in table. If column is a map, then key is re‐
+ quired, otherwise it is prohibited. If key already exists
+ in a map column, then the current value is not replaced
+ (use the set command to replace an existing value).
- Without --if-exists, it is an error if record does not
- exist. With --if-exists, this command does nothing if
+ Without --if-exists, it is an error if record does not
+ exist. With --if-exists, this command does nothing if
record does not exist.
[--if-exists] remove table record column value...
[--if-exists] remove table record column key...
- [--if-exists] remove table record column key=value...
- Removes the specified values or key-value pairs from col‐
+ [--if-exists] remove table record column key=value...
+ Removes the specified values or key-value pairs from col
umn in record in table. The first form applies to columns
- that are not maps: each specified value is removed from
- the column. The second and third forms apply to map col‐
- umns: if only a key is specified, then any key-value pair
- with the given key is removed, regardless of its value;
- if a value is given then a pair is removed only if both
- key and value match.
+ that are not maps: each specified value is removed from
+ the column. The second and third forms apply to map
+ columns: if only a key is specified, then any key-value
+ pair with the given key is removed, regardless of its
+ value; if a value is given then a pair is removed only if
+ both key and value match.
It is not an error if the column does not contain the
specified key or value or pair.
@@ -882,12 +878,12 @@
[--id=(@name|uuid)] create table column[:key]=value...
Creates a new record in table and sets the initial values
- of each column. Columns not explicitly set will receive
+ of each column. Columns not explicitly set will receive
their default values. Outputs the UUID of the new row.
- If @name is specified, then the UUID for the new row may
- be referred to by that name elsewhere in the same \*(PN
- invocation in contexts where a UUID is expected. Such
+ If @name is specified, then the UUID for the new row may
+ be referred to by that name elsewhere in the same \*(PN
+ invocation in contexts where a UUID is expected. Such
references may precede or follow the create command.
If a valid uuid is specified, then it is used as the UUID
@@ -895,23 +891,23 @@
Caution (ovs-vsctl as example)
Records in the Open vSwitch database are signifi‐
- cant only when they can be reached directly or
- indirectly from the Open_vSwitch table. Except for
- records in the QoS or Queue tables, records that
- are not reachable from the Open_vSwitch table are
+ cant only when they can be reached directly or in‐
+ directly from the Open_vSwitch table. Except for
+ records in the QoS or Queue tables, records that
+ are not reachable from the Open_vSwitch table are
automatically deleted from the database. This
- deletion happens immediately, without waiting for
- additional ovs-vsctl commands or other database
+ deletion happens immediately, without waiting for
+ additional ovs-vsctl commands or other database
activity. Thus, a create command must generally be
accompanied by additional commands within the same
- ovs-vsctl invocation to add a chain of references
- to the newly created record from the top-level
- Open_vSwitch record. The EXAMPLES section gives
+ ovs-vsctl invocation to add a chain of references
+ to the newly created record from the top-level
+ Open_vSwitch record. The EXAMPLES section gives
some examples that show how to do this.
[--if-exists] destroy table record...
- Deletes each specified record from table. Unless
- --if-exists is specified, each records must exist.
+ Deletes each specified record from table. Unless --if-ex‐‐
+ ists is specified, each records must exist.
--all destroy table
Deletes all records from the table.
@@ -930,19 +926,19 @@
wait-until table record [column[:key]=value]...
Waits until table contains a record named record whose
column equals value or, if key is specified, whose column
- contains a key with the specified value. This command
- supports the same operators and semantics described for
+ contains a key with the specified value. This command
+ supports the same operators and semantics described for
the find command above.
- If no column[:key]=value arguments are given, this com‐
- mand waits only until record exists. If more than one
- such argument is given, the command waits until all of
+ If no column[:key]=value arguments are given, this com‐
+ mand waits only until record exists. If more than one
+ such argument is given, the command waits until all of
them are satisfied.
Caution (ovs-vsctl as example)
- Usually wait-until should be placed at the begin‐
- ning of a set of ovs-vsctl commands. For example,
- wait-until bridge br0 -- get bridge br0 data‐
+ Usually wait-until should be placed at the begin‐
+ ning of a set of ovs-vsctl commands. For example,
+ wait-until bridge br0 -- get bridge br0 data‐‐
path_id waits until a bridge named br0 is created,
then prints its datapath_id column, whereas get
bridge br0 datapath_id -- wait-until bridge br0
@@ -964,11 +960,11 @@
server process. See Daemon Mode, above, for more information.
OVN_SBCTL_OPTIONS
- If set, a set of options for ovn-sbctl to apply automatically,
+ If set, a set of options for ovn-sbctl to apply automatically,
in the same form as on the command line.
OVN_SB_DB
- If set, the default database to contact when the --db option is
+ If set, the default database to contact when the --db option is
not used.
EXIT STATUS
@@ -979,7 +975,5 @@
SEE ALSO
ovn-sb(5), ovn-appctl(8).
-
-
-OVN 22.12.90 ovn-sbctl ovn-sbctl(8)
+OVN 24.03.90 ovn-sbctl ovn-sbctl(8)
diff --git a/src/static/support/dist-docs/ovn-sbctl.8.pdf b/src/static/support/dist-docs/ovn-sbctl.8.pdf
index 7997821c..6106b95f 100644
Binary files a/src/static/support/dist-docs/ovn-sbctl.8.pdf and b/src/static/support/dist-docs/ovn-sbctl.8.pdf differ
diff --git a/src/static/support/dist-docs/ovn-sbctl.8.txt b/src/static/support/dist-docs/ovn-sbctl.8.txt
index b95291c9..dde93a2b 100644
--- a/src/static/support/dist-docs/ovn-sbctl.8.txt
+++ b/src/static/support/dist-docs/ovn-sbctl.8.txt
@@ -1,7 +1,5 @@
ovn-sbctl(8) OVN Manual ovn-sbctl(8)
-
-
NAME
ovn-sbctl - Open Virtual Network southbound db management utility
@@ -21,20 +19,20 @@ DESCRIPTION
ovn-sbctl can perform any number of commands in a single run, imple‐
mented as a single atomic transaction against the database.
- The ovn-sbctl command line begins with global options (see OPTIONS
- below for details). The global options are followed by one or more com‐
+ The ovn-sbctl command line begins with global options (see OPTIONS be‐
+ low for details). The global options are followed by one or more com‐
mands. Each command should begin with -- by itself as a command-line
argument, to separate it from the following commands. (The -- before
the first command is optional.) The command itself starts with command-
- specific options, if any, followed by the command name and any argu‐
+ specific options, if any, followed by the command name and any argu‐
ments.
DAEMON MODE
- When it is invoked in the most ordinary way, ovn-sbctl connects to an
- OVSDB server that hosts the southbound database, retrieves a partial
- copy of the database that is complete enough to do its work, sends a
- transaction request to the server, and receives and processes the
- server’s reply. In common interactive use, this is fine, but if the
+ When it is invoked in the most ordinary way, ovn-sbctl connects to an
+ OVSDB server that hosts the southbound database, retrieves a partial
+ copy of the database that is complete enough to do its work, sends a
+ transaction request to the server, and receives and processes the
+ server’s reply. In common interactive use, this is fine, but if the
database is large, the step in which ovn-sbctl retrieves a partial copy
of the database can take a long time, which yields poor performance
overall.
@@ -42,22 +40,22 @@ DAEMON MODE
To improve performance in such a case, ovn-sbctl offers a "daemon
mode," in which the user first starts ovn-sbctl running in the back‐
ground and afterward uses the daemon to execute operations. Over sev‐
- eral ovn-sbctl command invocations, this performs better overall
- because it retrieves a copy of the database only once at the beginning,
+ eral ovn-sbctl command invocations, this performs better overall be‐
+ cause it retrieves a copy of the database only once at the beginning,
not once per program run.
Use the --detach option to start an ovn-sbctl daemon. With this option,
- ovn-sbctl prints the name of a control socket to stdout. The client
- should save this name in environment variable OVN_SB_DAEMON. Under the
+ ovn-sbctl prints the name of a control socket to stdout. The client
+ should save this name in environment variable OVN_SB_DAEMON. Under the
Bourne shell this might be done like this:
export OVN_SB_DAEMON=$(ovn-sbctl --pidfile --detach)
- When OVN_SB_DAEMON is set, ovn-sbctl automatically and transparently
+ When OVN_SB_DAEMON is set, ovn-sbctl automatically and transparently
uses the daemon to execute its commands.
- When the daemon is no longer needed, kill it and unset the environment
+ When the daemon is no longer needed, kill it and unset the environment
variable, e.g.:
kill $(cat $OVN_RUNDIR/ovn-sbctl.pid)
@@ -84,23 +82,23 @@ DAEMON MODE
ovn-appctl. One may also use ovn-appctl directly with the following
commands:
- run [options] command [arg...] [-- [options] command [arg...]
+ run [options] command [arg...] [-- [options] command [arg...]
...]
Instructs the daemon process to run one or more ovn-sbctl
commands described above and reply with the results of
running these commands. Accepts the --no-wait, --wait,
- --timeout, --dry-run, --oneline, and the options
- described under Table Formatting Options in addition to
- the the command-specific options.
+ --timeout, --dry-run, --oneline, and the options de‐
+ scribed under Table Formatting Options in addition to the
+ the command-specific options.
exit Causes ovn-sbctl to gracefully terminate.
OPTIONS
- The options listed below affect the behavior of ovn-sbctl as a whole.
+ The options listed below affect the behavior of ovn-sbctl as a whole.
Some individual commands also accept their own options, which are given
just before the command name. If the first command on the command line
- has options, then those options must be separated from the global
- options by --.
+ has options, then those options must be separated from the global op‐
+ tions by --.
ovn-sbctl also accepts options from the OVN_SBCTL_OPTIONS environment
variable, in the same format as on the command line. Options from the
@@ -108,10 +106,10 @@ OPTIONS
--db database
The OVSDB database remote to contact. If the OVN_SB_DB
- environment variable is set, its value is used as the
- default. Otherwise, the default is unix:/ovnsb_db.sock,
- but this default is unlikely to be useful outside of sin‐
- gle-machine OVN test environments.
+ environment variable is set, its value is used as the de‐
+ fault. Otherwise, the default is unix:/ovnsb_db.sock, but
+ this default is unlikely to be useful outside of single-
+ machine OVN test environments.
--leader-only
--no-leader-only
@@ -121,7 +119,7 @@ OPTIONS
ovn-sbctl reads and reports is up-to-date. With
--no-leader-only, ovn-sbctl will use any server in the
cluster, which means that for read-only transactions it can
- report and act on stale data (transactions that modify the
+ report and act on stale data (transactions that modify the
database are always serialized even with --no-leader-only).
Refer to Understanding Cluster Consistency in ovsdb(7) for
more information.
@@ -135,11 +133,11 @@ OPTIONS
tries to connect. The remotes will be shuffled only once to
a new order before the first connection attempt. The fol‐
lowing retries, if any, will follow the same new order. The
- default behavior is to make sure clients of a clustered
- database can distribute evenly to all members of the clus‐
- ter. With --no-shuffle-remotes, ovn-sbctl will use the
- original order specified in the connection string to con‐
- nect. This allows user to specify the preferred order,
+ default behavior is to make sure clients of a clustered
+ database can distribute evenly to all members of the clus‐
+ ter. With --no-shuffle-remotes, ovn-sbctl will use the
+ original order specified in the connection string to con‐
+ nect. This allows user to specify the preferred order,
which is particularly useful for testing.
--no-syslog
@@ -151,10 +149,10 @@ OPTIONS
--oneline
Modifies the output format so that the output for each com‐
- mand is printed on a single line. New-line characters that
- would otherwise separate lines are printed as \fB\\n\fR,
- and any instances of \fB\\\fR that would otherwise appear
- in the output are doubled. Prints a blank line for each
+ mand is printed on a single line. New-line characters that
+ would otherwise separate lines are printed as \fB\\n\fR,
+ and any instances of \fB\\\fR that would otherwise appear
+ in the output are doubled. Prints a blank line for each
command that has no output. This option does not affect the
formatting of output from the list or find commands; see
Table Formatting Options below.
@@ -174,7 +172,7 @@ OPTIONS
Daemon Options
--pidfile[=pidfile]
Causes a file (by default, program.pid) to be created indicating
- the PID of the running process. If the pidfile argument is not
+ the PID of the running process. If the pidfile argument is not
specified, or if it does not begin with /, then it is created in
.
@@ -192,13 +190,13 @@ OPTIONS
Runs this program as a background process. The process forks,
and in the child it starts a new session, closes the standard
file descriptors (which has the side effect of disabling logging
- to the console), and changes its current directory to the root
- (unless --no-chdir is specified). After the child completes its
+ to the console), and changes its current directory to the root
+ (unless --no-chdir is specified). After the child completes its
initialization, the parent exits.
--monitor
- Creates an additional process to monitor this program. If it
- dies due to a signal that indicates a programming error (SIGA‐
+ Creates an additional process to monitor this program. If it
+ dies due to a signal that indicates a programming error (SIGA‐
BRT, SIGALRM, SIGBUS, SIGFPE, SIGILL, SIGPIPE, SIGSEGV, SIGXCPU,
or SIGXFSZ) then the monitor process starts a new copy of it. If
the daemon dies or exits for another reason, the monitor process
@@ -209,10 +207,10 @@ OPTIONS
--no-chdir
By default, when --detach is specified, the daemon changes its
- current working directory to the root directory after it
- detaches. Otherwise, invoking the daemon from a carelessly cho‐
- sen directory would prevent the administrator from unmounting
- the file system that holds that directory.
+ current working directory to the root directory after it de‐
+ taches. Otherwise, invoking the daemon from a carelessly chosen
+ directory would prevent the administrator from unmounting the
+ file system that holds that directory.
Specifying --no-chdir suppresses this behavior, preventing the
daemon from changing its current working directory. This may be
@@ -231,21 +229,21 @@ OPTIONS
implementations that are typically enforced from kernel-space
(e.g. DAC or MAC), self-confinement is imposed from the user-
space daemon itself and hence should not be considered as a full
- confinement strategy, but instead should be viewed as an addi‐
+ confinement strategy, but instead should be viewed as an addi‐
tional layer of security.
--user=user:group
- Causes this program to run as a different user specified in
- user:group, thus dropping most of the root privileges. Short
- forms user and :group are also allowed, with current user or
- group assumed, respectively. Only daemons started by the root
+ Causes this program to run as a different user specified in
+ user:group, thus dropping most of the root privileges. Short
+ forms user and :group are also allowed, with current user or
+ group assumed, respectively. Only daemons started by the root
user accepts this argument.
On Linux, daemons will be granted CAP_IPC_LOCK and
- CAP_NET_BIND_SERVICES before dropping root privileges. Daemons
- that interact with a datapath, such as ovs-vswitchd, will be
- granted three additional capabilities, namely CAP_NET_ADMIN,
- CAP_NET_BROADCAST and CAP_NET_RAW. The capability change will
+ CAP_NET_BIND_SERVICES before dropping root privileges. Daemons
+ that interact with a datapath, such as ovs-vswitchd, will be
+ granted three additional capabilities, namely CAP_NET_ADMIN,
+ CAP_NET_BROADCAST and CAP_NET_RAW. The capability change will
apply even if the new user is root.
On Windows, this option is not currently supported. For security
@@ -260,13 +258,13 @@ OPTIONS
words separated by spaces or commas or colons, up to one from each
category below:
- · A valid module name, as displayed by the vlog/list command
+ • A valid module name, as displayed by the vlog/list command
on ovs-appctl(8), limits the log level change to the speci‐
fied module.
- · syslog, console, or file, to limit the log level change to
- only to the system log, to the console, or to a file,
- respectively. (If --detach is specified, the daemon closes
+ • syslog, console, or file, to limit the log level change to
+ only to the system log, to the console, or to a file, re‐
+ spectively. (If --detach is specified, the daemon closes
its standard file descriptors, so logging to the console
will have no effect.)
@@ -274,15 +272,15 @@ OPTIONS
only useful along with the --syslog-target option (the word
has no effect otherwise).
- · off, emer, err, warn, info, or dbg, to control the log
- level. Messages of the given severity or higher will be
- logged, and messages of lower severity will be filtered
- out. off filters out all messages. See ovs-appctl(8) for a
+ • off, emer, err, warn, info, or dbg, to control the log
+ level. Messages of the given severity or higher will be
+ logged, and messages of lower severity will be filtered
+ out. off filters out all messages. See ovs-appctl(8) for a
definition of each log level.
Case is not significant within spec.
- Regardless of the log levels set for file, logging to a file will
+ Regardless of the log levels set for file, logging to a file will
not take place unless --log-file is also specified (see below).
For compatibility with older versions of OVS, any is accepted as a
@@ -290,22 +288,22 @@ OPTIONS
-v
--verbose
- Sets the maximum logging verbosity level, equivalent to --ver‐
+ Sets the maximum logging verbosity level, equivalent to --ver‐
bose=dbg.
-vPATTERN:destination:pattern
--verbose=PATTERN:destination:pattern
- Sets the log pattern for destination to pattern. Refer to
- ovs-appctl(8) for a description of the valid syntax for pattern.
+ Sets the log pattern for destination to pattern. Refer to ovs-ap‐
+ pctl(8) for a description of the valid syntax for pattern.
-vFACILITY:facility
--verbose=FACILITY:facility
Sets the RFC5424 facility of the log message. facility can be one
of kern, user, mail, daemon, auth, syslog, lpr, news, uucp, clock,
- ftp, ntp, audit, alert, clock2, local0, local1, local2, local3,
+ ftp, ntp, audit, alert, clock2, local0, local1, local2, local3,
local4, local5, local6 or local7. If this option is not specified,
- daemon is used as the default for the local system syslog and
- local0 is used while sending a message to the target provided via
+ daemon is used as the default for the local system syslog and lo‐
+ cal0 is used while sending a message to the target provided via
the --syslog-target option.
--log-file[=file]
@@ -314,111 +312,111 @@ OPTIONS
if file is omitted is /usr/local/var/log/ovn/program.log.
--syslog-target=host:port
- Send syslog messages to UDP port on host, in addition to the sys‐
- tem syslog. The host must be a numerical IP address, not a host‐
+ Send syslog messages to UDP port on host, in addition to the sys‐
+ tem syslog. The host must be a numerical IP address, not a host‐
name.
--syslog-method=method
- Specify method as how syslog messages should be sent to syslog
+ Specify method as how syslog messages should be sent to syslog
daemon. The following forms are supported:
- · libc, to use the libc syslog() function. Downside of using
- this options is that libc adds fixed prefix to every mes‐
- sage before it is actually sent to the syslog daemon over
+ • libc, to use the libc syslog() function. Downside of using
+ this options is that libc adds fixed prefix to every mes‐
+ sage before it is actually sent to the syslog daemon over
/dev/log UNIX domain socket.
- · unix:file, to use a UNIX domain socket directly. It is pos‐
+ • unix:file, to use a UNIX domain socket directly. It is pos‐
sible to specify arbitrary message format with this option.
- However, rsyslogd 8.9 and older versions use hard coded
- parser function anyway that limits UNIX domain socket use.
- If you want to use arbitrary message format with older
- rsyslogd versions, then use UDP socket to localhost IP
- address instead.
-
- · udp:ip:port, to use a UDP socket. With this method it is
- possible to use arbitrary message format also with older
- rsyslogd. When sending syslog messages over UDP socket
- extra precaution needs to be taken into account, for exam‐
- ple, syslog daemon needs to be configured to listen on the
- specified UDP port, accidental iptables rules could be
- interfering with local syslog traffic and there are some
- security considerations that apply to UDP sockets, but do
- not apply to UNIX domain sockets.
-
- · null, to discard all messages logged to syslog.
-
- The default is taken from the OVS_SYSLOG_METHOD environment vari‐
+ However, rsyslogd 8.9 and older versions use hard coded
+ parser function anyway that limits UNIX domain socket use.
+ If you want to use arbitrary message format with older
+ rsyslogd versions, then use UDP socket to localhost IP ad‐
+ dress instead.
+
+ • udp:ip:port, to use a UDP socket. With this method it is
+ possible to use arbitrary message format also with older
+ rsyslogd. When sending syslog messages over UDP socket ex‐
+ tra precaution needs to be taken into account, for example,
+ syslog daemon needs to be configured to listen on the spec‐
+ ified UDP port, accidental iptables rules could be inter‐
+ fering with local syslog traffic and there are some secu‐
+ rity considerations that apply to UDP sockets, but do not
+ apply to UNIX domain sockets.
+
+ • null, to discard all messages logged to syslog.
+
+ The default is taken from the OVS_SYSLOG_METHOD environment vari‐
able; if it is unset, the default is libc.
Table Formatting Options
- These options control the format of output from the list and find com‐
+ These options control the format of output from the list and find com‐
mands.
-f format
--format=format
- Sets the type of table formatting. The following types of
+ Sets the type of table formatting. The following types of
format are available:
table 2-D text tables with aligned columns.
list (default)
- A list with one column per line and rows separated
+ A list with one column per line and rows separated
by a blank line.
html HTML tables.
csv Comma-separated values as defined in RFC 4180.
- json JSON format as defined in RFC 4627. The output is a
- sequence of JSON objects, each of which corresponds
- to one table. Each JSON object has the following
+ json JSON format as defined in RFC 4627. The output is a
+ sequence of JSON objects, each of which corresponds
+ to one table. Each JSON object has the following
members with the noted values:
caption
- The table’s caption. This member is omitted
+ The table’s caption. This member is omitted
if the table has no caption.
headings
- An array with one element per table column.
- Each array element is a string giving the
+ An array with one element per table column.
+ Each array element is a string giving the
corresponding column’s heading.
data An array with one element per table row. Each
element is also an array with one element per
- table column. The elements of this second-
+ table column. The elements of this second-
level array are the cells that constitute the
table. Cells that represent OVSDB data or
- data types are expressed in the format
- described in the OVSDB specification; other
+ data types are expressed in the format de‐
+ scribed in the OVSDB specification; other
cells are simply expressed as text strings.
-d format
--data=format
Sets the formatting for cells within output tables unless
the table format is set to json, in which case json format‐
- ting is always used when formatting cells. The following
+ ting is always used when formatting cells. The following
types of format are available:
string (default)
- The simple format described in the Database Values
+ The simple format described in the Database Values
section of ovs-vsctl(8).
- bare The simple format with punctuation stripped off: []
- and {} are omitted around sets, maps, and empty col‐
- umns, items within sets and maps are space-sepa‐
+ bare The simple format with punctuation stripped off: []
+ and {} are omitted around sets, maps, and empty
+ columns, items within sets and maps are space-sepa‐
rated, and strings are never quoted. This format may
be easier for scripts to parse.
json The RFC 4627 JSON format as described above.
--no-headings
- This option suppresses the heading row that otherwise
- appears in the first row of table output.
+ This option suppresses the heading row that otherwise ap‐
+ pears in the first row of table output.
--pretty
By default, JSON in output is printed as compactly as pos‐
sible. This option causes JSON in output to be printed in a
- more readable fashion. Members of objects and elements of
+ more readable fashion. Members of objects and elements of
arrays are printed one per line, with indentation.
This option does not affect JSON in tables, which is always
@@ -450,22 +448,22 @@ OPTIONS
ifying certificates presented to this program by SSL peers.
(This may be the same certificate that SSL peers use to
verify the certificate specified on -c or --certificate, or
- it may be a different one, depending on the PKI design in
+ it may be a different one, depending on the PKI design in
use.)
-C none
--ca-cert=none
- Disables verification of certificates presented by SSL
- peers. This introduces a security risk, because it means
- that certificates cannot be verified to be those of known
+ Disables verification of certificates presented by SSL
+ peers. This introduces a security risk, because it means
+ that certificates cannot be verified to be those of known
trusted hosts.
--bootstrap-ca-cert=cacert.pem
- When cacert.pem exists, this option has the same effect
- as -C or --ca-cert. If it does not exist, then the exe‐
- cutable will attempt to obtain the CA certificate from
- the SSL peer on its first SSL connection and save it to
- the named PEM file. If it is successful, it will immedi‐
+ When cacert.pem exists, this option has the same effect
+ as -C or --ca-cert. If it does not exist, then the exe‐
+ cutable will attempt to obtain the CA certificate from
+ the SSL peer on its first SSL connection and save it to
+ the named PEM file. If it is successful, it will immedi‐
ately drop the connection and reconnect, and from then on
all SSL connections must be authenticated by a certifi‐
cate signed by the CA certificate thus obtained.
@@ -476,7 +474,7 @@ OPTIONS
This option is only useful if the SSL peer sends its CA
certificate as part of the SSL certificate chain. The SSL
- protocol does not require the server to send the CA cer‐
+ protocol does not require the server to send the CA cer‐
tificate.
This option is mutually exclusive with -C and --ca-cert.
@@ -528,20 +526,20 @@ COMMANDS
Binds the logical port named logical-port to chassis.
Without --may-exist, attempting to bind a logical port
- that has already been bound is an error. With
- --may-exist, this command does nothing if logical-port
- has already been bound to a chassis.
+ that has already been bound is an error. With --may-ex‐
+ ist, this command does nothing if logical-port has al‐
+ ready been bound to a chassis.
[--if-exists] lsp-unbind logical-port
Removes the binding of logical-port.
Without --if-exists, attempting to unbind a logical port
that is not bound is an error. With --if-exists, attempt‐
- ing to unbind logical port that is not bound has no
- effect.
+ ing to unbind logical port that is not bound has no ef‐
+ fect.
Logical Flow Commands
- [--uuid] [--ovs[=remote]] [--stats] [--vflows] lflow-list [logical-
+ [--uuid] [--ovs[=remote]] [--stats] [--vflows] lflow-list [logical-
datapath] [lflow...]
List logical flows. If logical-datapath is specified, only list
flows for that logical datapath. The logical-datapath may be
@@ -550,9 +548,9 @@ COMMANDS
If at least one lflow is given, only matching logical flows, if
any, are listed. Each lflow may be specified as a UUID or the
- first few characters of a UUID, optionally prefixed by 0x.
- (Because ovn-controller sets OpenFlow flow cookies to the first
- 32 bits of the corresponding logical flow’s UUID, this makes it
+ first few characters of a UUID, optionally prefixed by 0x. (Be‐
+ cause ovn-controller sets OpenFlow flow cookies to the first 32
+ bits of the corresponding logical flow’s UUID, this makes it
easy to look up the logical flow that generated a particular
OpenFlow flow.)
@@ -563,21 +561,21 @@ COMMANDS
If --ovs is included, ovn-sbctl attempts to obtain and display
the OpenFlow flows that correspond to each OVN logical flow. To
do so, ovn-sbctl connects to remote (by default,
- unix:/br-int.mgmt) over OpenFlow and retrieves the flows. If
- remote is specified, it must be an active OpenFlow connection
- method described in ovsdb(7). Please see the discussion of the
- similar --ovs option in ovn-trace(8) for more information about
+ unix:/br-int.mgmt) over OpenFlow and retrieves the flows. If re‐
+ mote is specified, it must be an active OpenFlow connection
+ method described in ovsdb(7). Please see the discussion of the
+ similar --ovs option in ovn-trace(8) for more information about
the OpenFlow flow output.
- By default, OpenFlow flow output includes only match and
- actions. Add --stats to include all OpenFlow information, such
- as packet and byte counters, duration, and timeouts.
+ By default, OpenFlow flow output includes only match and ac‐
+ tions. Add --stats to include all OpenFlow information, such as
+ packet and byte counters, duration, and timeouts.
- If --vflows is included, other southbound database records
- directly used for generating OpenFlow flows are also listed.
- This includes: port-bindings, mac-bindings, multicast-groups,
- chassis. The --ovs and --stats can also be used in conjunction
- with --vflows.
+ If --vflows is included, other southbound database records di‐
+ rectly used for generating OpenFlow flows are also listed. This
+ includes: port-bindings, mac-bindings, multicast-groups, chas‐
+ sis. The --ovs and --stats can also be used in conjunction with
+ --vflows.
[--uuid] dump-flows [logical-datapath]
Alias for lflow-list.
@@ -588,9 +586,8 @@ COMMANDS
Remote Connectivity Commands
These commands manipulate the connections column in the SB_Global table
and rows in the Connection table. When ovsdb-server is configured to
- use the connections column for OVSDB connections, this allows the
- administrator to use \fBovn\-sbctl\fR to configure database connec‐
- tions.
+ use the connections column for OVSDB connections, this allows the ad‐
+ ministrator to use \fBovn\-sbctl\fR to configure database connections.
get-connection
Prints the configured connection(s).
@@ -599,30 +596,30 @@ COMMANDS
Deletes the configured connection(s).
[--inactivity-probe=msecs] set-connection target...
- Sets the configured manager target or targets. Use
- --inactivity-probe=msecs to override the default idle
- connection inactivity probe time. Use 0 to disable inac‐
- tivity probes.
+ Sets the configured manager target or targets. Use --in‐
+ activity-probe=msecs to override the default idle connec‐
+ tion inactivity probe time. Use 0 to disable inactivity
+ probes.
SSL Configuration Commands
- When ovsdb-server is configured to connect using SSL, the following
- parameters are required:
+ When ovsdb-server is configured to connect using SSL, the following pa‐
+ rameters are required:
private-key
- Specifies a PEM file containing the private key used for
+ Specifies a PEM file containing the private key used for
SSL connections.
certificate
- Specifies a PEM file containing a certificate, signed by
- the certificate authority (CA) used by the connection
- peers, that certifies the private key, identifying a
+ Specifies a PEM file containing a certificate, signed by
+ the certificate authority (CA) used by the connection
+ peers, that certifies the private key, identifying a
trustworthy peer.
ca-cert
- Specifies a PEM file containing the CA certificate used
+ Specifies a PEM file containing the CA certificate used
to verify that the connection peers are trustworthy.
- These SSL settings apply to all SSL connections made by the southbound
+ These SSL settings apply to all SSL connections made by the southbound
database server.
get-ssl
@@ -631,7 +628,7 @@ COMMANDS
del-ssl
Deletes the current SSL configuration.
- [--bootstrap] set-ssl private-key certificate ca-cert [ssl-pro‐
+ [--bootstrap] set-ssl private-key certificate ca-cert [ssl-pro‐
tocol-list [ssl-cipher-list]]
Sets the SSL configuration.
@@ -644,20 +641,20 @@ COMMANDS
Each of these commands has a table parameter to identify a table within
the database. Many of them also take a record parameter that identifies
- a particular record within a table. The record parameter may be the
- UUID for a record, which may be abbreviated to its first 4 (or more)
- hex digits, as long as that is unique. Many tables offer additional
- ways to identify records. Some commands also take column parameters
+ a particular record within a table. The record parameter may be the
+ UUID for a record, which may be abbreviated to its first 4 (or more)
+ hex digits, as long as that is unique. Many tables offer additional
+ ways to identify records. Some commands also take column parameters
that identify a particular field within the records in a table.
- For a list of tables and their columns, see ovn-sb(5) or see the table
+ For a list of tables and their columns, see ovn-sb(5) or see the table
listing from the --help option.
Record names must be specified in full and with correct capitalization,
except that UUIDs may be abbreviated to their first 4 (or more) hex
digits, as long as that is unique within the table. Names of tables and
- columns are not case-sensitive, and - and _ are treated interchange‐
- ably. Unique abbreviations of table and column names are acceptable,
+ columns are not case-sensitive, and - and _ are treated interchange‐
+ ably. Unique abbreviations of table and column names are acceptable,
e.g. d or dhcp is sufficient to identify the DHCP_Options table.
Database Values
@@ -679,40 +676,40 @@ COMMANDS
begin with an English letter or underscore and consist
only of letters, underscores, hyphens, and periods. How‐
ever, true and false and strings that match the syntax of
- UUIDs (see below) must be enclosed in double quotes to
- distinguish them from other basic types. When double
- quotes are used, the syntax is that of strings in JSON,
- e.g. backslashes may be used to escape special charac‐
- ters. The empty string must be represented as a pair of
+ UUIDs (see below) must be enclosed in double quotes to
+ distinguish them from other basic types. When double
+ quotes are used, the syntax is that of strings in JSON,
+ e.g. backslashes may be used to escape special charac‐
+ ters. The empty string must be represented as a pair of
double quotes ("").
- UUID Either a universally unique identifier in the style of
- RFC 4122, e.g. f81d4fae-7dec-11d0-a765-00a0c91e6bf6, or
- an @name defined by a get or create command within the
+ UUID Either a universally unique identifier in the style of
+ RFC 4122, e.g. f81d4fae-7dec-11d0-a765-00a0c91e6bf6, or
+ an @name defined by a get or create command within the
same ovs-vsctl invocation.
Multiple values in a single column may be separated by spaces or a sin‐
- gle comma. When multiple values are present, duplicates are not
- allowed, and order is not important. Conversely, some database columns
+ gle comma. When multiple values are present, duplicates are not al‐
+ lowed, and order is not important. Conversely, some database columns
can have an empty set of values, represented as [], and square brackets
may optionally enclose other non-empty sets or single values as well.
- A few database columns are ``maps’’ of key-value pairs, where the key
+ A few database columns are ``maps’’ of key-value pairs, where the key
and the value are each some fixed database type. These are specified in
the form key=value, where key and value follow the syntax for the col‐
umn’s key type and value type, respectively. When multiple pairs are
- present (separated by spaces or a comma), duplicate keys are not
- allowed, and again the order is not important. Duplicate values are
- allowed. An empty map is represented as {}. Curly braces may optionally
+ present (separated by spaces or a comma), duplicate keys are not al‐
+ lowed, and again the order is not important. Duplicate values are al‐
+ lowed. An empty map is represented as {}. Curly braces may optionally
enclose non-empty maps as well (but use quotes to prevent the shell
- from expanding other-config={0=x,1=y} into other-config=0=x other-con‐
+ from expanding other-config={0=x,1=y} into other-config=0=x other-con‐
fig=1=y, which may not have the desired effect).
Database Command Syntax
- [--if-exists] [--columns=column[,column]...] list table
+ [--if-exists] [--columns=column[,column]...] list table
[record]...
- Lists the data in each specified record. If no records
+ Lists the data in each specified record. If no records
are specified, lists all the records in table.
If --columns is specified, only the requested columns are
@@ -720,32 +717,32 @@ COMMANDS
are listed, in alphabetical order by column name.
Without --if-exists, it is an error if any specified
- record does not exist. With --if-exists, the command
- ignores any record that does not exist, without producing
+ record does not exist. With --if-exists, the command ig‐
+ nores any record that does not exist, without producing
any output.
- [--columns=column[,column]...] find table [col‐
+ [--columns=column[,column]...] find table [col‐
umn[:key]=value]...
- Lists the data in each record in table whose column
- equals value or, if key is specified, whose column con‐
+ Lists the data in each record in table whose column
+ equals value or, if key is specified, whose column con‐
tains a key with the specified value. The following oper‐
ators may be used where = is written in the syntax sum‐
mary:
= != < > <= >=
Selects records in which column[:key] equals, does
- not equal, is less than, is greater than, is less
- than or equal to, or is greater than or equal to
+ not equal, is less than, is greater than, is less
+ than or equal to, or is greater than or equal to
value, respectively.
- Consider column[:key] and value as sets of ele‐
+ Consider column[:key] and value as sets of ele‐
ments. Identical sets are considered equal. Other‐
wise, if the sets have different numbers of ele‐
ments, then the set with more elements is consid‐
ered to be larger. Otherwise, consider a element
from each set pairwise, in increasing order within
- each set. The first pair that differs determines
- the result. (For a column that contains key-value
+ each set. The first pair that differs determines
+ the result. (For a column that contains key-value
pairs, first all the keys are compared, and values
are considered only if the two sets contain iden‐
tical keys.)
@@ -764,30 +761,30 @@ COMMANDS
the empty set or contains 1 or 2 but not both.
{>=} {>}
- Same as {<=} and {<}, respectively, except that
- the relationship is reversed. For example,
- flood-vlans{>=}1,2 selects records in which the
+ Same as {<=} and {<}, respectively, except that
+ the relationship is reversed. For example,
+ flood-vlans{>=}1,2 selects records in which the
flood-vlans column contains both 1 and 2.
The following operators are available only in Open
vSwitch 2.16 and later:
- {in} Selects records in which every element in col‐
- umn[:key] is also in value. (This is the same as
+ {in} Selects records in which every element in col‐
+ umn[:key] is also in value. (This is the same as
{<=}.)
{not-in}
- Selects records in which every element in col‐
+ Selects records in which every element in col‐
umn[:key] is not in value.
- For arithmetic operators (= != < > <= >=), when key is
- specified but a particular record’s column does not con‐
- tain key, the record is always omitted from the results.
- Thus, the condition other-config:mtu!=1500 matches
- records that have a mtu key whose value is not 1500, but
+ For arithmetic operators (= != < > <= >=), when key is
+ specified but a particular record’s column does not con‐
+ tain key, the record is always omitted from the results.
+ Thus, the condition other-config:mtu!=1500 matches
+ records that have a mtu key whose value is not 1500, but
not those that lack an mtu key.
- For the set operators, when key is specified but a par‐
+ For the set operators, when key is specified but a par‐
ticular record’s column does not contain key, the compar‐
ison is done against an empty set. Thus, the condition
other-config:mtu{!=}1500 matches records that have a mtu
@@ -815,9 +812,9 @@ COMMANDS
record. With --if-exists, a missing record yields no out‐
put and a missing key prints a blank line.
- If @name is specified, then the UUID for record may be
- referred to by that name later in the same ovs-vsctl
- invocation in contexts where a UUID is expected.
+ If @name is specified, then the UUID for record may be
+ referred to by that name later in the same ovs-vsctl in‐
+ vocation in contexts where a UUID is expected.
Both --id and the column arguments are optional, but usu‐
ally at least one or the other should be specified. If
@@ -827,41 +824,40 @@ COMMANDS
--id and --if-exists cannot be used together.
[--if-exists] set table record column[:key]=value...
- Sets the value of each specified column in the given
- record in table to value. For map columns, a key may
- optionally be specified, in which case the value associ‐
- ated with key in that column is changed (or added, if
- none exists), instead of the entire map.
+ Sets the value of each specified column in the given
+ record in table to value. For map columns, a key may op‐
+ tionally be specified, in which case the value associated
+ with key in that column is changed (or added, if none ex‐
+ ists), instead of the entire map.
- Without --if-exists, it is an error if record does not
- exist. With --if-exists, this command does nothing if
+ Without --if-exists, it is an error if record does not
+ exist. With --if-exists, this command does nothing if
record does not exist.
[--if-exists] add table record column [key=]value...
- Adds the specified value or key-value pair to column in
- record in table. If column is a map, then key is
- required, otherwise it is prohibited. If key already
- exists in a map column, then the current value is not
- replaced (use the set command to replace an existing
- value).
+ Adds the specified value or key-value pair to column in
+ record in table. If column is a map, then key is re‐
+ quired, otherwise it is prohibited. If key already exists
+ in a map column, then the current value is not replaced
+ (use the set command to replace an existing value).
- Without --if-exists, it is an error if record does not
- exist. With --if-exists, this command does nothing if
+ Without --if-exists, it is an error if record does not
+ exist. With --if-exists, this command does nothing if
record does not exist.
[--if-exists] remove table record column value...
[--if-exists] remove table record column key...
- [--if-exists] remove table record column key=value...
+ [--if-exists] remove table record column key=value...
Removes the specified values or key-value pairs from col‐
umn in record in table. The first form applies to columns
- that are not maps: each specified value is removed from
- the column. The second and third forms apply to map col‐
- umns: if only a key is specified, then any key-value pair
- with the given key is removed, regardless of its value;
- if a value is given then a pair is removed only if both
- key and value match.
+ that are not maps: each specified value is removed from
+ the column. The second and third forms apply to map
+ columns: if only a key is specified, then any key-value
+ pair with the given key is removed, regardless of its
+ value; if a value is given then a pair is removed only if
+ both key and value match.
It is not an error if the column does not contain the
specified key or value or pair.
@@ -881,12 +877,12 @@ COMMANDS
[--id=(@name|uuid)] create table column[:key]=value...
Creates a new record in table and sets the initial values
- of each column. Columns not explicitly set will receive
+ of each column. Columns not explicitly set will receive
their default values. Outputs the UUID of the new row.
- If @name is specified, then the UUID for the new row may
- be referred to by that name elsewhere in the same \*(PN
- invocation in contexts where a UUID is expected. Such
+ If @name is specified, then the UUID for the new row may
+ be referred to by that name elsewhere in the same \*(PN
+ invocation in contexts where a UUID is expected. Such
references may precede or follow the create command.
If a valid uuid is specified, then it is used as the UUID
@@ -894,23 +890,23 @@ COMMANDS
Caution (ovs-vsctl as example)
Records in the Open vSwitch database are signifi‐
- cant only when they can be reached directly or
- indirectly from the Open_vSwitch table. Except for
- records in the QoS or Queue tables, records that
- are not reachable from the Open_vSwitch table are
+ cant only when they can be reached directly or in‐
+ directly from the Open_vSwitch table. Except for
+ records in the QoS or Queue tables, records that
+ are not reachable from the Open_vSwitch table are
automatically deleted from the database. This
- deletion happens immediately, without waiting for
- additional ovs-vsctl commands or other database
+ deletion happens immediately, without waiting for
+ additional ovs-vsctl commands or other database
activity. Thus, a create command must generally be
accompanied by additional commands within the same
- ovs-vsctl invocation to add a chain of references
- to the newly created record from the top-level
- Open_vSwitch record. The EXAMPLES section gives
+ ovs-vsctl invocation to add a chain of references
+ to the newly created record from the top-level
+ Open_vSwitch record. The EXAMPLES section gives
some examples that show how to do this.
[--if-exists] destroy table record...
- Deletes each specified record from table. Unless
- --if-exists is specified, each records must exist.
+ Deletes each specified record from table. Unless --if-ex‐
+ ists is specified, each records must exist.
--all destroy table
Deletes all records from the table.
@@ -929,19 +925,19 @@ COMMANDS
wait-until table record [column[:key]=value]...
Waits until table contains a record named record whose
column equals value or, if key is specified, whose column
- contains a key with the specified value. This command
- supports the same operators and semantics described for
+ contains a key with the specified value. This command
+ supports the same operators and semantics described for
the find command above.
- If no column[:key]=value arguments are given, this com‐
- mand waits only until record exists. If more than one
- such argument is given, the command waits until all of
+ If no column[:key]=value arguments are given, this com‐
+ mand waits only until record exists. If more than one
+ such argument is given, the command waits until all of
them are satisfied.
Caution (ovs-vsctl as example)
- Usually wait-until should be placed at the begin‐
- ning of a set of ovs-vsctl commands. For example,
- wait-until bridge br0 -- get bridge br0 data‐
+ Usually wait-until should be placed at the begin‐
+ ning of a set of ovs-vsctl commands. For example,
+ wait-until bridge br0 -- get bridge br0 data‐
path_id waits until a bridge named br0 is created,
then prints its datapath_id column, whereas get
bridge br0 datapath_id -- wait-until bridge br0
@@ -963,11 +959,11 @@ ENVIRONMENT
server process. See Daemon Mode, above, for more information.
OVN_SBCTL_OPTIONS
- If set, a set of options for ovn-sbctl to apply automatically,
+ If set, a set of options for ovn-sbctl to apply automatically,
in the same form as on the command line.
OVN_SB_DB
- If set, the default database to contact when the --db option is
+ If set, the default database to contact when the --db option is
not used.
EXIT STATUS
@@ -978,6 +974,4 @@ EXIT STATUS
SEE ALSO
ovn-sb(5), ovn-appctl(8).
-
-
-OVN 22.12.90 ovn-sbctl ovn-sbctl(8)
+OVN 24.03.90 ovn-sbctl ovn-sbctl(8)
diff --git a/src/static/support/dist-docs/ovn-trace.8 b/src/static/support/dist-docs/ovn-trace.8
index e15ca5c6..ea23f13a 100644
--- a/src/static/support/dist-docs/ovn-trace.8
+++ b/src/static/support/dist-docs/ovn-trace.8
@@ -1,6 +1,6 @@
'\" p
.\" -*- nroff -*-
-.TH "ovn-trace" 8 "ovn-trace" "OVN 22\[char46]12\[char46]90" "OVN Manual"
+.TH "ovn-trace" 8 "ovn-trace" "OVN 24\[char46]03\[char46]90" "OVN Manual"
.fp 5 L CR \\" Make fixed-width font available as \\fL.
.de TQ
. br
diff --git a/src/static/support/dist-docs/ovn-trace.8.html b/src/static/support/dist-docs/ovn-trace.8.html
index 3d5a4a8d..e583b0ec 100644
--- a/src/static/support/dist-docs/ovn-trace.8.html
+++ b/src/static/support/dist-docs/ovn-trace.8.html
@@ -1,7 +1,5 @@
-ovn-trace(8) OVN Manual ovn-trace(8)
-
-
+ovn-trace(8) OVN Manual ovn-trace(8)
NAME
ovn-trace - Open Virtual Network logical network tracing utility
@@ -15,32 +13,32 @@
This utility simulates packet forwarding within an OVN logical network.
It can be used to run through ``what-if’’ scenarios: if a packet origi‐
nates at a logical port, what will happen to it and where will it ulti‐
- mately end up? Users already familiar with the Open vSwitch
- ofproto/trace command described in ovs-vswitch(8) will find ovn-trace
- to be a similar tool for logical networks.
+ mately end up? Users already familiar with the Open vSwitch of‐‐
+ proto/trace command described in ovs-vswitch(8) will find ovn-trace to
+ be a similar tool for logical networks.
- ovn-trace works by reading the Logical_Flow and other tables from the
- OVN southbound database (see ovn-sb(5)). It simulates a packet’s path
- through logical networks by repeatedly looking it up in the logical
+ ovn-trace works by reading the Logical_Flow and other tables from the
+ OVN southbound database (see ovn-sb(5)). It simulates a packet’s path
+ through logical networks by repeatedly looking it up in the logical
flow table, following the entire tree of possibilities.
- ovn-trace simulates only the OVN logical network. It does not simulate
- the physical elements on which the logical network is layered. This
- means that, for example, it is unimportant how VMs are distributed
- among hypervisors, or whether their hypervisors are functioning and
- reachable, so ovn-trace will yield the same results regardless. There
- is one important exception: ovn-northd, the daemon that generates the
- logical flows that ovn-trace simulates, treats logical ports differ‐
+ ovn-trace simulates only the OVN logical network. It does not simulate
+ the physical elements on which the logical network is layered. This
+ means that, for example, it is unimportant how VMs are distributed
+ among hypervisors, or whether their hypervisors are functioning and
+ reachable, so ovn-trace will yield the same results regardless. There
+ is one important exception: ovn-northd, the daemon that generates the
+ logical flows that ovn-trace simulates, treats logical ports differ‐
ently based on whether they are up or down. Thus, if you see surprising
results, ensure that the ports involved in a simulation are up.
- The simplest way to use ovn-trace is to provide the microflow (and
- optional datapath) arguments on the command line. In this case, it sim‐
- ulates the behavior of a single packet and exits. For an alternate
- usage model, see Daemon Mode below.
+ The simplest way to use ovn-trace is to provide the microflow (and op‐
+ tional datapath) arguments on the command line. In this case, it simu‐
+ lates the behavior of a single packet and exits. For an alternate usage
+ model, see Daemon Mode below.
- The optional datapath argument specifies the name of a logical data‐
- path. Acceptable names are the name from the northbound Logical_Switch
+ The optional datapath argument specifies the name of a logical data‐
+ path. Acceptable names are the name from the northbound Logical_Switch
or Logical_Router table, the UUID of a record from one of those tables,
or the UUID of a record from the southbound Datapath_Binding table.
(The datapath is optional because ovn-trace can figure it out from the
@@ -52,8 +50,8 @@
sites; for example, if the expression refers to ip4.src, there is no
need to explicitly state ip4 or eth.type == 0x800.
- For reasonable L2 behavior, the microflow should include at least
- inport and eth.dst, plus eth.src if port security is enabled. For exam‐
+ For reasonable L2 behavior, the microflow should include at least in‐‐
+ port and eth.dst, plus eth.src if port security is enabled. For exam‐
ple:
inport == "lp11" &&&& eth.src == 00:01:02:03:04:05 &&&& eth.dst == ff:ff:ff:ff:ff:ff
@@ -118,7 +116,7 @@
with ingress logical port lp111. The packet matches a logical flow in
table 0 (aka ls_in_port_sec_l2) with priority 50 and executes next(1);
to pass to table 1. Tables 1 through 11 are trivial and omitted. In ta‐
- ble 19 (aka ls_in_l2_lkup), the packet matches a flow with priority 50
+ ble 19 (aka ls_in_l2_lkup), the packet matches a flow with priority 50
based on its Ethernet destination address and the flow’s actions output
the packet to the lrp11-attachement logical port.
@@ -147,12 +145,12 @@
Minimal Output
- Minimal output includes only actions that modify packet data (not
- including OVN registers or metadata such as outport) and output actions
- that actually deliver a packet to a logical port (excluding patch
- ports). The operands of actions that modify packet data are displayed
- reduced to constants, e.g. ip4.dst = reg0; might be show as ip4.dst =
- 192.168.0.1; if that was the value actually loaded. This yields output
+ Minimal output includes only actions that modify packet data (not in‐
+ cluding OVN registers or metadata such as outport) and output actions
+ that actually deliver a packet to a logical port (excluding patch
+ ports). The operands of actions that modify packet data are displayed
+ reduced to constants, e.g. ip4.dst = reg0; might be show as ip4.dst =
+ 192.168.0.1; if that was the value actually loaded. This yields output
even simpler than the summary format. (Users familiar with Open vSwitch
may recognize this as similar in spirit to the datapath actions listed
at the bottom of ofproto/trace output.)
@@ -177,14 +175,14 @@
Forks the pipeline. In one fork, advances to the next ta‐
ble as if next; were executed. The packet is not changed,
on the assumption that no NAT state was available. In the
- other fork, the pipeline continues without change after
+ other fork, the pipeline continues without change after
the ct_dnat action.
ct_snat (without an argument)
- This action distinguishes between gateway routers and
- distributed routers. A gateway router is defined as a
- logical datapath that contains an l3gateway port; any
- other logical datapath is a distributed router. On a
+ This action distinguishes between gateway routers and
+ distributed routers. A gateway router is defined as a
+ logical datapath that contains an l3gateway port; any
+ other logical datapath is a distributed router. On a
gateway router, ct_snat; is treated as a no-op. On a dis‐
tributed router, it is treated the same way as ct_dnat;.
@@ -198,14 +196,14 @@
ct_lb;
ct_lb(ip[:port]...);
- Forks the pipeline. In one fork, sets ip4.dst (or ip6.dst)
- to one of the load-balancer addresses and the destination
+ Forks the pipeline. In one fork, sets ip4.dst (or ip6.dst)
+ to one of the load-balancer addresses and the destination
port to its associated port, if any, and sets ct.dnat to 1.
With one or more arguments, gives preference to the address
- specified on --lb-dst, if any; without arguments, uses the
- address and port specified on --lb-dst. In the other fork,
- the pipeline continues without change after the ct_lb
- action.
+ specified on --lb-dst, if any; without arguments, uses the
+ address and port specified on --lb-dst. In the other fork,
+ the pipeline continues without change after the ct_lb ac‐
+ tion.
ct_commit
put_arp
@@ -213,7 +211,7 @@
These actions are treated as no-ops.
DAEMON MODE
- If ovn-trace is invoked with the --detach option (see Daemon Options,
+ If ovn-trace is invoked with the --detach option (see Daemon Options,
below), it runs in the background as a daemon and accepts commands from
ovs-appctl (or another JSON-RPC client) indefinitely. The currently
supported commands are described below.
@@ -230,99 +228,99 @@
--detailed
--summary
--minimal
- These options control the form and level of detail in ovn-trace
+ These options control the form and level of detail in ovn-trace
output. If more than one of these options is specified, all of the
selected forms are output, in the order listed above, each headed
by a banner line. If none of these options is given, --detailed is
- the default. See Output, above, for a description of each kind of
+ the default. See Output, above, for a description of each kind of
output.
--all
Selects all three forms of output.
--ovs[=remote]
- Makes ovn-trace attempt to obtain and display the OpenFlow flows
+ Makes ovn-trace attempt to obtain and display the OpenFlow flows
that correspond to each OVN logical flow. To do so, ovn-trace con‐
nects to remote (by default, unix:/br-int.mgmt) over OpenFlow and
retrieves the flows. If remote is specified, it must be an active
OpenFlow connection method described in ovsdb(7).
To make the best use of the output, it is important to understand
- the relationship between logical flows and OpenFlow flows.
- ovn-architecture(7), under Architectural Physical Life Cycle of a
- Packet, describes this relationship. Keep in mind the following
+ the relationship between logical flows and OpenFlow flows. ovn-ar‐‐
+ chitecture(7), under Architectural Physical Life Cycle of a
+ Packet, describes this relationship. Keep in mind the following
points:
- · ovn-trace currently shows all the OpenFlow flows to which a
- logical flow corresponds, even though an actual packet
- ordinarily matches only one of these.
+ • ovn-trace currently shows all the OpenFlow flows to which a
+ logical flow corresponds, even though an actual packet or‐
+ dinarily matches only one of these.
- · Some logical flows can map to the Open vSwitch ``conjunc‐
+ • Some logical flows can map to the Open vSwitch ``conjunc‐
tive match’’ extension (see ovs-fields(7)). Currently
ovn-trace cannot display the flows with conjunction actions
that effectively produce the conj_id match.
- · Some logical flows may not be represented in the OpenFlow
- tables on a given hypervisor, if they could not be used on
+ • Some logical flows may not be represented in the OpenFlow
+ tables on a given hypervisor, if they could not be used on
that hypervisor.
- · Some OpenFlow flows do not correspond to logical flows,
- such as OpenFlow flows that map between physical and logi‐
+ • Some OpenFlow flows do not correspond to logical flows,
+ such as OpenFlow flows that map between physical and logi‐
cal ports. These flows will never show up in a trace.
- · When ovn-trace omits uninteresting logical flows from out‐
+ • When ovn-trace omits uninteresting logical flows from out‐
put, it does not look up the corresponding OpenFlow flows.
--ct=flags
- This option sets the ct_state flags that a ct_next logical action
+ This option sets the ct_state flags that a ct_next logical action
will report. The flags must be a comma- or space-separated list of
the following connection tracking flags:
- · trk: Include to indicate connection tracking has taken
+ • trk: Include to indicate connection tracking has taken
place. (This bit is set automatically even if not listed in
flags.
- · new: Include to indicate a new flow.
+ • new: Include to indicate a new flow.
- · est: Include to indicate an established flow.
+ • est: Include to indicate an established flow.
- · rel: Include to indicate a related flow.
+ • rel: Include to indicate a related flow.
- · rpl: Include to indicate a reply flow.
+ • rpl: Include to indicate a reply flow.
- · inv: Include to indicate a connection entry in a bad state.
+ • inv: Include to indicate a connection entry in a bad state.
- · dnat: Include to indicate a packet whose destination IP
- address has been changed.
+ • dnat: Include to indicate a packet whose destination IP ad‐
+ dress has been changed.
- · snat: Include to indicate a packet whose source IP address
+ • snat: Include to indicate a packet whose source IP address
has been changed.
The ct_next action is used to implement the OVN distributed fire‐
wall. For testing, useful flag combinations include:
- · trk,new: A packet in a flow in either direction through a
+ • trk,new: A packet in a flow in either direction through a
firewall that has not yet been committed (with ct_commit).
- · trk,est: A packet in an established flow going out through
+ • trk,est: A packet in an established flow going out through
a firewall.
- · trk,rpl: A packet coming in through a firewall in reply to
+ • trk,rpl: A packet coming in through a firewall in reply to
an established flow.
- · trk,inv: An invalid packet in either direction.
+ • trk,inv: An invalid packet in either direction.
A packet might pass through the connection tracker twice in one
trip through OVN: once following egress from a VM as it passes
outward through a firewall, and once preceding ingress to a second
- VM as it passes inward through a firewall. Use multiple --ct
- options to specify the flags for multiple ct_next actions.
+ VM as it passes inward through a firewall. Use multiple --ct op‐
+ tions to specify the flags for multiple ct_next actions.
- When --ct is unspecified, or when there are fewer --ct options
+ When --ct is unspecified, or when there are fewer --ct options
than ct_next actions, the flags default to trk,est.
--lb-dst=ip[:port]
- Sets the IP from VIP pool to use as destination of the packet.
+ Sets the IP from VIP pool to use as destination of the packet.
--lb-dst is not available in daemon mode.
--select-id=id
@@ -334,13 +332,13 @@
--friendly-names
--no-friendly-names
When cloud management systems such as OpenStack are layered on top
- of OVN, they often use long, human-unfriendly names for ports and
- datapaths, for example, ones that include entire UUIDs. They do
+ of OVN, they often use long, human-unfriendly names for ports and
+ datapaths, for example, ones that include entire UUIDs. They do
usually include friendlier names, but the long, hard-to-read names
are the ones that appear in matches and actions. By default, or
with --friendly-names, ovn-trace substitutes these friendlier
names for the long names in its output. Use --no-friendly-names to
- disable this behavior; this option might be useful, for example,
+ disable this behavior; this option might be useful, for example,
if a program is going to parse ovn-trace output.
Daemon Options
@@ -353,7 +351,7 @@
If --pidfile is not specified, no pidfile is created.
--overwrite-pidfile
- By default, when --pidfile is specified and the specified pid‐
+ By default, when --pidfile is specified and the specified pid‐
file already exists and is locked by a running process, the dae‐
mon refuses to start. Specify --overwrite-pidfile to cause it to
instead overwrite the pidfile.
@@ -361,8 +359,8 @@
When --pidfile is not specified, this option has no effect.
--detach
- Runs this program as a background process. The process forks,
- and in the child it starts a new session, closes the standard
+ Runs this program as a background process. The process forks,
+ and in the child it starts a new session, closes the standard
file descriptors (which has the side effect of disabling logging
to the console), and changes its current directory to the root
(unless --no-chdir is specified). After the child completes its
@@ -370,24 +368,24 @@
--monitor
Creates an additional process to monitor this program. If it
- dies due to a signal that indicates a programming error (SIGA‐
+ dies due to a signal that indicates a programming error (SIGA‐‐
BRT, SIGALRM, SIGBUS, SIGFPE, SIGILL, SIGPIPE, SIGSEGV, SIGXCPU,
or SIGXFSZ) then the monitor process starts a new copy of it. If
the daemon dies or exits for another reason, the monitor process
exits.
- This option is normally used with --detach, but it also func‐
+ This option is normally used with --detach, but it also func‐
tions without it.
--no-chdir
- By default, when --detach is specified, the daemon changes its
- current working directory to the root directory after it
- detaches. Otherwise, invoking the daemon from a carelessly cho‐
- sen directory would prevent the administrator from unmounting
- the file system that holds that directory.
-
- Specifying --no-chdir suppresses this behavior, preventing the
- daemon from changing its current working directory. This may be
+ By default, when --detach is specified, the daemon changes its
+ current working directory to the root directory after it de‐
+ taches. Otherwise, invoking the daemon from a carelessly chosen
+ directory would prevent the administrator from unmounting the
+ file system that holds that directory.
+
+ Specifying --no-chdir suppresses this behavior, preventing the
+ daemon from changing its current working directory. This may be
useful for collecting core files, since it is common behavior to
write core dumps into the current working directory and the root
directory is not a good directory to use.
@@ -395,13 +393,13 @@
This option has no effect when --detach is not specified.
--no-self-confinement
- By default this daemon will try to self-confine itself to work
- with files under well-known directories determined at build
- time. It is better to stick with this default behavior and not
- to use this flag unless some other Access Control is used to
- confine daemon. Note that in contrast to other access control
- implementations that are typically enforced from kernel-space
- (e.g. DAC or MAC), self-confinement is imposed from the user-
+ By default this daemon will try to self-confine itself to work
+ with files under well-known directories determined at build
+ time. It is better to stick with this default behavior and not
+ to use this flag unless some other Access Control is used to
+ confine daemon. Note that in contrast to other access control
+ implementations that are typically enforced from kernel-space
+ (e.g. DAC or MAC), self-confinement is imposed from the user-
space daemon itself and hence should not be considered as a full
confinement strategy, but instead should be viewed as an addi‐
tional layer of security.
@@ -421,32 +419,32 @@
apply even if the new user is root.
On Windows, this option is not currently supported. For security
- reasons, specifying this option will cause the daemon process
+ reasons, specifying this option will cause the daemon process
not to start.
Logging Options
-v[spec]
--verbose=[spec]
- Sets logging levels. Without any spec, sets the log level for
- every module and destination to dbg. Otherwise, spec is a list of
+ Sets logging levels. Without any spec, sets the log level for
+ every module and destination to dbg. Otherwise, spec is a list of
words separated by spaces or commas or colons, up to one from each
category below:
- · A valid module name, as displayed by the vlog/list command
+ • A valid module name, as displayed by the vlog/list command
on ovs-appctl(8), limits the log level change to the speci‐
fied module.
- · syslog, console, or file, to limit the log level change to
- only to the system log, to the console, or to a file,
- respectively. (If --detach is specified, the daemon closes
- its standard file descriptors, so logging to the console
+ • syslog, console, or file, to limit the log level change to
+ only to the system log, to the console, or to a file, re‐
+ spectively. (If --detach is specified, the daemon closes
+ its standard file descriptors, so logging to the console
will have no effect.)
- On Windows platform, syslog is accepted as a word and is
+ On Windows platform, syslog is accepted as a word and is
only useful along with the --syslog-target option (the word
has no effect otherwise).
- · off, emer, err, warn, info, or dbg, to control the log
+ • off, emer, err, warn, info, or dbg, to control the log
level. Messages of the given severity or higher will be
logged, and messages of lower severity will be filtered
out. off filters out all messages. See ovs-appctl(8) for a
@@ -462,26 +460,26 @@
-v
--verbose
- Sets the maximum logging verbosity level, equivalent to --ver‐
+ Sets the maximum logging verbosity level, equivalent to --ver‐‐
bose=dbg.
-vPATTERN:destination:pattern
--verbose=PATTERN:destination:pattern
- Sets the log pattern for destination to pattern. Refer to
- ovs-appctl(8) for a description of the valid syntax for pattern.
+ Sets the log pattern for destination to pattern. Refer to ovs-ap‐‐
+ pctl(8) for a description of the valid syntax for pattern.
-vFACILITY:facility
--verbose=FACILITY:facility
- Sets the RFC5424 facility of the log message. facility can be one
+ Sets the RFC5424 facility of the log message. facility can be one
of kern, user, mail, daemon, auth, syslog, lpr, news, uucp, clock,
ftp, ntp, audit, alert, clock2, local0, local1, local2, local3,
local4, local5, local6 or local7. If this option is not specified,
- daemon is used as the default for the local system syslog and
- local0 is used while sending a message to the target provided via
+ daemon is used as the default for the local system syslog and lo‐‐
+ cal0 is used while sending a message to the target provided via
the --syslog-target option.
--log-file[=file]
- Enables logging to a file. If file is specified, then it is used
+ Enables logging to a file. If file is specified, then it is used
as the exact name for the log file. The default log file name used
if file is omitted is /usr/local/var/log/ovn/program.log.
@@ -494,30 +492,30 @@
Specify method as how syslog messages should be sent to syslog
daemon. The following forms are supported:
- · libc, to use the libc syslog() function. Downside of using
+ • libc, to use the libc syslog() function. Downside of using
this options is that libc adds fixed prefix to every mes‐
sage before it is actually sent to the syslog daemon over
/dev/log UNIX domain socket.
- · unix:file, to use a UNIX domain socket directly. It is pos‐
+ • unix:file, to use a UNIX domain socket directly. It is pos‐
sible to specify arbitrary message format with this option.
However, rsyslogd 8.9 and older versions use hard coded
parser function anyway that limits UNIX domain socket use.
If you want to use arbitrary message format with older
- rsyslogd versions, then use UDP socket to localhost IP
- address instead.
+ rsyslogd versions, then use UDP socket to localhost IP ad‐
+ dress instead.
- · udp:ip:port, to use a UDP socket. With this method it is
+ • udp:ip:port, to use a UDP socket. With this method it is
possible to use arbitrary message format also with older
- rsyslogd. When sending syslog messages over UDP socket
- extra precaution needs to be taken into account, for exam‐
- ple, syslog daemon needs to be configured to listen on the
- specified UDP port, accidental iptables rules could be
- interfering with local syslog traffic and there are some
- security considerations that apply to UDP sockets, but do
- not apply to UNIX domain sockets.
+ rsyslogd. When sending syslog messages over UDP socket ex‐
+ tra precaution needs to be taken into account, for example,
+ syslog daemon needs to be configured to listen on the spec‐
+ ified UDP port, accidental iptables rules could be inter‐
+ fering with local syslog traffic and there are some secu‐
+ rity considerations that apply to UDP sockets, but do not
+ apply to UNIX domain sockets.
- · null, to discard all messages logged to syslog.
+ • null, to discard all messages logged to syslog.
The default is taken from the OVS_SYSLOG_METHOD environment vari‐
able; if it is unset, the default is libc.
@@ -545,20 +543,20 @@
ifying certificates presented to this program by SSL peers.
(This may be the same certificate that SSL peers use to
verify the certificate specified on -c or --certificate, or
- it may be a different one, depending on the PKI design in
+ it may be a different one, depending on the PKI design in
use.)
-C none
--ca-cert=none
- Disables verification of certificates presented by SSL
- peers. This introduces a security risk, because it means
- that certificates cannot be verified to be those of known
+ Disables verification of certificates presented by SSL
+ peers. This introduces a security risk, because it means
+ that certificates cannot be verified to be those of known
trusted hosts.
Other Options
--db database
- The OVSDB database remote to contact. If the OVN_SB_DB environ‐
- ment variable is set, its value is used as the default. Other‐
+ The OVSDB database remote to contact. If the OVN_SB_DB environ‐
+ ment variable is set, its value is used as the default. Other‐
wise, the default is unix:/db.sock, but this default is unlikely
to be useful outside of single-machine OVN test environments.
@@ -570,7 +568,5 @@
--version
Prints version information to the console.
-
-
-OVN 22.12.90 ovn-trace ovn-trace(8)
+OVN 24.03.90 ovn-trace ovn-trace(8)
diff --git a/src/static/support/dist-docs/ovn-trace.8.pdf b/src/static/support/dist-docs/ovn-trace.8.pdf
index 2b7c90bd..11ae9c29 100644
Binary files a/src/static/support/dist-docs/ovn-trace.8.pdf and b/src/static/support/dist-docs/ovn-trace.8.pdf differ
diff --git a/src/static/support/dist-docs/ovn-trace.8.txt b/src/static/support/dist-docs/ovn-trace.8.txt
index 121f40b8..cc5a6917 100644
--- a/src/static/support/dist-docs/ovn-trace.8.txt
+++ b/src/static/support/dist-docs/ovn-trace.8.txt
@@ -1,7 +1,5 @@
ovn-trace(8) OVN Manual ovn-trace(8)
-
-
NAME
ovn-trace - Open Virtual Network logical network tracing utility
@@ -14,32 +12,32 @@ DESCRIPTION
This utility simulates packet forwarding within an OVN logical network.
It can be used to run through ``what-if’’ scenarios: if a packet origi‐
nates at a logical port, what will happen to it and where will it ulti‐
- mately end up? Users already familiar with the Open vSwitch
- ofproto/trace command described in ovs-vswitch(8) will find ovn-trace
- to be a similar tool for logical networks.
+ mately end up? Users already familiar with the Open vSwitch of‐
+ proto/trace command described in ovs-vswitch(8) will find ovn-trace to
+ be a similar tool for logical networks.
- ovn-trace works by reading the Logical_Flow and other tables from the
- OVN southbound database (see ovn-sb(5)). It simulates a packet’s path
- through logical networks by repeatedly looking it up in the logical
+ ovn-trace works by reading the Logical_Flow and other tables from the
+ OVN southbound database (see ovn-sb(5)). It simulates a packet’s path
+ through logical networks by repeatedly looking it up in the logical
flow table, following the entire tree of possibilities.
- ovn-trace simulates only the OVN logical network. It does not simulate
- the physical elements on which the logical network is layered. This
- means that, for example, it is unimportant how VMs are distributed
- among hypervisors, or whether their hypervisors are functioning and
- reachable, so ovn-trace will yield the same results regardless. There
- is one important exception: ovn-northd, the daemon that generates the
- logical flows that ovn-trace simulates, treats logical ports differ‐
+ ovn-trace simulates only the OVN logical network. It does not simulate
+ the physical elements on which the logical network is layered. This
+ means that, for example, it is unimportant how VMs are distributed
+ among hypervisors, or whether their hypervisors are functioning and
+ reachable, so ovn-trace will yield the same results regardless. There
+ is one important exception: ovn-northd, the daemon that generates the
+ logical flows that ovn-trace simulates, treats logical ports differ‐
ently based on whether they are up or down. Thus, if you see surprising
results, ensure that the ports involved in a simulation are up.
- The simplest way to use ovn-trace is to provide the microflow (and
- optional datapath) arguments on the command line. In this case, it sim‐
- ulates the behavior of a single packet and exits. For an alternate
- usage model, see Daemon Mode below.
+ The simplest way to use ovn-trace is to provide the microflow (and op‐
+ tional datapath) arguments on the command line. In this case, it simu‐
+ lates the behavior of a single packet and exits. For an alternate usage
+ model, see Daemon Mode below.
- The optional datapath argument specifies the name of a logical data‐
- path. Acceptable names are the name from the northbound Logical_Switch
+ The optional datapath argument specifies the name of a logical data‐
+ path. Acceptable names are the name from the northbound Logical_Switch
or Logical_Router table, the UUID of a record from one of those tables,
or the UUID of a record from the southbound Datapath_Binding table.
(The datapath is optional because ovn-trace can figure it out from the
@@ -51,8 +49,8 @@ DESCRIPTION
sites; for example, if the expression refers to ip4.src, there is no
need to explicitly state ip4 or eth.type == 0x800.
- For reasonable L2 behavior, the microflow should include at least
- inport and eth.dst, plus eth.src if port security is enabled. For exam‐
+ For reasonable L2 behavior, the microflow should include at least in‐
+ port and eth.dst, plus eth.src if port security is enabled. For exam‐
ple:
inport == "lp11" && eth.src == 00:01:02:03:04:05 && eth.dst == ff:ff:ff:ff:ff:ff
@@ -117,7 +115,7 @@ OUTPUT
with ingress logical port lp111. The packet matches a logical flow in
table 0 (aka ls_in_port_sec_l2) with priority 50 and executes next(1);
to pass to table 1. Tables 1 through 11 are trivial and omitted. In ta‐
- ble 19 (aka ls_in_l2_lkup), the packet matches a flow with priority 50
+ ble 19 (aka ls_in_l2_lkup), the packet matches a flow with priority 50
based on its Ethernet destination address and the flow’s actions output
the packet to the lrp11-attachement logical port.
@@ -146,12 +144,12 @@ OUTPUT
Minimal Output
- Minimal output includes only actions that modify packet data (not
- including OVN registers or metadata such as outport) and output actions
- that actually deliver a packet to a logical port (excluding patch
- ports). The operands of actions that modify packet data are displayed
- reduced to constants, e.g. ip4.dst = reg0; might be show as ip4.dst =
- 192.168.0.1; if that was the value actually loaded. This yields output
+ Minimal output includes only actions that modify packet data (not in‐
+ cluding OVN registers or metadata such as outport) and output actions
+ that actually deliver a packet to a logical port (excluding patch
+ ports). The operands of actions that modify packet data are displayed
+ reduced to constants, e.g. ip4.dst = reg0; might be show as ip4.dst =
+ 192.168.0.1; if that was the value actually loaded. This yields output
even simpler than the summary format. (Users familiar with Open vSwitch
may recognize this as similar in spirit to the datapath actions listed
at the bottom of ofproto/trace output.)
@@ -176,14 +174,14 @@ STATEFUL ACTIONS
Forks the pipeline. In one fork, advances to the next ta‐
ble as if next; were executed. The packet is not changed,
on the assumption that no NAT state was available. In the
- other fork, the pipeline continues without change after
+ other fork, the pipeline continues without change after
the ct_dnat action.
ct_snat (without an argument)
- This action distinguishes between gateway routers and
- distributed routers. A gateway router is defined as a
- logical datapath that contains an l3gateway port; any
- other logical datapath is a distributed router. On a
+ This action distinguishes between gateway routers and
+ distributed routers. A gateway router is defined as a
+ logical datapath that contains an l3gateway port; any
+ other logical datapath is a distributed router. On a
gateway router, ct_snat; is treated as a no-op. On a dis‐
tributed router, it is treated the same way as ct_dnat;.
@@ -197,14 +195,14 @@ STATEFUL ACTIONS
ct_lb;
ct_lb(ip[:port]...);
- Forks the pipeline. In one fork, sets ip4.dst (or ip6.dst)
- to one of the load-balancer addresses and the destination
+ Forks the pipeline. In one fork, sets ip4.dst (or ip6.dst)
+ to one of the load-balancer addresses and the destination
port to its associated port, if any, and sets ct.dnat to 1.
With one or more arguments, gives preference to the address
- specified on --lb-dst, if any; without arguments, uses the
- address and port specified on --lb-dst. In the other fork,
- the pipeline continues without change after the ct_lb
- action.
+ specified on --lb-dst, if any; without arguments, uses the
+ address and port specified on --lb-dst. In the other fork,
+ the pipeline continues without change after the ct_lb ac‐
+ tion.
ct_commit
put_arp
@@ -212,7 +210,7 @@ STATEFUL ACTIONS
These actions are treated as no-ops.
DAEMON MODE
- If ovn-trace is invoked with the --detach option (see Daemon Options,
+ If ovn-trace is invoked with the --detach option (see Daemon Options,
below), it runs in the background as a daemon and accepts commands from
ovs-appctl (or another JSON-RPC client) indefinitely. The currently
supported commands are described below.
@@ -229,99 +227,99 @@ OPTIONS
--detailed
--summary
--minimal
- These options control the form and level of detail in ovn-trace
+ These options control the form and level of detail in ovn-trace
output. If more than one of these options is specified, all of the
selected forms are output, in the order listed above, each headed
by a banner line. If none of these options is given, --detailed is
- the default. See Output, above, for a description of each kind of
+ the default. See Output, above, for a description of each kind of
output.
--all
Selects all three forms of output.
--ovs[=remote]
- Makes ovn-trace attempt to obtain and display the OpenFlow flows
+ Makes ovn-trace attempt to obtain and display the OpenFlow flows
that correspond to each OVN logical flow. To do so, ovn-trace con‐
nects to remote (by default, unix:/br-int.mgmt) over OpenFlow and
retrieves the flows. If remote is specified, it must be an active
OpenFlow connection method described in ovsdb(7).
To make the best use of the output, it is important to understand
- the relationship between logical flows and OpenFlow flows.
- ovn-architecture(7), under Architectural Physical Life Cycle of a
- Packet, describes this relationship. Keep in mind the following
+ the relationship between logical flows and OpenFlow flows. ovn-ar‐
+ chitecture(7), under Architectural Physical Life Cycle of a
+ Packet, describes this relationship. Keep in mind the following
points:
- · ovn-trace currently shows all the OpenFlow flows to which a
- logical flow corresponds, even though an actual packet
- ordinarily matches only one of these.
+ • ovn-trace currently shows all the OpenFlow flows to which a
+ logical flow corresponds, even though an actual packet or‐
+ dinarily matches only one of these.
- · Some logical flows can map to the Open vSwitch ``conjunc‐
+ • Some logical flows can map to the Open vSwitch ``conjunc‐
tive match’’ extension (see ovs-fields(7)). Currently
ovn-trace cannot display the flows with conjunction actions
that effectively produce the conj_id match.
- · Some logical flows may not be represented in the OpenFlow
- tables on a given hypervisor, if they could not be used on
+ • Some logical flows may not be represented in the OpenFlow
+ tables on a given hypervisor, if they could not be used on
that hypervisor.
- · Some OpenFlow flows do not correspond to logical flows,
- such as OpenFlow flows that map between physical and logi‐
+ • Some OpenFlow flows do not correspond to logical flows,
+ such as OpenFlow flows that map between physical and logi‐
cal ports. These flows will never show up in a trace.
- · When ovn-trace omits uninteresting logical flows from out‐
+ • When ovn-trace omits uninteresting logical flows from out‐
put, it does not look up the corresponding OpenFlow flows.
--ct=flags
- This option sets the ct_state flags that a ct_next logical action
+ This option sets the ct_state flags that a ct_next logical action
will report. The flags must be a comma- or space-separated list of
the following connection tracking flags:
- · trk: Include to indicate connection tracking has taken
+ • trk: Include to indicate connection tracking has taken
place. (This bit is set automatically even if not listed in
flags.
- · new: Include to indicate a new flow.
+ • new: Include to indicate a new flow.
- · est: Include to indicate an established flow.
+ • est: Include to indicate an established flow.
- · rel: Include to indicate a related flow.
+ • rel: Include to indicate a related flow.
- · rpl: Include to indicate a reply flow.
+ • rpl: Include to indicate a reply flow.
- · inv: Include to indicate a connection entry in a bad state.
+ • inv: Include to indicate a connection entry in a bad state.
- · dnat: Include to indicate a packet whose destination IP
- address has been changed.
+ • dnat: Include to indicate a packet whose destination IP ad‐
+ dress has been changed.
- · snat: Include to indicate a packet whose source IP address
+ • snat: Include to indicate a packet whose source IP address
has been changed.
The ct_next action is used to implement the OVN distributed fire‐
wall. For testing, useful flag combinations include:
- · trk,new: A packet in a flow in either direction through a
+ • trk,new: A packet in a flow in either direction through a
firewall that has not yet been committed (with ct_commit).
- · trk,est: A packet in an established flow going out through
+ • trk,est: A packet in an established flow going out through
a firewall.
- · trk,rpl: A packet coming in through a firewall in reply to
+ • trk,rpl: A packet coming in through a firewall in reply to
an established flow.
- · trk,inv: An invalid packet in either direction.
+ • trk,inv: An invalid packet in either direction.
A packet might pass through the connection tracker twice in one
trip through OVN: once following egress from a VM as it passes
outward through a firewall, and once preceding ingress to a second
- VM as it passes inward through a firewall. Use multiple --ct
- options to specify the flags for multiple ct_next actions.
+ VM as it passes inward through a firewall. Use multiple --ct op‐
+ tions to specify the flags for multiple ct_next actions.
- When --ct is unspecified, or when there are fewer --ct options
+ When --ct is unspecified, or when there are fewer --ct options
than ct_next actions, the flags default to trk,est.
--lb-dst=ip[:port]
- Sets the IP from VIP pool to use as destination of the packet.
+ Sets the IP from VIP pool to use as destination of the packet.
--lb-dst is not available in daemon mode.
--select-id=id
@@ -333,13 +331,13 @@ OPTIONS
--friendly-names
--no-friendly-names
When cloud management systems such as OpenStack are layered on top
- of OVN, they often use long, human-unfriendly names for ports and
- datapaths, for example, ones that include entire UUIDs. They do
+ of OVN, they often use long, human-unfriendly names for ports and
+ datapaths, for example, ones that include entire UUIDs. They do
usually include friendlier names, but the long, hard-to-read names
are the ones that appear in matches and actions. By default, or
with --friendly-names, ovn-trace substitutes these friendlier
names for the long names in its output. Use --no-friendly-names to
- disable this behavior; this option might be useful, for example,
+ disable this behavior; this option might be useful, for example,
if a program is going to parse ovn-trace output.
Daemon Options
@@ -352,7 +350,7 @@ OPTIONS
If --pidfile is not specified, no pidfile is created.
--overwrite-pidfile
- By default, when --pidfile is specified and the specified pid‐
+ By default, when --pidfile is specified and the specified pid‐
file already exists and is locked by a running process, the dae‐
mon refuses to start. Specify --overwrite-pidfile to cause it to
instead overwrite the pidfile.
@@ -360,8 +358,8 @@ OPTIONS
When --pidfile is not specified, this option has no effect.
--detach
- Runs this program as a background process. The process forks,
- and in the child it starts a new session, closes the standard
+ Runs this program as a background process. The process forks,
+ and in the child it starts a new session, closes the standard
file descriptors (which has the side effect of disabling logging
to the console), and changes its current directory to the root
(unless --no-chdir is specified). After the child completes its
@@ -369,24 +367,24 @@ OPTIONS
--monitor
Creates an additional process to monitor this program. If it
- dies due to a signal that indicates a programming error (SIGA‐
+ dies due to a signal that indicates a programming error (SIGA‐
BRT, SIGALRM, SIGBUS, SIGFPE, SIGILL, SIGPIPE, SIGSEGV, SIGXCPU,
or SIGXFSZ) then the monitor process starts a new copy of it. If
the daemon dies or exits for another reason, the monitor process
exits.
- This option is normally used with --detach, but it also func‐
+ This option is normally used with --detach, but it also func‐
tions without it.
--no-chdir
- By default, when --detach is specified, the daemon changes its
- current working directory to the root directory after it
- detaches. Otherwise, invoking the daemon from a carelessly cho‐
- sen directory would prevent the administrator from unmounting
- the file system that holds that directory.
-
- Specifying --no-chdir suppresses this behavior, preventing the
- daemon from changing its current working directory. This may be
+ By default, when --detach is specified, the daemon changes its
+ current working directory to the root directory after it de‐
+ taches. Otherwise, invoking the daemon from a carelessly chosen
+ directory would prevent the administrator from unmounting the
+ file system that holds that directory.
+
+ Specifying --no-chdir suppresses this behavior, preventing the
+ daemon from changing its current working directory. This may be
useful for collecting core files, since it is common behavior to
write core dumps into the current working directory and the root
directory is not a good directory to use.
@@ -394,13 +392,13 @@ OPTIONS
This option has no effect when --detach is not specified.
--no-self-confinement
- By default this daemon will try to self-confine itself to work
- with files under well-known directories determined at build
- time. It is better to stick with this default behavior and not
- to use this flag unless some other Access Control is used to
- confine daemon. Note that in contrast to other access control
- implementations that are typically enforced from kernel-space
- (e.g. DAC or MAC), self-confinement is imposed from the user-
+ By default this daemon will try to self-confine itself to work
+ with files under well-known directories determined at build
+ time. It is better to stick with this default behavior and not
+ to use this flag unless some other Access Control is used to
+ confine daemon. Note that in contrast to other access control
+ implementations that are typically enforced from kernel-space
+ (e.g. DAC or MAC), self-confinement is imposed from the user-
space daemon itself and hence should not be considered as a full
confinement strategy, but instead should be viewed as an addi‐
tional layer of security.
@@ -420,32 +418,32 @@ OPTIONS
apply even if the new user is root.
On Windows, this option is not currently supported. For security
- reasons, specifying this option will cause the daemon process
+ reasons, specifying this option will cause the daemon process
not to start.
Logging Options
-v[spec]
--verbose=[spec]
- Sets logging levels. Without any spec, sets the log level for
- every module and destination to dbg. Otherwise, spec is a list of
+ Sets logging levels. Without any spec, sets the log level for
+ every module and destination to dbg. Otherwise, spec is a list of
words separated by spaces or commas or colons, up to one from each
category below:
- · A valid module name, as displayed by the vlog/list command
+ • A valid module name, as displayed by the vlog/list command
on ovs-appctl(8), limits the log level change to the speci‐
fied module.
- · syslog, console, or file, to limit the log level change to
- only to the system log, to the console, or to a file,
- respectively. (If --detach is specified, the daemon closes
- its standard file descriptors, so logging to the console
+ • syslog, console, or file, to limit the log level change to
+ only to the system log, to the console, or to a file, re‐
+ spectively. (If --detach is specified, the daemon closes
+ its standard file descriptors, so logging to the console
will have no effect.)
- On Windows platform, syslog is accepted as a word and is
+ On Windows platform, syslog is accepted as a word and is
only useful along with the --syslog-target option (the word
has no effect otherwise).
- · off, emer, err, warn, info, or dbg, to control the log
+ • off, emer, err, warn, info, or dbg, to control the log
level. Messages of the given severity or higher will be
logged, and messages of lower severity will be filtered
out. off filters out all messages. See ovs-appctl(8) for a
@@ -461,26 +459,26 @@ OPTIONS
-v
--verbose
- Sets the maximum logging verbosity level, equivalent to --ver‐
+ Sets the maximum logging verbosity level, equivalent to --ver‐
bose=dbg.
-vPATTERN:destination:pattern
--verbose=PATTERN:destination:pattern
- Sets the log pattern for destination to pattern. Refer to
- ovs-appctl(8) for a description of the valid syntax for pattern.
+ Sets the log pattern for destination to pattern. Refer to ovs-ap‐
+ pctl(8) for a description of the valid syntax for pattern.
-vFACILITY:facility
--verbose=FACILITY:facility
- Sets the RFC5424 facility of the log message. facility can be one
+ Sets the RFC5424 facility of the log message. facility can be one
of kern, user, mail, daemon, auth, syslog, lpr, news, uucp, clock,
ftp, ntp, audit, alert, clock2, local0, local1, local2, local3,
local4, local5, local6 or local7. If this option is not specified,
- daemon is used as the default for the local system syslog and
- local0 is used while sending a message to the target provided via
+ daemon is used as the default for the local system syslog and lo‐
+ cal0 is used while sending a message to the target provided via
the --syslog-target option.
--log-file[=file]
- Enables logging to a file. If file is specified, then it is used
+ Enables logging to a file. If file is specified, then it is used
as the exact name for the log file. The default log file name used
if file is omitted is /usr/local/var/log/ovn/program.log.
@@ -493,30 +491,30 @@ OPTIONS
Specify method as how syslog messages should be sent to syslog
daemon. The following forms are supported:
- · libc, to use the libc syslog() function. Downside of using
+ • libc, to use the libc syslog() function. Downside of using
this options is that libc adds fixed prefix to every mes‐
sage before it is actually sent to the syslog daemon over
/dev/log UNIX domain socket.
- · unix:file, to use a UNIX domain socket directly. It is pos‐
+ • unix:file, to use a UNIX domain socket directly. It is pos‐
sible to specify arbitrary message format with this option.
However, rsyslogd 8.9 and older versions use hard coded
parser function anyway that limits UNIX domain socket use.
If you want to use arbitrary message format with older
- rsyslogd versions, then use UDP socket to localhost IP
- address instead.
+ rsyslogd versions, then use UDP socket to localhost IP ad‐
+ dress instead.
- · udp:ip:port, to use a UDP socket. With this method it is
+ • udp:ip:port, to use a UDP socket. With this method it is
possible to use arbitrary message format also with older
- rsyslogd. When sending syslog messages over UDP socket
- extra precaution needs to be taken into account, for exam‐
- ple, syslog daemon needs to be configured to listen on the
- specified UDP port, accidental iptables rules could be
- interfering with local syslog traffic and there are some
- security considerations that apply to UDP sockets, but do
- not apply to UNIX domain sockets.
+ rsyslogd. When sending syslog messages over UDP socket ex‐
+ tra precaution needs to be taken into account, for example,
+ syslog daemon needs to be configured to listen on the spec‐
+ ified UDP port, accidental iptables rules could be inter‐
+ fering with local syslog traffic and there are some secu‐
+ rity considerations that apply to UDP sockets, but do not
+ apply to UNIX domain sockets.
- · null, to discard all messages logged to syslog.
+ • null, to discard all messages logged to syslog.
The default is taken from the OVS_SYSLOG_METHOD environment vari‐
able; if it is unset, the default is libc.
@@ -544,20 +542,20 @@ OPTIONS
ifying certificates presented to this program by SSL peers.
(This may be the same certificate that SSL peers use to
verify the certificate specified on -c or --certificate, or
- it may be a different one, depending on the PKI design in
+ it may be a different one, depending on the PKI design in
use.)
-C none
--ca-cert=none
- Disables verification of certificates presented by SSL
- peers. This introduces a security risk, because it means
- that certificates cannot be verified to be those of known
+ Disables verification of certificates presented by SSL
+ peers. This introduces a security risk, because it means
+ that certificates cannot be verified to be those of known
trusted hosts.
Other Options
--db database
- The OVSDB database remote to contact. If the OVN_SB_DB environ‐
- ment variable is set, its value is used as the default. Other‐
+ The OVSDB database remote to contact. If the OVN_SB_DB environ‐
+ ment variable is set, its value is used as the default. Other‐
wise, the default is unix:/db.sock, but this default is unlikely
to be useful outside of single-machine OVN test environments.
@@ -569,6 +567,4 @@ OPTIONS
--version
Prints version information to the console.
-
-
-OVN 22.12.90 ovn-trace ovn-trace(8)
+OVN 24.03.90 ovn-trace ovn-trace(8)